computers should be less friendly

So, I came upon an iPhone to play with for a few days and decided I should try to learn about how the user applications run on it.  There has been a lot of great work already by the guys on the iPhone Dev Wiki around getting SSH and such on the iPhone, needless to say without their work this discovery would not have happened.

The point was to learn how the applications are structured and then see if I could add an existing application back to the iPhone with a different name and icon and have it run. Today Fred and I set out to see if we could get this to happen.

iPhone applications look very similar to applications for OSX, makes sense as they both run some version of OSX.  The file structure of the iPhone Calculator is this:

[/Applications]
    [/Calculator.app]
        Calculator
        CalculatorBackground.png
        Default.png
        [/English.lproj]
            InfoPlist.strings
            Localizable.strings
        Info.plist
        LCDBackground.png
        PkgInfo
        icon.png
        ring.png

[ source: iPhone Directory listing ]

For this example we will be trying to change the calculator app into some a touch more fun looking.  First step is simple ( if you already have SSH on the iPhone and the binkit on your iPhone)  tar up the Calculator app and copy it to a Mac.

Executable [Calculator]

The Calculator file is a compiled binary for the ARM platform running it from OSX produces the error message: “Bad CPU type in executable.”  We assume that this has something to with the Universal application concept in OSX.  It is opening that executable and looking to see if it has the ability it talk to an Intel/PPC processor it of course doesn’t so it craps out.  First thing we did was to rename this file to foobar.

Info.plist

This is the file that has all the information about what to execute when a user clicks on the icon in the home screen.  File is a regular plist file from normal OSX applications.  The node to concern yourself with is CFBundleExecutable.  This points at the binary you want to execute.  So, in our case we need to point this node at our renamed executable.

icon.png

A few sites have already figured out you can change these around so, I won’t go into anymore detail then pointing you at the ModMyiPhone wiki that describes the structure of iPhone pngs.  You don’t actually need to “optimize” your pngs for your iPhone.  It can render regular ones just fine.  We threw a “festive” graphic into our package.

“Deploy”

The final step is to move all these files over to the iPhone.  Make sure you get the directory structure right:  /Applications/foobar.app/ .  Reboot the phone and you should see your newly renamed and functioning Calc application on the home page.

One other interesting that came of this is that the iPhone can’t have more then 16 applications on it.  The home screen does not have the ability to scroll.  We loaded 4 more copies of the calculator onto the phone and were unable to scroll down to see them.  Maybe there is a simple change to the launcher application to allow the scrolling to happen or maybe Apple has to change the application to allow it.

You can see the little Handbrake icon peeking out from under the Buttonbar, but you can’t scroll down to see it.  Sad.

No, this isn’t a new native application but, it gets us one step closer to deploying applications onto the iPhone once we can compile them, which is still a long way off.

Eddie Herrmann was reading Scoble‘s twits a few weeks back and he was complaining about how annoying it was to take all of your followers and make them friends. So, last night Eddie and I decided to give him a hand.

Prom Queen is basically a popularity contest that also helps you convert followers into friends. Simply, put in your Twitter UserID and password into Prom Queen and it will go out and scrape all your followers and make them friends. It will also then enter you into our “popularity contest,” which ranks you based on the number of Followers you have. So feel free to use it and let us know what you think.

This is a total hack so if Twitter changes around much expect this site to be down till we fix it.

If your IT department is even the smallest bit like mine it may seem that is almost totally impossible to create a place where you can safely try out new technology. In my IT shop though we have carved out a small niche where we have a hand full of folks with a small percentage of their time to really seek out impossible problems and help solve them. At first this seemed like an impossible sell to senior management, however using the following logic we were able to get the time we needed to see if some of any new technology could help our business.

1. Agile Development
• Im totally guessing here, but in most IT shops I assume you probably use some locally bastardized version of the Waterfall method. In our R&D team we use an over simplified version of Scrum, the idea is to remove all the unnecessary artifacts from the process and “Shutup and make it work,” to use one of our teams mantras. The basic idea is get testable code in another team’s hands as frequently as possible; this could mean every night or every week.
• The reason this is number one is that it will allow you ( and/or your team ) to prove value instantly. People go nuts when you deliver the 1st version of working code before other teams have even decided who writes the spec
• Using this type of process automatically distinguishes you from your colleagues, it allows you to move fluidly with the ever changing IT landscape, it is a huge win over your normal process and a big key to my team’s success
2. Flatten your Team
• This may seem like a no brainer but odds are there are lots of people between you and your user community. To be successful at delivering code as fast as you will need to justify your spent time you must be as close as possible to your user base. This means you can’t have a rigid structure the person who knows the most about the area needs to make the decisions. Suck up your pride and let them run the show.
3. Get smart people
• I have a really hard time phrasing this statement but, suffice to say, you have to get the cream of your organization. If you want someone to go decide if Ruby on Rails is a good idea you better trust that person’s ability to learn and their ability to judge technologies. In the end it’s better to have fewer people then an army of people you have to micro-manage.
4. Research is failure
• This is one of the hardest concepts for an IT shop to grasp — they mostly deal with uptime and throughput but when experimenting with new ways of doing things you have to be able to deal with a certain amount of risk and this finally brings me to the reason for this blog, a recent post ( really go read it ) by Carmine Coyote at Slow Leadership, really a great job about the fear that makes these teams fail. Which brings me to my last point
  
5. Fear Nothing
• You can’t be a “disruptive innovator” ( thanks Shai ) without risking something every once in awhile
• Make your management understand that fear is costing them $
• “Thrill your users” ( thanks again Shai ) any fears your management has will go away

Good luck, if IT in the US is to stay we must stop being a commodity and start delivering really measurable value to our businesses again. The simplest way to do this in the enterprise space is to simply make those ugly back end systems usable.

btw — this blog was written somewhere south of Greenland at about 33k feet. On board internet is great.