Let software developers develop software, don’t hog them with repeated configuration/administration stuff.

This rule is violated with large-scale Cocoa development for the iPhone that also has beta testers: If you want to allow them, you need something like HockeyApp (or TestFlight, but we didn’t use that one). Further, somebody might break the build without realizing it (that’s not specific in any way to Cocoa development). Different versions of Xcode use different compilers, which might not accept the same source code.

Apple sketched a solution for some of these problems in WWDC 2012, session 404: You can integrate Xcode into Jenkins CI, a continuous integration platform written in Java. We chose to improve on this solution, to let it do much more.

What you need:

• A build server that runs Mac OS X, accessible by all developers and itself able to access the HockeyApp website.
• A server runnig git. This might be the same server as the above, but doesn’t have to be. Our instructions are for the case where it’s on the same server, as this is easier to do (only “localhost” as hostname).
• Development must happen using git & Xcode (we tested version 4.3, 4.4DP4 and 4.5DP2)
• A very solid knowledge of the command line, since just about everything will be done there.

What this solution provides:

• On every push, the app is checked for build errors (and the test suites can be run, if you happen to have some).
• Working versions are automatically tagged, so you can easily correlate build logs to the git history.
• Pushing a release to HockeyApp only requires adding a tag to a revision before pushing it to the server.

Some ideas in what way this solution can be extended very easily:

• Push working git revisions to a different git server.
• Email a build breaker to communicate this fact.

Concepts

The system is configured so that on every push of a new commit, Jenkins downloads the revision and builds it. When it works, Jenkins also tags it with the name jenkins_<build number>. The build number is also displayed in its web interface.

When you push, and the HEAD is also tagged with release_<major>_<minor>_<patch> (where all the <> are numbers, everything except the major number are optional), Jenkins automatically uploads the result to HockeyApp. Supply your release notes as the message for that tag (-m on the command line).

The most recent release_-tag in the commit tree is used to update the version number inside the Info.plist of the application (no matter whether it is uploaded to HockeyApp or not).

Initial Setup

Obviously, you need Xcode installed on your build server. Note the application name of all the versions you have installed (for example, “Xcode45-DP2″). Xcode comes with git, which is very handy.

First, I installed gitolite for easy repository configuration. For this, we need a git user first.

To keep things as minimalistic as possible, this is not a regular user as created by the UI, we created it using the command line (as root):

First, create the group:

dscl . create /Groups/git PrimaryGroupID 1025

The unique ID was chosen based on not having a conflict with the other groups.

Next, create the user:

dscl . create /Users/git
dscl . create /Users/git UserShell /usr/bin/false
dscl . create /Users/git RealName git
dscl . create /Users/git UniqueID 1025
dscl . create /Users/git PrimaryGroupID 1025
dscl . create /Users/git NFSHomeDirectory /Users/Shared/git
dscl . append /Groups/git GroupMembership git

The unique ID was chosen based on not having a conflict with automatically created users. Afterwards, create the user’s home directory at /Users/Shared/git, and change its owner and group to git:git.

You might want to use /bin/bash as the shell instead as long as you’re setting the whole system up, it makes things a bit simpler. Without it, you can change the active user (as root) to git with

sudo -u git -s

Which unfortunately doesn’t update the whole environment (like $HOME). If you have a proper shell, you can use -i instead of -s, which does update everything.

gitolite includes a nice installation setup in its README.txt. Just follow the (short) instructions there, then create a new repository for your project (we called ours “CIDemo”).

Jenkins is easier to do (with a caveat, see next paragraph), since there’s a fully-fledged installer for Mac OS X available. We just used that one, and it worked fine. Select using a separate jenkins user (it will be created automatically).

You need at least version 1.439 of Jenkins. Right now, this version is not released yet. Thus I had to fetch the version 1.437 from github, and cherry-pick the one fix that’s required, a811f406e785a8c8e6cb4b9246829dce9c7b97ae. Otherwise, restarting Jenkins removes the jobs due to a parsing error.

Keychain Fun

Since you want to sign your apps, you have to supply the signing keys and the provisioning profile. The profile you can just copy to ~jenkins/. For the script below, we use the file name “${HOME}/Development.mobileprovision“.

The certificate and private key are more complicated, since they have to be in a keychain. Since the jenkins user does not have UI support, you can’t just log in and use Keychain Access.

The solution I found was to launch Keychain Access from your regular user, setup the keychain there and then copy it to the jenkins user. Use “New Keychain” from the File menu (name it something like “jenkins”, use whatever password you want), then option-drag you developer certificate(s) to the new one. Then, delete the keychain (but do not remove it from the file system), and then in the shell, copy ~/Library/Keychains/jenkins.keychain to ~jenkins/Library/Keychains/login.keychain (create the directory on the destination, and also change the owner and group to jenkins). Don’t forget to set the keychain permissions to 600. Then, you can set this keychain as the default and remove the password (this is not possible from the UI):

security default-keychain -d user -s login.keychain
security set-keychain-password

The old password is the one you entered when you created it, just press return for the new one.

Jenkins Setup

In Jenkins’ web interface (port 8080 on the machine), add the following plugins:

• Jenkins GIT plugin
• Post Build Task

In the Jenkins configuration, in the “Git” section, change the git executable path to “/Applications/{your Xcode appname}.app/Contents/Developer/usr/bin/git“. In the “Git plugin” section, set up “Global Config user.name Value” and “Global Config user.email Value”. Also setup the SMTP setup for the email notifications there.

Also, you should enable security in the configuration, with whatever system you like. Otherwise, everyone who can reach this server via HTTP can execute arbitrary shell commands as the jenkins user, which is kinda bad.

Back on the command line, create a (standard) ssh key for the jenkins user (use sudo like explained above to switch to that user). Add its public key to your project in gitolite (with RW permissions).

You also have to accept the Xcode license agreement for all users on the system, which can be done on the command line:

sudo xcodebuild -license

Next, we created a new job in the Jenkins web interface with the “Build multi-configuration project” type. Name it distinctively.

In the “Source Code Management” section, select git. The repository URL is “git@localhost:{project name}.git” (see your gitolite config). In the Advanced section there, enter “origin” as the name. In “branches to build”, you can enter what fits your build workflow. We entered “master“.

In “Build Triggers”, activate “Poll SCM”. This doesn’t really poll, but it enables automatic building after a push.

In “Configuration Matrix”, add two dimensions:

• name=XcodeApplication, values=Xcode Xcode44-DP4 Xcode45-DP2
• name=SDKName, values=macosx iphone iphonesimulator

Of course, you have to alter these to fit your setup (which Xcode apps and which platforms you want to build-test). The values for the SDKs are defined by Apple, so you usually don’t want to change them.

Push “Add build step”, “Execute shell”. Insert the following script:

#!/bin/bash
export DEVELOPER_DIR=/Applications/${XcodeApplication}.app/Contents/Developer
security unlock-keychain -p "" login.keychain
if [ "${SDKName}" == "macosx" ]; then
  SchemeName="CIDemo Mac"
else
  SchemeName="CIDemo iOS"
fi
xcodebuild -workspace CIDemo.xcworkspace \
  -scheme "${SchemeName}" -sdk "${SDKName}" \
  -configuration Release \
  DSTROOT=$WORKSPACE/build.dst \
  OBJROOT=$WORKSPACE/build.obj \
  SYMROOT=$WORKSPACE/build.sym \
  SHARED_PRECOMPS_DIR=$WORKSPACE/build.pch

Next is adding the automatic tagging of succeeding builds (or all builds, whatever you think is reasonable).

In “Post-build Actions”, add Git Publisher. There, activate “Push Only If Build Succeeds” (if you want that), in Tags, use “Tag to push:” = “jenkins_$BUILD_NUMBER“. Create new tag active, “Target remote name” = “origin“.

Next, add “E-mail Notification”, and configure it to your liking.

The post build task to add is a bit more complicated (you might want to leave this for now and add it later). It involves uploading the result to HockeyApp (but only the iOS version built on Xcode 4.3 here):

#!/bin/bash
# by Andreas Monitzer (@anlumo1) and Pepi Zawodsky (@MacLemon)
#

# This script published under WTF license
# http://en.wikipedia.org/wiki/WTFPL
# Improvements to this script are welcome though.
if [ "${SDKName}" == "iphoneos" -a "${XcodeApplication}" == "Xcode" ]; then
 	TAG=$(git describe --exact-match --match "release_*" 2> /dev/null)
  	if [ "$?" -eq "0" ]; then
 		# publish the app
 		# get tag annotation to use as the release notes
 		NOTES=$(git tag -l -n9999 $TAG|sed -e "s/^$TAG//;s/^ *//")
  		API_TOKEN="<HockeyApp API token>"
 		SIGNING_IDENTITY="iPhone Developer"
 		PROVISIONING_PROFILE="${HOME}/Development.mobileprovision"
 		PRODUCT_NAME="CIDemo"
  		DSYM="$WORKSPACE/build.sym/Release-iphoneos/${PRODUCT_NAME}.app.dSYM"
 		APP="$WORKSPACE/build.sym/Release-iphoneos/${PRODUCT_NAME}.app"
  		HOCKEY="$WORKSPACE/build.HockeyApp/"
 		mkdir "$HOCKEY" 2> /dev/null
  		echo "Creating .ipa for ${PRODUCT_NAME}..."
  		/bin/rm -f "${HOCKEY}${PRODUCT_NAME}.ipa"
 		/usr/bin/xcrun -sdk iphoneos PackageApplication \
 					   -v "${APP}" \
 					   -o "${HOCKEY}${PRODUCT_NAME}.ipa" \
 					   --sign "${SIGNING_IDENTITY}" \
 					   --embed "${PROVISIONING_PROFILE}" > ${HOCKEY}${PRODUCT_NAME}.log
  		echo "Zipping .dSYM for ${PRODUCT_NAME}..."
  		/bin/rm -f "${HOCKEY}${PRODUCT_NAME}.dSYM.zip"
 		/usr/bin/zip -r "${HOCKEY}${PRODUCT_NAME}.dSYM.zip" "${DSYM}"
  		echo "Uploading to HockeyApp..."
  		/usr/bin/curl "https://rink.hockeyapp.net/api/2/apps/<HockeyApp app id>/app_versions" \
 					  -F "status=2" \
 					  -F "notify=0" \
 					  -F ipa=@"${HOCKEY}${PRODUCT_NAME}.ipa" \
 					  -F dsym=@"${HOCKEY}${PRODUCT_NAME}.dSYM.zip" \
 					  -F notes="${NOTES}" \
 					  -H "X-HockeyAppToken: ${API_TOKEN}"
  		echo "Uploaded to HockeyApp" 	fi fi

It’s important that you actually understand what this script is doing, so you can alter it to fit your needs!

Git Setup

What’s missing here is informing Jenkins that a new commit was pushed. For this, you have to create a new file in “/Users/Shared/git/repositories/<project name>.git/hooks” called post-receive. This is the content:

#!/bin/bash
curl http://localhost:8080/git/notifyCommit?url=git@localhost:<repository name>.git

As you can see, you could easily change this to inform another server about the new push (this is a common issue with automatic build actions which have to run a script locally to trigger something). Set this script to 755 permissions.

Updating the Bundle Version

In every OS X and iOS project you need to access certain information from the Info.plist present in every .app bundle. Some of that information is automatically created by Xcode, other stuff you need to provide manually, like entering a version number for your app in Xcode. Every time you have to manually add fields or increase a version number this is not only error prone but simply annoying.

Screenshot of Xcode Target settings showing the Version and Build fields with 1.0.

This is why this script takes care to add all the useful information like a build revision and git short hash to the Info.plist automatically. This not only works for automated build systems like Jenkins but also for local builds.

Version numbers are taken from a git tag in the form of release___. You can add a release version tag by running this command: git tag -a "release_2_4_8". You’ll be prompted to enter release notes for this tag and if you’re using Hockey they will be used there automatically as well. Nifty! Don’t forget to push your new tag to the build server by issuing git push --tags origin.

This script needs to be added as a “run script” build phase in Xcode.

#!/bin/bash
# by Andreas Monitzer (@anlumo1) and Pepi Zawodsky (@MacLemon)
#
# This script published under WTF license
# http://en.wikipedia.org/wiki/WTFPL
# Improvements to this script are welcome though.

# Augments the Info.plist with a lot of nice stuff.
# It's suggested to call this script from a "run script" build phase, not copy the script's contents there.

# All Values are available from Objective-C like this:
# Example
# NSDictionary *infoPList = [[NSBundle mainBundle] infoDictionary];
# NSLog(@"CFBundleShortVersionString: %@", [infoPList objectForKey:@"CFBundleShortVersionString"]);

 echo "Checking for file ${PROJECT_DIR}/.git"

# When using git SCM
if [ -e "${PROJECT_DIR}/../.git" ]
then

    # Get a svn-like revision number that keeps increasing with every commit.
    REV=$(git log --pretty=format:'' | wc -l | sed 's/[ \t]//g')
    echo "git rev: $REV"

    # Getting the current branch
    GITBRANCH=$(git branch | grep "*" | sed -e 's/^* //')
    echo "Git Branch: $GITBRANCH"
    # To prevent local builds from displaying incorrent branches we need to delete and readd.
    /usr/libexec/PlistBuddy -c "Delete :GitBranch string" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"
    /usr/libexec/PlistBuddy -c "Add :GitBranch string $GITBRANCH" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"

    # full build hash
    GITHASH=$(git rev-parse HEAD)
    echo "Git Hash: $GITHASH"
    /usr/libexec/PlistBuddy -c "Delete :GitHash string" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"
    /usr/libexec/PlistBuddy -c "Add :GitHash string $GITHASH" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"

    # commonly used short hash
    GITHASHSHORT=$(git rev-parse --short HEAD)
    echo "Git Hash Short: $GITHASHSHORT"
    /usr/libexec/PlistBuddy -c "Delete :GitShortHash string" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"
    /usr/libexec/PlistBuddy -c "Add :GitShortHash string $GITHASHSHORT" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"

    # parsing tags to build the CFBundleVersion in the form of <MAJOR>.<MINOR>.<PATCH>.<REV>
    # Parts of the version number that are missing are substituted with zeros.
    NEAREST=$(git describe --abbrev=0 --match "release_[0-9]*")
    echo "Nearest release Tag: \"$NEAREST\""

    MAJOR="0"
    MINOR="0"
    PATCH="0"
    if [ "$NEAREST" == "" ]
    then
        echo "No release tag found!"
    else
        MAJOR=$(echo $NEAREST | cut -d "_" -f 2)
        if [ $MAJOR == "" ]
        then
            MAJOR="0"
        else
            MINOR=$(echo $NEAREST | cut -d "_" -f 3)
            if [ $MINOR == "" ]
            then
                MINOR="0"
            else
                PATCH=$(echo $NEAREST | cut -d "_" -f 4)
                if [ $PATCH == "" ]
                then
                    PATCH="0"
                fi
            fi
        fi
    fi

    echo "Version String: $MAJOR.$MINOR.$PATCH.$REV"

    # Setting in the Info.plist file
     /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $MAJOR.$MINOR.$PATCH.$REV" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"
     /usr/libexec/PlistBuddy -c "Set :CFBundleShortVersionString $MAJOR.$MINOR.$PATCH.$REV ($GITHASHSHORT)" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"

    # Setting the same version number in the .dSYM file needed for symbolication in the Hockeyapp.net webinterface
     /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $MAJOR.$MINOR.$PATCH.$REV" "${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Info.plist"
     /usr/libexec/PlistBuddy -c "Set :CFBundleShortVersionString $MAJOR.$MINOR.$PATCH.$REV ($GITHASHSHORT)" "${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Info.plist"

elif [ -e "${PROJECT_DIR}/../.svn" ]
then
    # Support for SVN would be happy if you'd actually implement it!
    REV=$(svnversion -nc "${PROJECT_DIR}" | sed -e 's/^[^:]*://;s/[A-Za-z]//')
    echo -n "SVN rev: $REV"
fi

if [ "$BUILD_NUMBER" == "" ]
then
    /usr/libexec/PlistBuddy -c "Delete :JenkinsBuild string" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"
    /usr/libexec/PlistBuddy -c "Add :JenkinsBuild string $BUILD_NUMBER" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"
else
    /usr/libexec/PlistBuddy -c "Delete :JenkinsBuild string" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"
    /usr/libexec/PlistBuddy -c "Add :JenkinsBuild string Local build (not via Jenkins)" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"
fi

#EOF

Wrapping Up

So, that’s as far as we’ve come. If you have any comments/additions, feel free to send them to me! I hope that the information we’ve covered here can help you construct a continuous integration solution that fits right into your development process.

There’s a lot of ways you can go from here. Maybe uploading to iTunes Connect is also something to think about, although I’d personally like that process to be a bit manual, in order to remove unintentional results.

(Note that the code covered here is under the WTFPL, but the text is not.)

This is only a quick note about the list view range selection behavior (shift-click) I’m observing in Mac OS X Lion’s Finder. There’s quite more to it than you might think!

• First off, when there’s nothing selected and you shift-click on an item, all items from the top up to the clicked one (including itself) are selected.
• When there is an existing selection, the result depends on the previous non-range selection action:
  • Regular selection: The range between that item and the clicked one is selected (including both items).
  • Deselection (cmd-click on a previously selected item): The range between the clicked item and the next selected one below it is selected. If there is none, the range between the previous selected item and the clicked one is selected.
• In the previous step, if the previously selected item is part of a contiguous range, all other items of that range are deselected.

Did I miss anything? Please tell me via Twitter (@anlumo) or comment below!

UPDATE: @5minpause pointed me to an article, describing the same behavior in a much more elaborate way: Legendary Selections, Dude

UPDATE 2: Alright, discovered another peculiarity in the Finder selection behavior: When clicking onto the file name or file icon without any modifiers, the selection is changed on mouseUp: (the previous selection is also not changed in mouseDown: yet). When either any modifier is held down or the row is clicked somewhere else, the selection is changed in mouseDown:. I guess this is implemented so that you can drag a file without changing the selection.

int a = 0;
void(^block)(void) = ^{ printf("%d", a); };
a = 1;
block();

outputs 0, because the value of a is copied to the block when it is declared.

If you want it to track the variable instead, you have to do:

__block int a = 0;
void(^block)(void) = ^{ printf("%d", a); };
a = 1;
block();

This outputs 1, as you would expect, since the block only gets a reference to a. It might look obvious this way, but consider this code:

void(^calc)(int,int) = ^(int a, int b) {
    printf("%d ", a);
    if(b<10000) calc(b, a+b);
};
calc(0, 1);

(Bonus points if you know what sequence this should output!) Since the variable block isn’t defined when the block is declared, it points to a bogus value and crashes. You have to do it this way:

__block void(^calc)(int,int) = ^(int a, int b) {
    printf("%d ", a);
    if(b<10000) calc(b, a+b);
};
calc(0, 1);

Generally, I like to read fiction, but every now and then I have to work through some nonfiction book to gain some knowledge. I’ve tried to read technical books about programming APIs etc, but in recent years I’ve found these to be quite boring, since they’re a bit too far on the basics side of things. Why should I buy and read a whole book about something I can learn with a few free online beginner’s tutorials just as well?

So, I’ve moved more into the “general concepts”-genre of nonfiction books. One big example of that is “The Art of Community” by Jono Bacon. The author is the manager of the Ubuntu community, and he shares some of his experience with the reader.

Communities are everywhere, from knitting clubs and programming workshops to political parties. There are certain rules that underlie these groups, which everybody knows instinctively. However, when you want to manage such a group, you have to know these rules explicitly, so you can act upon them. The book does a good job of giving you the feeling of what’s involved there.

The hard part about being a community manager is that you have to steer the community, without being seen as a leader. The majority of the book content is about what you have to do to get the community where you want it to be, by letting the members do what they want to do. This is done mostly by nudging and removing obstacles at the right places.

The author also provides very nice checklists for what you have to do to get things started and how to expand the community leadership into a board when it’s necessary. The chapter about governing a community is very large and reminds me a lot about our political system. However, it’s probably only relevant to a very small group of people, because communities of a size where such a system is necessary are very rare.

In general, the book tries to explain things in a general manner, so even though it’s of a technical origin, a knitting club manager can understand and apply the knowledge. However, some parts of it are probably completely incomprehensible to those. For example, there’s an extended discussion about what version control system to use, which is far too specific. In my experience, people are very bad at ignoring things they don’t understand and just give up instead, so that’s probably a roadblock for technically challenged readers. Some concrete examples also suffer from this issue, but for me they were very illustrative.

As a side effect, the book also explains the way the Ubuntu community works and its principles. That alone is very insightful, and allowed me to spot some BS in some online publications writing about Ubuntu.

So, what’s my verdict? If you know a bit about open source software development, the book is very enlightening, even when you don’t plan to manage a community, because you get a better understanding of the mechanisms that are at work in every one you are a part of (and I think everybody is part of some, even when they’re not aware of it). However, when you’re actually working on creating/expanding one, the book is great. Actually, I think everyone who is working on such a thing should read it, in order to avoid easy mistakes that can break everything. Just make sure to have to general knowledge about software development methods and open source software, otherwise you’d not understand a large part of the explanations.

The book is available as an ebook for free at http://www.artofcommunityonline.org/, but also from O’Reilly.

The imports are pretty similar to Java:

from Crypto.Hash import SHA
from Crypto.PublicKey import RSA
import base64

Note that you have to install PyCrypto for this to work. If you’re using Google App Engine, you might have a few issues with that, since the directory the library is installed to is ignored by the App Engine environment. For now I moved the library into the app directory, but I’ll have to fix that eventually.

The public and private keys can be stored as a regular integer in python:

privateKey = int("...", 16)
publicKey = int("...", 16)

This time around, python even recognizes the ’0x’ prefix, so you don’t have to remove it (but it works fine without).

The next line is the one that took me around 7h to come up with:

RSAkey = RSA.construct((self.publicKey, 3, self.privateKey))

The parameters are ‘n’, ‘e’, ‘d’, ‘p’, ‘q’, ‘u’ (I’m only supplying the first three here, the others are not needed). ‘n’ is the public key, ‘e’ is the exponent (constant 3 in AquaticPrime) and ‘d’ the private key. When I reverse-engineered the PyCrypto-code, I discovered that the right way to get my signature is actually to decrypt the message. Encrypting only uses the public key, decrypting the private key.

First, I have to hash the sorted values from the dictionary using SHA1:

hash = SHA.new("user@email.comUserCockpit 2 Single User".encode("utf-8")).digest()

I used some placeholders for the fields here, they have to be filled in for proper licenses.

Next up is decryption (signing). However, openssl uses PKCS#1 padding. Java does that automatically, PyCrypto does not, so we have to do that manually:

signature = RSAkey.decrypt('\x00\x01' + ('\xff' * 105) + '\x00' + hash)

That’s nearly the same padding code as the PHP implementation, except for the string multiplication, which was a for-loop (yay for that shortcut).

So, all that’s left here is the base64 encoding, which is quite easy again:

base64.b64encode(signature)

That’s it! All that’s left is creating the plist string again, but that’s the same as in the Java code and not that exciting.

This is actually quite easy once you have the code for it

Maybe somebody is interested in this code. It’s relatively easy to create AquaticPrime license keys in Java once you know how. I used it last year on Google App Engine to generate my licenses for a promotion.

First, you need the imports:

Next, you have to store the public and private keys in the Java class:

You can get those from the AquaticPrime Developer application. Don’t include the “0x” prefix! Use a single line for the whole key.

Next, you have to generate the data to sign. The keys-value-pairs included in the dictionary have to be sorted by key (case insensitively). For simplicity, I only did the following for my Cockpit licenses:

This data has to be hashed using SHA1:

The data has to be encrypted using RSA with the private and public keys mentioned above. For this, you first have to convert the hex strings to BigIntegers, and then create a new RSAPrivateKeySpec object out of them:

Next, the RSA cipher can be initialized:

Your final license key looks like this:

Note that there are a lot of exceptions to catch there, but the compiler informs you about them anyways

First off, a definition (since I just invented that name). I call it legally distributed, because distributed development is very common. A few years ago I worked at a company where some programmers were in Tunesia, some in Shenzen/China, some in Paris, some in Vienna, some in Bratislava, etc (nobody knew the exact amount of people involved, but it was estimated at around 200). All of those spread-out teams had to be coordinated and it wasn’t a lot of fun — some coworkers voiced their opinion that a single team in one location could have done the same work with better quality with 1/4 of people or less.

However, what I’m calling legally distributed is quite the opposite: the people are all working in the same (general) geographic area, but aren’t hired by any company which oversees the process. They’re all what is called one-person-companies (EPU) here. They’re working together on a project-by-project basis, splitting the costs, risk and earnings. This is a true agile business: For one project, you might work with person A, B and C, on another project with person D and E. This way, you always have some project going on (or more at the same time if you’re not careful), and you can always pick a team of people that have the talent for the tasks required and the necessary capacities. The risk for everyone is reduced, because it is spread around multiple projects.

Now, there’s a problem with it that causes this whole structure to be quite fragile: there’s no legal framework for any of this, except for the very basics (that you’re allowed to do business at all), which means that there’s no protection if something goes wrong. There’s no standard contract for this kind of arrangement (like there is for many other things), and nobody can afford a lawyer to write one. Most of the agreements are based on oral contracts, which any lawyer strongly disapproves of.

However, in an ever-accelerating world, this is definitely the direction software development is heading towards. Some time ago I participated in a conversation with friends of mine, and one of them mentioned that he’s been working for the same company for four years. The immediate reaction from one of the others was “What? You should look for a new job very soon, otherwise it looks bad on your CV.” Considering that my mother worked at a single company for thirty years (until they closed shops) and that’s not considered unusual in that age group, there’s a definite trend there. However, getting hired and then quitting are both lengthy processes, which is not adequate for agile project-based development. Thus, many companies have shifted to hidden employment, where you’re treated like you’re an employee, but legally are not. This is a very bad thing, because you get the worst thing of both worlds.

Of course, this one-man-company-distribution doesn’t scale all that well to more than three or maybe four people (I’ve never had more than three on a team), but when looking at software sales e.g. in one of Apple’s App Stores, it’s clear that the profits per developer are heavily favoring smaller teams nowadays anyways.

So, is that kind of development here to stay? Or will those who do it right now just found their own companies in the end, fearing the legal issues arising from it? I don’t know, but I’ll definitely stay for a while and see what will happen.

However, it completely misses the concept behind software engineering and programming itself. I think design patterns are a bit like LEGO™ pieces: You put in an iterator pattern piece, stick it to a singleton pattern piece and attach an observer pattern piece at the top, and there you have your helicopter that can be built by a five-year old.

That’s completely not how software programming is really done by professionals. When you have a problem to be solved during development, you just think about it and come up with a solution (usually within minutes). Programming has a very limited solution space, so there are a very limited number of solutions you could come up with. When you do that, you usually do something that somebody incidentally wrote down as a software pattern, even without you knowing about it. So, why should I learn those patterns? The ideas behind them come naturally when they’re needed anyways.

Maybe I should differentiate a bit at this point. There’s the MVC pattern (“Model-View-Controller”). This pattern is different, because it does not describe a class hierarchy, it describes a way of thinking. That’s what you really should learn when you want to do professional programming. Programming is not about “should I subclass this class”, it’s about “what are the general structures of my program?”. Those are things that cannot be learned by memorizing, they have to be learned by experience (and doing it wrong the first time around — that’s what antipatterns would cover). Either that, or the explanations of what to do and what not to do become very vague. There’s no UML in there! Sidenote: I actually considered writing a book about this (working title “The Art of Software Design”), but then I remembered the horrible experience of my last book attempt and let it go.

So, one of the major things I hate in blog posts is when they go on forever, without adding anything more after a point (or having tons of fillers between the important stuff), so I’ll just stop here. If you have any comments/questions/complaints, feel free to comment below, twitter me or send me an email.

Maybe I’ll visit this topic again in the future with some concrete examples (let’s call them the “Software Design Pattern Antipatterns”).

I’ve held a workshop about it in the last two weekends, where I demonstrated how to build a basic groupchat application. Unfortunately, the 8h I allocated for it weren’t enough (but it was close) due to some typical JavaScript issues, namely that it doesn’t do any name verification at all.

You can get my demo application from github.

But, back on topic. Sproutcore is a JavaScript framework for developing modern browser-side web applications. This means that only a single URL is fetched from the server, the rest of the page is run locally. Of course, the application can do AJAX requests back to the server, but the user never has to wait for it after the initial load.

This totally changes the concepts of web pages, and leads to a model that’s very close to desktop development.

So far, this is actually nothing unusual. There are many other frameworks like this, like GWT and Cappucino. The special thing about Sproutcore is that it’s based on concepts known from Cocoa, like Key-Value Observing, Key-Value Coding and Binding. These allow creating a very dynamic application without having to write any code to update the content after the initial setup. For example, if the storage layer receives new data from the server, it can be inserted into the data store, which automatically updates the user interface, while still adhering to the MVC concept.

In my demo application for the workshop, for the communication with the server I chose XMPP as the protocol. The reason for this is that via BOSH the whole server-side infrastructure was already in place, and there’s a nice JavaScript-library available for it, strophe.js. Besides, it’s a very popular standard protocol, and I’m a big fan of it.

I used the storage layer I mentioned earlier for communicating with the server. Creating a message locally means sending it to the server, new messages that are received are created from the storage layer. This allows a clear separation between network protocol and application logic. Due to the dynamic nature of Sproutcore, this works perfectly.

I’ll probably followup with more specific Sproutcore-related things later, since I’m using it for multiple rather large projects. There’s a lot to discover and learn.