A simple script that’ll toggle your System Preferences proxy settings on a Mac. It takes one argument- the name of the interface on which to toggle the proxy (eg, ‘Airport’ or ‘Ethernet’). You can easily wrap this with an automator script using the “Get specified text” action to provide the argument and the ‘Shell Script’ action to run the script.

Uses growl to notify you of what it’s done. That can be removed if you want- just delete the end of the script below the relavent comment.

How

Nothing too complex here- uses the mac command line ‘networksetup’ tool, which allows command-line modification of network setting, to get and set the proxy state. Then it uses the mac command line ‘osascript’ tool, which runs apple script, to notify growl. The applescript in question just registers itself, then sends the message.

Code

# Get current status
interface=$1
status=`networksetup -getsocksfirewallproxy $interface | grep "^Enabled: [a-zA-z]*$"`
echo "status=$status"
if [ "`echo $status | grep "No"`" ]; then
    newState="on"
else
    newState="off"
fi

# Set new state
networksetup -setsocksfirewallproxystate Airport $newState

# Print message (delete after here to remove growl notification)
if [ "$status" ]; then
    message="$interface socks proxy is now $newState"
else
    message="Error toggling socks proxy on interface:'$interface'"
fi
osascript -e 'tell application "GrowlHelperApp"' -e 'set the allNotificationsList to {"Toggled"}' -e 'set the enabledNotificationsList to {"Toggled"}' -e 'register as application "Proxy Toggler" all notifications allNotificationsList default notifications enabledNotificationsList' -e "notify with name \"Toggled\" title \"Toggled\" description \"$message\" application name \"Proxy Toggler\"" -e 'end tell'

You’d think that encryption is in encryption- AES is AES, DES is DES, etc. Encrypt with scheme X, decrypt with scheme X, and it comes out clean. Turns out, though, that it’s not that easy. Or rather, it is, but the relevant libraries on different platforms like to do things different. Consider that to encrypt/decrypt something with AES you need:

• To use the same mode (CBC, EBC, etc)
• The same block type for block cipher modes
• The same key size (128 bit, 256 bit, etc)
• The same key (of course)
• The same initialization vector
• To know whether the library pads/truncates your key
• To know whether/how the library hashes your key
• To know whether the library includes necessary extra information (plaintext size and IV) in its output or whether you need to keep track of that yourself
• To know whether your ciphertext output it hex, base64 encoded, UTF8, or whatever.

In further fun, the libraries you’re looking at may only expose half of these variables and just pick their own numbers for the other half.

So, when you need to encrypt something client-side and decrypt it in, say, PHP, it’s not as simple as you’d like.

Quick Aside

Why would you want to encrypt client-side! That’s insane! Well, the short version is that I’m not hiding data from bad guys- I’m hiding it from my own system. What’s happening is that the user is entering credential information for an external system. That includes a username + password, plus some variable other stuff. The variable other stuff (VOS for now) is what needs to get encrypted. The username and password are already treated with kid gloves in our system- they’re not saved, they’re blocked out if a dev tries to log them, etc. The VOS, though, is new, and we’re passing it back as part of a complex data object that isn’t treated carefully- it could end up in analytics, logs, dump files, emails, etc. As such, we’re encrypting it client-side with the user’s password and decrypting it just before we need to send it to the external system (a point at which we also have the user’s password). As such, if it accidentally gets logged or something, it’s not stored in the clear.

Solution time

Not that complex, just putting it here because there didn’t seem to be a good ready-made recommendation anywhere I google.

I ended up using SlowAES, which is fast enough for many purposes. It comes with parallel implementations in PHP, JS, Python and Ruby. They each take the same parameters and use the same utilities, so it’s easy to get them to line up. To save you some time, here’s a simple use example for PHP and JS (not thoroughly tested because we decided to go for another solution before this made it to that point, but anyway):

encrypt.php

<?php
require( 'slowaes/php/aes_fast.php');
require( 'slowaes/php/cryptoHelpers.php');

/*
 * Encrypts and decrypts plaintext with a given key.  Written to be compatible
 * with it's counterpart in js.  Uses AES.  Uses the slowAES encryption lib,
 * which is more than fast enough for our purposes; using it here because it
 * has several parallel versions in different languages (mainly php and js).
 *
 * Usage: Encrypt takes any string as the plaintext and any string as the key.
 *      Decrypt takes the output of encrypt and the same key used to encrypt.
 *
 * Details you might care about:
 *      The encryption output is really 3 space-seperated strings: 
 *      - The length of the original plaintext string as an integer
 *      - The Initialization Vector (iv).  This is just a random string that
 *        will be different each encryption, and can be sent in the clear
 *        with the ciphertext.  This is a hex string.
 *      - The ciphertext itself, as a hex string.
 *
 * Crypto details you won't care about unless you're setting up another set of
 * methods to match these ones:
 *      - AES (Rijndael, or very close, I think)
 *      - 256 bit key
 *      - 128 bit IV
 *      - CBC mode
 *
 **/
function encrypt( $plaintext, $key ){

    // Set up encryption parameters.
    $plaintext_utf8 = utf8_encode($plaintext);
    $inputData = cryptoHelpers::convertStringToByteArray($plaintext);
    $keyAsNumbers = cryptoHelpers::toNumbers(bin2hex($key));
    $keyLength = count($keyAsNumbers);
    $iv = cryptoHelpers::generateSharedKey(16);

    $encrypted = AES::encrypt(
        $inputData,
        AES::modeOfOperation_CBC,
        $keyAsNumbers,
        $keyLength,
        $iv
    );

    // Set up output format (space delimeted "plaintextsize iv cipher")
    $retVal = $encrypted['originalsize'] . " "
        . cryptoHelpers::toHex($iv) . " "
        . cryptoHelpers::toHex($encrypted['cipher']);

    return $retVal;
}

function decrypt( $input, $key ){

    // Split the input into its parts
    $cipherSplit = explode( " ", $input);
    $originalSize = intval($cipherSplit[0]);
    $iv = cryptoHelpers::toNumbers($cipherSplit[1]);
    $cipherText = $cipherSplit[2];

    // Set up encryption parameters
    $cipherIn = cryptoHelpers::toNumbers($cipherText);
    $keyAsNumbers = cryptoHelpers::toNumbers(bin2hex($key));
    $keyLength = count($keyAsNumbers);

    $decrypted = AES::decrypt(
        $cipherIn,
        $originalSize,
        AES::modeOfOperation_CBC,
        $keyAsNumbers,
        $keyLength,
        $iv
    );

    // Byte-array to text.
    $hexDecrypted = cryptoHelpers::toHex($decrypted);
    $retVal = pack("H*" , $hexDecrypted);

    return $retVal;
}

/**
 * Some simple testing code
 **/

$plaintext = "Testing the php encryption/decryption. Unicode LOD: ಠ_ಠ!";
$key = "multipass!";
$cipherText = encrypt($plaintext,$key);
$result = decrypt($cipherText,$key);
?>
<!doctype html>
<html lang="en"><head><meta charset="UTF-8"></head><body>
    <h1>Encrypting</h1>
    <b>plaintext:</b> <?= $plaintext ?> <br>
    <b>key:</b> <?= $key ?> <br>
    <b>raw cipherText:</b> <?= $cipherText ?> <br>
    <h1>Decrypting</h1>
    <b>result:</b><?= $result ?>
</body></html>

encrypt.js.html

/**
 * An encryption setup to match our server-side one; see there for
 * documentation on it.
 **/
function decrypt(input, key){

    // Split the input into its compontents
    var inputSplit = input.split(" ");
    var originalSize = parseInt(inputSplit[0]);
    var iv = cryptoHelpers.toNumbers(inputSplit[1]);
    var cipherIn = cryptoHelpers.toNumbers(inputSplit[2]);

    // Set up encryption parameters
    var keyAsNumbers = cryptoHelpers.toNumbers( bin2hex( key ) );

    var decrypted = slowAES.decrypt(
        cipherIn,
        slowAES.modeOfOperation.CBC,
        keyAsNumbers,
        iv
    );

    // Byte-array to text
    var retVal = hex2bin(cryptoHelpers.toHex(decrypted));
    retVal = cryptoHelpers.decode_utf8(retVal);

    return retVal;
}

function encrypt( plaintext, key ){

    // Set up encryption parameters
    plaintext = cryptoHelpers.encode_utf8(plaintext);
    var inputData = cryptoHelpers.convertStringToByteArray(plaintext);
    var keyAsNumber = cryptoHelpers.toNumbers(bin2hex(key));
    var iv = cryptoHelpers.generateSharedKey(16);

    var encrypted = slowAES.encrypt(
        inputData,
        slowAES.modeOfOperation.CBC,
        keyAsNumber,
        iv
    );

    // Set up output format (space delimeted "plaintextsize iv cipher")
    var retVal = plaintext.length + " "
        + cryptoHelpers.toHex(iv) + " "
        + cryptoHelpers.toHex(encrypted);

    return retVal;
}

// Equivilent to PHP bin2hex
function bin2hex (s) {
    var i, f = 0,
        a = [];

    s += '';
    f = s.length;

    for (i = 0; i < f; i++) {
        a[i] = s.charCodeAt(i).toString(16).replace(/^([\da-f])$/, "0$1");
    }

    return a.join('');
}

// Equivilent to PHP hex2bin
function hex2bin(hex) {
    var str = '';
    for (var i = 0; i < hex.length; i += 2)
        str += String.fromCharCode(parseInt(hex.substr(i, 2), 16));
    return str;
}

/**
 * Some simple testing code
 **/
$(function(){
    var key = "multipass!";
    var plaintext = "Testing the php encryption/decryption. Unicode LOD: ಠ_ಠ!";
    var output = "";
    var cipherText = encrypt(plaintext,key);
    var newPlaintext = decrypt(cipherText,key);
    output += ("<br>plaintext=" + plaintext);
    output += ("<br>cipherText=" + cipherText);
    output += ("<br>newPlaintext=" + newPlaintext);

    $('#output').html(output);
});

Remember that this is probably neither efficient nor elegant. It hasn’t been tested extensively, so use at your own risk. Should do the job, though. The full code is zipped up here: JSPHPEncryption 2.zip

1. Install proj4, the 80’s-era c library that everything relating to geospatial coordinate transformations seems to be built on. This is related to and possibly the basis for, but not actually the same thing as gdal. Gdal has some handy command-line tools in case you don’t need to do this programmatically. Further, it takes similar projection strings as proj4.

   Anyway, build it from source. I had no trouble on Mac OS 10.6.

2. Install the ruby bindings. I had to build from source here (ruby 1.9.2) too- their build instructions were pretty handy. Just go through the configure/make/make install stuff, then rake as a gem, then gem install that local gem.

3. Code it up:

   require 'proj4'
   proj = Proj4::Projection.new '+proj=tmerc +lat_0=40 +lon_0=-78.58333333333333 +k=0.9999375 +x_0=350000 +y_0=0 +ellps=GRS80 +units=ft +no_defs'
   geox = 1394144.401
   geoy = 1165107.387
   latlon = proj.inverse Proj4::Point.new(geox,geoy)
   converter = (180 / Math::PI)
   puts "lat = " + (latlon.lat * converter).to_s
   puts "lon = " + (latlon.lon * converter).to_s
   

Note that geox and geoy are the inputs. The string of parameters in the call to Projection.new is what defines the initial projection (that is, the state plane) that the input is on. You’ll want to replace that with the one for your state. To get that info:

1. Go to http://home.comcast.net/~rickking04/gis/spc.htm and look up your FIPS zone. Mine is 3103, since my data is for Monroe county, NY.
2. Go to http://spatialreference.org/ref/esri/ and enter your state. There should be a short list of results, one of which has your FIPS zone in it. Mine is “ESRI:102317: NAD 1983 HARN StatePlane New York West FIPS 3103”. Click on it.
3. Click on the “Proj4” link, which should take you to the string you want. Mine is “+proj=tmerc +lat0=40 +lon0=-78.58333333333333 +k=0.9999375 +x0=350000 +y0=0 +ellps=GRS80 +units=m +no_defs”. Note that you may need to change the ‘units’ element in that string- mine was in feet, which is ‘ft’.

In this example, insertToDOM just adds the code as the content of a script element to the element (this code uses JQeury, but you could easily do it without.

function insertToDOM(code){
    $("head").append( $('<script language="javascript">' + code + '</script>'));
}

Now, to get all user-defined functions, we need to filter out all the normal javascript functions. In this case, we’re analyzing the function bodies- built-in functions will have bodies containing “[native code]”, so we can just get rid of those. Everything that reaches the console.log(window[f].toString()); line will be a user-defined function. Note that the toString method called on a function object will return its body.

insertToDOM(
    'for (var f in window){'+
        'bodyString = window[f]!=null ? window[f].toString() : "";'+
        'if(bodyString.indexOf != null && bodyString.indexOf("[native code]")==-1 && bodyString.indexOf("function ")!=-1 ){'+
            'console.log(window[f].toString());'+
        '}'+
    '}'
);

Irrelevant background

This code is part of an ongoing christmas javascript war I’m having with the webmaster of a forum I frequent. He annually covers his site with christmas themed decorations and obnoxious mouse-following reindeer. I wrote a chrome plugin to revert it. He wrote a script to detect my code and redirect to internet shock sites if it’s found. We’ve been going back and forth recently- he’ll fix his code, I’ll fix mine. This is my latest blow- a variant on this detects if the function body contains redirect code and kills the function if it does. I could just fix my code following his next move and then just stop publishing my code, but where’ the fun in that? :D

Code for the above plugin, if anyone’s interested, can be found at https://sse.se.rit.edu/hg-manage/kmk3817

Edit: For a later version of this I threw together an insertToDom function that takes a function object, chops out the body, and inserts that. So, passing in “function(){alert(“test”);}” will add “alert(“test”)” to the DOM in a script element.

function insertToDOM(func){
    //everything between the first and last brackets.
    funcString = func.toString();
    funcStringArray1 = funcString.split("}");
    funcStringArray1.pop();
    funcString = funcStringArray1.join("}");
    funcStringArray2 = funcString.split("{");
    funcStringArray2.shift();
    funcBody = funcStringArray2.join("{");
    $("head").append( $('<script language="javascript">' + funcBody + '</script>'));
}

Of course, we all know that holding on to quality developers means keeping them challenged, paying them highly, throwing them cool technology, etc. That said, we’re not all made of money, so here’s a few cheap tricks that buy a lot of developer love for not much money.

Free food

Give your employees a free dinner once every month or two. Somewhere nice and a little highly-priced, but not someplace they have to dress up. High-quality barbecue joints or steakhouses are decent choices. A lot of the common-folk consider a meal around $50 a head to be too pricy to treat themselves, so it’s pretty great when it’s gifted from management. Remember, you paid them 100 times that amount this month alone (assuming 60k a year). It’s a gift you don’t even have to do on company time, and gets a lot of bang for a tiny cost.

Dual Monitors

A number of sites and studies espouse the productivity virtues of multiple monitors- they easily make up for a $100 investment on that alone. Further, though, developers enjoy using them. Again, you’re paying them $60,000 a year- you can afford to give them a tool they love that’s been shown to increase productivity up to 44%, lasts 3+ years, and costs 0.16% of a developer’s annual pay.

Free Coffee

It may seem like a small thing, but one nicety I’ve heard programmers and IT workers complain about endlessly is the lack of free coffee. It’s a little weird, considering how cheap home coffee-makers are (got mine for $12 at a thrift store), and how cheap making one’s self a cup is. That said, developers seem to love having it on hand in the office, and I can hardly fault them- they get up early, come in, and sit without much movement for the next 4 hours. Anyway, you can get a high-end office-oriented single-cup maker for $500, or $17 a head in a 30-person office. Hell, even a cheap home-oriented brewer (<$50) kept well supplied will do the job (though the wasted time for high-paid developers to set up and brew pots may not be worth the savings).

Decent Chairs

A rower notices the rowboat. A pilot notices his cockpit. When I tour a potential job, I notice the chair I’m going to spend 40 hours a week in. Yes, good chairs are stupidly expensive ($750 for the famous Aeron chair), but quality chairs stand out. There’s talk about improved back health, productivity, etc, but the biggest advantage is their attractiveness to new and old developers. They signal that the people in management care about the day-to-day physical needs of developers (even though we all know you just want more work out of us). At a dollar a week (assuming a 10 year lifespan), that Aeron chair is a solid investment- cheaper than (as Joel Spolsky points out) your average toilet paper expenditure.

There, that wasn’t so bad, was it? I didn’t suggest that everyone get private offices, litter the place with beanbags, or have catered sushi every day. These are simple things, and you can do them without really high-level approval. They’ll reduce turnover, increase productivity, and attract brighter minds- in short, they’ll pay for themselves.

“When do you comment?”

Most opinions I’ve seen have fallen into one of a few categories:

1. Real men don’t need comments
2. The code should be self-documenting
3. Comment on design decisions (the ‘whys’ of code blocks)
4. Comment on the what blocks of code are doing (the ‘whats’ of code blocks)
5. COMMENT EVERYTHING!!!!1!!1ONE11!1!!

Few reasonable people hold position 5, and the people holding position 1 aren’t likely to turn away from their RPC-4000 to care what some wet-behind-the-ears, object-oriented, virtualizing, abstracting, greenhorn youngin’ like me has to say.

Self Documenting Code

The general argument is that clear method/parameter/variable/etc names, clean well-formatted code, and well structured source are sufficient for the sort of low-level documentation you see.

The Pros are pretty clear- less commenting means less stuff to keep up to date and in sync with the code.

Commenting just makes the source file twice as long.

However, no one is perfect. Your code is never ultimately well structured, named, and formatted. If you think it is and I have to deal with your code later, I want to track you down and light your face on fire. Unless you’re the perfect lovechild of Steve McConnell and Erich Gamma, then your naming, structure, and formatting will be incomplete, and I will hate you. You’re better off assuming you suck and commenting as such.

Comment on design decisions

The idea here is that you’d comment on how a method or block of code fits in with the rest of system. Obviously you don’t want a complete design document in the comments for every method, but you might want to point out specific gotcha’s and the code’s general role in the system.

The Pro’s to this are that it helps someone going through the code understand the possible ramifications of changes, especially if they’re non-obvious.

The problem with this approach is that it’s hard to keep up to date. That’s true of any documentation, but comments are supposed to be the closest thing to the code itself. Comments that reflect not just changes to the code at hand but also the rest of the system are difficult to keep current. If code in modules A, B, and C all discuss what module D does (in relation to how they interact with it), then they all have to be updated when module D is changed or repurposed.

Comment on function

Pretty simple - comment on what a block of code or method does. You see this formalized in Javadocs.

The main argument against this tact is that it should be unnecessary. Programmers can read code, why do we need text to tell us what code does?

I would argue that we don’t want to take the time to read your code and figure out what it does. If I’m skimming through a dozen foreign thousand-line class files, I don’t want to have to read every line in them just to find the one block that modifies X; it’d be nice to be able to skim through comments to find “//This section deals with X.”

In another case, your code may just be too dense to be read quickly. I can figure out what your line-noise regex does, but unless you deal with it constantly it’ll take a minute- it’d save me some time if you took 20 seconds to give dense code a brief description. The same can go for any unusually clever or cryptic piece of code: yes I can read it, but I’m looking at this source to find information, not marvel at how clever you thought you could be.

Whaddaya say?

So which style’s best? It really depends on how you and your development team work. Some things to consider:

• How good is your external documentation?
• How big is your codebase?
• Is your architecture clear enough that the consequences of most changes are obvious?

Personally, I try to err on the side of more commenting- while I’ve seen some egregious examples of over-commenting, those are few and far between. Under-commenting, though, I’d bet we’ve almost all been burnt by.