While developing some javascript classes with MooTools’ new Class() pattern I found myself being mysteriously redirected from http://www.example.com/test.html to http://www.example.com/[object Object] every time I opened the page.

Turns out instead of saying

  var C = new Class({...});
  var c = new C();

I had, forgotten the second new and written

  var C = new Class({...});
  var c = C();

I can’t explain the redirect, but once I added the missing new keyword everything was back to normal. This happened in a much more convoluted situation which made the missing keyword harder to spot. I guess it goes to show that you shouldn’t try to be clever, even when “just writing an unit test”.

This is one of my pet peeves. Language with prolific use of the underscore character. I have many times looked at Ruby to see what all the fuss is about and never gotten past all those damn underscores. I will never use a language that relies on underscore as a word boundary.

Underscore is not a space, it doesn’t look like a space so why bother trying? Instead it breaks logical units such as variable names or function names into units that may or may not belong together. By skimming I cant tell if that is a . (dot) deference or just a pseudo word boundary. Further more it slows down typing because you have to move your fingers way out of the normal flow.

Camelcasing is tried, tested and found divine, stop messing with it.

This latest rant was brought on by the JSSpec framework for unit testing in Javascript, which I am considering forking because of the underscores.

Next week, possibly a rant on the curly bracket character, and why it is impossible to type reliably on scandinavian keyboards. Stop using it too!

Keeping the Magpie Developer in mind, I have decided to adopt a javascript framework. After mature deliberation I decided on MooTools, here are my reasonings:

1. It’s in active development
2. It lets me maintain references to the real DOM elements, unlike JQuery.
3. I can call into the library when I need it, no need to ask it not to clutter the namespace (MochiKit) with hundreds of functions.
4. I generally build my DOM from javascript (progressive enhancement) and so I already have references to the elements that I need. I dont need a query language (JQuery) to find my elements.
5. I am not looking to add glitz to my sites with a few lines of code .
6. I don’t think Javascript needs to “suck less” (MochiKit).

I should note that this is by no means final, hell I was half way writing this about PrototypeJS before I dug deeper into MooTools and found it excellent.

Our customer has a e-mail campaing system that sends out around 30.000 opt-in emails to its customers every now and then. Nothing spectacular but it handles keyword substitution, independent operation for long running tasks, some pretty wild cyrillic texts.

Recently though sending newsletters to customers with non ASCII characters in their names stopped working, something which did work before, the only recent changes were some added tracing instructions and exception handling.

Here’s why!

  using System.Net.Mail;
  using System.Reflection;
  using NUnit.Framework;
  
  namespace Tests {
    [TestFixture]
    public class TestMailMessage {
      [Test]
      public void TestSending() {
        string email = "test@example.com";
        string name = "Börje Bengtson";
        MailAddress a = new MailAddress(email,name);
        MailAddress b = new MailAddress(email,name);
        b.ToString();
        BindingFlags flags = BindingFlags.Instance |
                             BindingFlags.NonPublic |
                             BindingFlags.InvokeMethod;
        string encodedStringA = typeof(MailAddress)
          .InvokeMember("ToEncodedString",flags,null,a,null);
        string encodedStringB = typeof(MailAddress)
          .InvokeMember("ToEncodedString",flags,null,b,null);
        /** BOOM! **/
        Assert.AreEqual(encodedStringA, encodedStringB);
      }
    }
  }

Calling the ToString() method before ToEncodedString() (which is called when sending the message) will pollute the MailAddress internal state with an unencoded version of the address that is returned as a cached version on subsequent calls to ToEncodedString().

Turns out some of the added tracing code printed out the address of the receiver it was processing at the moment, triggering the bug in the framework.

Now, if I could only find somewhere to report this…

Been solving a few HTML email mysteries lately