‘Open Source’ Category

  1. How Cappuccino handles pass-by-reference APIs in Cocoa.

    August 4, 2012 by Eduardo Gonzalez

    I’ve been using Cappuccino at work recently and I came across a corner of Objective-J that I previously didn’t know about: how to use enumerateObjectsUsingBlock.

    One of the nice things about Objective-C is that it has blocks.  Blocks allow you to make functions that take other functions as arguments, all while preserving scope. One of the most popular block-using APIs is the NSArray method enumerateObjectsUsingBlock. It takes a block that has three arguments: the current value of the iteration, the current index and a reference to a Boolean stop variable. If you set the variable to YES the loop will stop (much like the break keyword, which only works to break out of while and for loops.)

    This is a problem for JavaScript because it always passes by value. Since it’s very cheap to create objects in JavaScript you could just pass an object with a property you can set, but that means that you have to remember the property name to set and the caller has to remember to copy that value back out. The Cappuccino developers thought of using a function that closes over an object in the parent scope via a macro called AT_REF.

    To use a cappuccino AT_REF you simply call it and pass in the new value you want to set. Like so:

    [array enumerateObjectsUsingBlock:function (item, i, stop) { 
        stop(YES);
    }];
    

    In the implementation of enumerateObjectsUsingBlock you’ll see something like the following:

    var stop = NO; 
    for (var i = 0; i < length; i++) { 
        block(arr[i], i, BY_REF(stop)); 
        if (stop) 
            break; 
    }
    

    The AT_REF macro expands to something like:

    (function(val) { 
        if (arguments.length) 
            return (stop = val); 
        return val; 
    }) 
    

    That way you can both set the value by calling it with an argument and get the value by calling it with no arguments.

    It’s brilliant if you ask me. But then again, pretty obvious when you think about it.

    In the future the devs would like to integrate this into the language by using @ref() and @deref(), (hence the name of the macro).

    To define methods that use AT_REF in your own code you can simply @import <Foundation/Ref.h>.  Clients of your API just need to know to call the argument to set and get it’s value.


  2. What worries me about Scala

    May 4, 2012 by Eduardo Gonzalez

    I’ve recently been rediscovering podcasts.  I’m particularly fond of the NodeUp podcast, but I also listen to podcasts about Rails, Clojure, and Scala.  The Scala podcast is by far the most academic; taking a shot every time they say the word “type” makes for a pretty nice drinking game.

    I must admit I like academic and theoretical discussion as much as the next guy, but I worry about how little attention is paid to practical matters.  NodeUp on the other-hand is almost completely about practical things: libraries, frameworks, scaling, deployment, etc.  I’ve found them all to be pretty informative.  The Rails podcast is also fairly practical, but they do tend to cover object-oriented design patterns from time to time.  I admit that JavaScript and Ruby aren’t exactly paradigm-shifting languages, but still, programming is about more than just the mathematics.

    For example, the Scala world has two great web frameworks: Lift and Play.  It would be nice to hear how they feel, not just about how type safe they are.  Granted type safety is one of the main reasons I’m interested in Scala over node/ruby, but programming is about tradeoffs.  Things like programmer productivity anecdotes are really worth something to new-comers and are a great fit for a discussion-centric medium like a podcast.

    If Scala is going to become a mainstream language, there needs to be more discussion on these touchy-feely and practical subjects. If you know any, please let me know in the comments.  Podcasts about Scala are really hard to find.


  3. Password Maker

    July 17, 2011 by Eduardo Gonzalez

    With all the recent database compromises going on lately, I’ve decided to step my passwords up a notch.

    My old “password scheme” was pretty simple, I had 4 different levels of passwords so that if a lower one got compromised the more sensitive passwords would still be safe.  The flaw in this scheme is that if one of your sensitive passwords are exposed then all your other sensitive sites are.  I used to think that my banking websites would have pretty hardened systems, but that’s not necessarily the case.

    The only safe way to handle passwords online is to have a unique password for every site you use.  A lot of people complain that memorizing passwords is hard, but I find it actually pretty easy (I memorized thousands of Kanji after all). The real hard part is remembering which password you used for what site.  When you have 4 passwords, you can just iterate through them without getting locked out but it doesn’t work when you have tens or hundreds of passwords to try.

    Luckily there are a few companies with products to solve this problem. I looked at services like LastPass and 1Password. 1Password was way to expensive and LastPass was hard to use, ugly, and for some inexplicible reason stored your passwords on a server.  No matter what encryption they use today, it’ll be completely inadequate in 5 or 10 years.

    Enter PasswordMaker, it’s an open-source extension for Firefox that generates passwords for websites based on the URL of the site you are visiting hashed with a master password.  This is probably the only scalable solution to the password problem.  It also does this without storing your password anywhere which makes it the most secure solution I’ve found yet. Plus the algorithm for generating passwords is simple so if I’m ever in some kind of a pinch, I can regenerate my passwords by hand (with the help of the md5 utility).

    The main problems with PasswordMaker is that it doesn’t work very well on mobile phones.  There’s an Android port, but it’s about as bare as can get.  It could use some UX love. For example, It could take advantage of Android’s Share intent to get rid of the whole URL input dance that you have to do now.

    Although this setup is working for me without too much pain, I still think that the whole username/password system is way too complicated.  The fact that I need a program to manage them definitely makes it a smell.  I loved OpenID, but apparently it’s also too complicated for users, so now I’m really rooting for Mozilla’s recently announced BrowserID.  As more and more software and services move to the cloud, BrowserID, or something like it, is pretty much going to be required to keep login-creep at bay. It should help reduce the anxiety that people like my wife have when thinking about whether or not they should sign-up for some new site.