Lee Packham

There’s a few questions about whether this should be allowed, or not. I’m of the mindset that, providing it is detailed in the license agreement for the software, it’s ok. Yes yes, no one reads them – but is that the vendor’s problem?

Anyway, taken from Ars Technica is this little gem:

CFShow([[NSUserDefaults standardUserDefaults] objectForKey:@"SBFormattedPhoneNumber"]);

You can also browse quite a bit more of this dict.:

NSString *path = [NSHomeDirectory() stringByAppendingPathComponent:@"Library/Preferences/.GlobalPreferences.plist"];
NSDictionary *dict = [NSDictionary dictionaryWithContentsOfFile:path];
CFShow(dict);

Enjoy… But use responsibly.

This one of those posts where it’s more for ‘me’ and those Googling around. Today, I wanted to install FreeBSD on a memory stick for a server and then configure it in VMware before plugging into the internal USB slot of my server.

Installation was a breeze, booting was a little more difficult as the VMware BIOS doesn’t support booting off USB devices attached to it. To work around this I did the following

$ diskutil list
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *320.1 GB   disk0
   1:                        EFI                         209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD            254.3 GB   disk0s2
   3:       Microsoft Basic Data BOOTCAMP                65.4 GB    disk0s3
/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk1
   1:                        EFI                         209.7 MB   disk1s1
   2:                  Apple_HFS OSX External            499.6 GB   disk1s2
/dev/disk2
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *16.0 GB    disk2
   1:                    FreeBSD                         16.0 GB    disk2s1
$ /Library/Application\ Support/VMware\ Fusion/vmware-rawdiskCreator create /dev/disk2 1 SIXTEENGIG buslogic

So you can see in the diskutil list that the disk is on /dev/disk2 – what we then do is use vmware-rawdiskCreator to make a vmdk file represents it (something that Fusion won’t let you do in the UI). You then have to create a NEW VM and attach it to that, you cannot simply attach to an existing VM.

Then you have a nice bootable USB VM!

When the 3GS came out, I bought an iPhone 3G. What!? Why on Earth would I do that as a developer? Simple…

I wanted to make sure I got my hands on the machine that had the smallest amount of RAM and the slower CPU. All developers should really do the same. The problem with the 3GS, just like the Pentium processor when it first appeared, and the advent of DDR/DDR2 and DDR3 – it makes developers lazy.

When I started out doing software development, you had CPUs measured in Hz and RAM measured in Bytes. You had to make sure you used the system wisely to make sure your application ran properly. That meant optimising your code and ensuring you didn’t have any leaks in the code.

Fast forward to the modern day. Who cares if my application uses that extra 1 Megabyte of RAM? Well I do. RAM and CPU are precious resources and that is so true on small UNIX devices such as the iPhone. You’re competing against other processes such as the Phone.app, Messaging, iPod and Safari which all run in the background.

On the older 2G/3G devices, this leaves you with <10MB of RAM. On the 3GS you get left with 70+MB! What should you code for? Well the fact that there are still so many 2G/3G devices out there, your iPhone application MUST work in the <10MB scenario. You can’t get lazy just because you’re debugging in the simulator or on the 3GS where you have ample resources.

To get maximum exposure for a non-game app, I put the following rules in place for myself:

• Must use < 10MB of RAM
• CPU usage should be as close to 0 and not over 30% during loading
• Any network traffic should be compressed and minimal so that GPRS transfers are still feasible
• Don’t use splash screens, use the Apple guidelines for the startup PNG file (i.e. your UI!)

Is that so unreasonable? Ok, so if you need RAM, the iPhone can kill things in the background, granted – but that slows YOUR application down while it does it. Also, when the user presses the Home button to leave, the wizzy animation doesn’t work.

You’re making a first impression on your user that just, maybe, paid money for your application. Being slow to start, or even appearing slow to start, is going to get you lots 1 star reviews very quickly. Hardly fantastic marketing is it? There are lots of examples of this all over the App Store – including some of the ‘Top Paid’ apps. They end up recommending people reboot their phone before using their app!? What? Really? That’s insane.

Optimise, debug, make sure you use asynchronous network communications and most of all, test your application on a SLOWER device. Keep those iPhone 3G devices to hand and use them as your primary debug phones.

I’ve been working to deal with the ever growing information that Transport for London (Tfl) like to provide the daily commuter with. Part of this is changing how the information is downloaded from the server and part of this is small and subtle UI changes.

The first of these is to ensure that all colour information is downloaded from the server instead of making use of hard coded colours in the application itself. This seems obvious, but time constraints the first time around forbid this happening.

So now, the version I am testing has the colours coming directly from the server. It’s working very well and doesn’t slow the application down at all.

It also means that I can now truly update the information given to the application without having to update the application itself – this is a massive bonus!

Soon after the next version of the application is approved, the DLR status information will be added. All done without having to resubmit any new version of the application to the AppStore. This provides the user with up to the date information without the two week wait.

I felt this was a worthwhile design choice, and something that a number of iPhone applications don’t do. I don’t like the idea of buying an application that has to be updated just because the style of something in the data it relies upon changes. This just causes frustration.

The other change I have done is to reduce the font size. Silly? Maybe. The issue at the moment is that the amount of engineering works leading up the 2012 olympics means that Tfl are having to put a lot more information on their posts over the weekend around things like Bus services. This is useful to the user, so I wanted to make sure I included as much as possible. Initially, only the first paragraph was shown.

Now, the server side gets as much as it can onto the small display the iPhone provides. That’s great, but the font size on the original version was massive. In fact, it was 17pt! I’ve now reduced it to 12pt, which is still readable, as you can see from the screenshot on the right.

The other thing I have done is to make the UITextView that is used to display the data scrollable. So shortly after release on the AppStore, I intend to change the server side to really pump out all the information (carriage returns and all) to the user so they get the best experience and can quickly get at the information.

I’m still really glad of the feedback I have been getting thanks to the freebie version I pumped out for 48 hours. The latest download statistic I have from Apple puts it at over 300 copies were grabbed for free over the weekend. That’s fantastic! If only Push Notifications could be free – I’d offer it for free, forever.

In preparation for version 1.2 of Tube Status Push Notifications (Tube Notify) – I have updated the Django application that serves up the data to the app. and it’s push notifications.

The changes are:

• Colors are now downloaded with the data, this will allow the next version of the application to use server side data rather than hard coded in the client. This means that any future lines added/changed will not need a new version of the application
• DLR update code added in preparation for 1.2 – Because of the Colors being hard coded, the client currently can’t cope with the DLR/Overground lines. The next release will be able to and therefore I have written some code to collate the DLR service status.

I’m not overly sure if people want Overground information. I just always assume it’s not working – as it never seems to be.

Either way, now I can finish the testing of 1.2 and get it submitted for approval. Fun fun fun!

Over the last 48 hours, I offered Tube Notify for free on the App Store. I did this for one reason and one reason only. One has to spend money to make money. In this case, I wanted to get feedback on the app. The problem with the App Store is you can’t offer time limited demos to potential customers. Instead they make their purchase decision based on other factors. The main one being… Feedback.

150 people took advantage of the fact the app was free – that’s pretty good considering the fact that it’s no longer on the front page of the Travel Section. Out of that, I got 4 feedback reports and I now have a listed average! That average being 3/5. Can’t really grumble with that – so if you got the app for free and gave feedback, thank you.

Now to get to work on the next update for it…

This is a common problem around the web on PHP servers so I’m making a note here for my own reference as I recently had to deal with some people that find it ‘funny’ to script kiddy hack servers:

1. Make sure that all web directories are only writeable if they absolutely need to be (obvious, but you’d be surprised)
2. Change php.ini to add the following:

disable_functions = exec, passthru, shell_exec, system, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_source

What option 2 will do is stop PHP scripts from executing any commands under any user context at all. This will ensure that even IF something did get installed, it would be quite hard for it to do very much.

I’m sure there are many other PHP commands that are worth disabling – I’d be interested to learn of them.

Update: Just after I posted this, the author of Colloquy posted on Twitter that the’s got a new Nightly that solves this problem in a “proper” way. Proves the power of Twitter works!

I just upgraded to Snow Leopard and loaded up my IRC client, which happens to be Colloquy, and noticed that Growl stopped working! Checked Growl, Adium was managing to use it just fine.

Turns out that you need to load Colloquy in 32-bit mode as there is no 64-bit Growl API at present.

To do this:

1. Go to Applications in Finder
2. Find Colloquy
3. Highlight it with a single left click
4. Hit CMD-I or go to File -> Get Info
5. Tick the ‘Open in 32-bit mode’ box
6. Close the window
7. Load up Colloquy

Can’t see why Colloquy needs 64-bits anyway. I’d rather it was limited to 4GB of RAM – the amount of memory leaks it tends to have!