I found a way to get into the BASIC interpreter, I’m sure this isn’t the ‘official’ way of doing it, but by turning the machine off and then on again pretty quick (about 1 second delay) got me to a ‘]’ prompt, where I could clear the screen and start writing some BASIC on it. You can see in some of the photos in the gallery above that I had typed some things in and it seems to work well.

It’s a real shame that the floppy drive has been molested like that, so I’m on the prowl for a new floppy drive and hopefully some software too. I still have heaps of reading up to do about the Apple //e (I had some experience with it in primary school and early high school, where I was writing LOGO with it), but a copy of Where in the World is Carmen Sandiego for the Apple II would be a great addition :)

I’m going to start this not-so-regular string of PHP programming posts by commenting on a technique that is relatively new to me (I’ve known it for a couple of years now, but to be honest the opportunities to use this haven’t been that numerous), but improves programmer usability ie. it makes your life as a PHP programmer just that little bit easier. I call it ‘array parameters’ for lack of a better term.

Basically, it’s just using an array for your parameters in your custom functions, rather than declaring the order of values for your parameter in your function declaration. It’s also handy when trying to do nifty little things like default values for parameters, in which PHP has some shortcomings in.

It’s best to show this by example. Let’s say we have a function that sends an email out to a specific address.

1
2
3
4
5

function sendMail($toAddress, $fromAddress, $emailMessage, $emailSubject) {
	// let's just imagine that all inputs have already been sanitized and are safe to use
	$emailHeaders = "From: " . $fromAddress;
	return mail($toAddress, $emailSubject, $emailMessage, $emailHeaders); 
}

This function can be called via the following simple one-liner:

1

$sendResult = mail('to@example.com', 'from@example.com', 'This is a test email', 'Test email');

Pretty simple, right? We have four parameters, all in a specific order. We can go one step further and specify some defaults:

1
2
3
4
5

function sendMail($toAddress, $fromAddress, $emailMessage, $emailSubject = "This is the default subject") {
	// let's just imagine that all inputs have already been sanitized and are safe to use
	$emailHeaders = "From: " . $fromAddress;
	return mail($toAddress, $emailSubject, $emailMessage, $emailHeaders); 
}

That way, we can do something like the following:

1

$sendResult = mail('to@example.com', 'from@example.com', 'This is a test email'); // omitted the $emailSubject parameter

… which will fire off an email with the subject line “This is a default subject”.

This is all well and good, and heaps of PHP code out there in the wild (and behind locked doors) are written in this way. So what’s the big deal?

Let’s imagine that there is a group of PHP developers working on a project. There is a central repository of some shared libraries, and developrs are free to create new functions and add them to the library. One developer has contributed the above sendMail function (let’s say that this developer had embellished a little and turned it into an easy to use HTML email function) and ordered the parameters the way that made most sense to them, but some other people don’t agree and figure that it should follow more closely the order of parameters that the built in PHP mail() function has.

A political shitfight occurs, some sort of consensus has been achieved and the guys that thought differently to the original programmer won; the parameter order gets changed to make life easier. But by that stage, there’s already a whole heap of code that uses the “old” version. So they figure they should make another function instead, called sendMail2()… can you see where I’m getting at here? Some more lateral thought is needed.

Not everyone has the capability of seeing 3 steps ahead, and many times people come back to functions that they have written in the past and adjust them. Add a new feature or two, or try to make things more “usable” when it comes to programming, breaking old code in the process.

Wouldn’t it be great if you could just write a function that takes some sort of special variable, where the order doesn’t matter? That if new functionality is added to the function, it can be done so easily, and without breaking old code?

That’s where array parameters comes in.

Let’s refactor our sendMail() function and use a keyed array as our sole parameter input, as so:

1
2
3
4
5
6
7
8
9
10
11
12

function sendMail($options) {
	$emailHeaders = "From: " . $options['fromAddress'];
	return mail($options['toAddress'], $options['emailSubject'], $options['emailMessage'], $emailHeaders);
}
 
// when we call our function, we can do it as so:
$sendResult = sendMail(array(
	'toAddress' => 'to@example.com', 
	'fromAddress' => 'from@example.com', 
	'emailSubject' => 'This is a test email', 
	'emailMessage' => 'This is the test email content right here'
));

You can jumble around whatever keyed array elements you like, it doesn’t matter. You don’t need to remember which parameter comes first, as long as it’s in the array, it’ll get picked up.

What if some parameters are missing though? You should have some sort of default values for parameters (read array keys) that might not be in the parameter array when called.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

function sendMail($options) { 
	// we can set the defaults here
	$defaults = array(
		'toAddress' => null, 
		'fromAddress' => 'default_from@example.com', 
		'emailSubject' => 'No subject was defined, so here is a default one'
	);
	$options = array_merge($defaults, $options); // copy the $options array over the $defaults 
 
	$emailHeaders = "From: " . $options['fromAddress'];
	return mail($options['toAddress'], $options['emailSubject'], $options['emailMessage'], $emailHeaders);
}
 
// You can now call sendMail() as such, if you like:
$sendResult = sendMail(array(
	'toAddress' => 'to@example.com', 
	'emailMessage' => 'Here is a test email with some default parameters applied'
));

The array_merge() function will overwrite the $defaults array with whatever has been input. You don’t need to declare everything as an input (I put the ‘toAddress’ key in the defaults and set it to null to demonstrate that you can do this too if you feel more comfortable). The key ‘emailMessage’ isn’t declared in the $defaults array, but it is appended to $options when it is merged with it. It works the other way too; if you add functionality to this function and require more parameters, you can add them to the $defaults array and use them as above, without breaking any old code.

So I hope some of you out there have found this PHP coding technique useful. By no means have I discovered or invented this myself; it’s used liberally throughout the CakePHP framework and I have been pretty exposed to that over the past few years. I’m sure many other projects out there use something similar, if not the same. It won’t fix old code that still relies on the old process of itemising each parameter in a function, but if you start right now with this technique, your team (and yourself) will thank you later for it.

I’d be glad to hear your thoughts, and yes I know the code snippets above aren’t styled properly, but I’ll leave that for another day.

Anyway, I digress – following some people on Twitter such as Interactive Matter and Jeff Keyzer had exposed me to some interesting information about the Arduino. A quick tweet to Jeff and a recommendation was made for the new Arduino model coming out soon (at the time) – the Arduino Uno. I quickly found a distributor in Australia called (funnily enough) Australian Robotics and a few days later I receive my very own Arduino Uno in my hot little hands.

I don’t have any other hardware or cabling available on hand, so I can’t do much with it for now. But a quick stop at Jaycar will solve that problem.

I took some unboxing pics (keeping up with the Apple tradition) but didn’t think of taking pics until after I opened it – so the sealing label on the Arduino box is a little tattered in the photos. As for the photos themselves, I took them on my iPhone so some might be a bit blurry, I apologise in advance.

I proposed to my (then) girlfriend in November 2009 via iPhone app. Yes, I’m a nerd. Here’s how it happened.

At Dogma, my current workplace, we would go out for Yum Cha every couple of months ago and just get drunk on Asahi and bloated from chocolate-filled sesame dumplings. During this state, we would have a good long chat with everyone else on the table and discuss what’s happening in everyone’s lives.

For some reason, my co-workers were always interested in when I’m going to propose to my girlfriend, usually I just buff the question off or try to divert conversation to someone / something else, but I was getting a bit tired of that and just blurted out that I had no idea how to. My girlfriend wasn’t like any one else I had gone out with (one of the reasons why I wanted to propose), and I felt that it would be good to propose to her in a unique and interesting way. I definitely didn’t want to hide a ring in a cake or drop it in a champagne glass (that’s so tacky).

Due to the level of drunkedness, the ideas that my coworkers were coming up with were absolute gold. The best one was to create an iPhone app, and I jumped onto that idea straight away as I felt it was really ‘me’. I can’t remember who of my co-workers thought of it first, but whoever you are, thanks!

I had gone out onto the intarwebs a few weeks before that and bought an iPhone programming book – iPhone in Action by Christopher Allen and Shannon Appelcline. The book’s split in two, one section focuses on web programming and optimising for iPhone use, and the other half focuses on the iPhone app with CocoaTouch side of things. I had a flick through it and was pretty daunted with the Objective C syntax — it didn’t seem very C-like to me, and I was very comfortable with PHP.

Time went on and being busy with other things, this project fell by the wayside a little. Lo and behold, the year’s end was nearing and without an iPhone app (at this stage I was completely sold on the idea) I wasn’t going to pop the question. So I made some time in my schedule to sit down and try and nut out this Objective C thing. One of the tutorials was how to load a website in an application, and then I had a lightbulb moment.

If only if I could write the whole application as a website, store it locally within the application, and then get the app to load it up, then I could make the app behave like a native iPhone app, and the turn around could be much, much quicker. Yes, it’s the lazy way of completing the project, but time was against me (I had a vacation to go to with my girlfriend to Sydney coming up, and I wanted to be engaged before then), so I read into it and figured it all out.

So without any further ado, here’s some screenshots that you’d probably be interested in. The application is called iDo. I am aware that another app on the iPhone App Store is called iDo, but since I am not looking at selling this app, this shouldn’t be a problem.

Just a run-down on what each screen does.

• The first screen shows off the icon that I edited for the application. I say edited, as it’s actually an image that I grabbed off the internet somewhere (it might be a free stock image, or it might not, I can’t remember). I’m guessing since I’m not using this application for any commercial gain what-so-ever, that I’m relatively safe using images such as this.
• The second screen shows what my girlfriend would be first greeted with when launching the app. I have blurred out the meaty part of the message, as I’m a private person, and don’t feel comfortable showing the world what I wrote there; they are for two sets of eyes only, mine and hers. Note that I made it so that the ‘No’ button cannot be selected — you have no option but to click on ‘Yes’ to proceed ;) Plus it’s really mushy.
• The third screen needs a bit of background story. Early on in our relationship, I wasn’t exactly made of money so as a joke I would always say that when I propose, it’ll be with a Burger Ring. Hence the Burger Ring in the top slot on this screen. My girlfriend some time ago had actually shown me what style of ring she wanted, when I was ready to propose, to make sure that I get her a ring that she likes (which I think is pretty important). The ring in the third slot is the example ring she showed me, I had to find it again to place it in this app. The ring in the middle is something that I came across when trying to find some gag ring I could put in there — it’s a Chupa-Chup ring.
• The fourth screen shows the highlighting that happens when you tap and drag a ring from the left side to the hand. It glows white.
• The fifth screen is a shot of the animated GIF that I found of fireworks after some rummaging through Google Images. It was luckily big enough to fill the iPhone screen.

The techincal details of the app is as follows:

• The only Objective-C / CocoaTouch part of the whole application is the iDo shell — in the view files, there is just a UIWebView that gets populated with a local file (index.html). It’s index.html (and subsequent pages like page2.html, etc) that contains the “controller” (if you were to think of it as MVC).
• There are other frivolous things in iDoAppDelegate.m that controls things like the colour of the status bar.
• The HTML files were interesting — I found out via trial and error that it’s hard, nay, impossible, to link CSS files and to get them to load properly when the app was running. So all the CSS is embedded in the HTML files. <img> links etc were fine though.
• I used iPhone-specific JavaScript to prevent moving the whole web view around when tapping and dragging (like what Safari does by default when loading a page) , and to handle the tap + drag of the rings from the left side to the right.
• The highlighting of the hand is actually executed by two images, hand.png and hand_w.png. They get swapped in via some JS, just your basic document.getElementById(‘hand’).src = ‘hand.png’ kind of thing. There is some x-y coordinate range detection in there (again, in JS) to make sure that when dragging the ring, it’s over the hand before it highlights. This means that if you get a ring, and drag it over the hand, it will highlight, and if you don’t let the ring “go” and drag it back to the left side, the highlight disappears as it should. If you drop the ring successfully on the hand, location.href is populated with ‘page3.html’ (ie. it loads up page3.html). This file just has an <img> tag that specifies the animated fireworks GIF.
• The background images of the hearts (again, found it somewhere on Google Images so who knows what the copyright is like for this) is just loaded up as a background-image attribute value to the body selector.
• The home page is actually just one big image not including the ‘Yes’ button, which is a separate image that’s linked to page2.html. This is how I got the ‘No’ button to not be selectable; it’s part of the background image.

So that’s about it. From start to finish, the whole project took me 4 nights to do, including testing on my iPhone and in Xcode’s simulator. I then bought an iPod Touch and installed it on there too (just the developer version, so it probably still has debug code in it too, making it run a little slower), wrapped it up as a gift and proposed to my girlfriend with it at a nice secluded spot on Port Melbourne beach.

By the way, she said yes :)

2) Those Get a Mac ads — c’mon guys, enough with the baby music in the background and the “jibes” at MS. Each platform has its strengths and weaknesses

3) The flip-flopping of Apple that happens sometimes. One recent one is the removal, then re-addition of Firewire on the MacBook (now MacBook Pro) platform.

4) Apple taking its sweet time releasing updates to some software. Like Java updates to 1.6, for example.

5) Related to (3), but the gradual removal of features. Like using your iPhone as a drive (I used to do this all the time with my iPod)

6) Tech reporters, especially from the US, that rubbish an entire platform like the iPhone because it doesn’t have a feature like MMS in the US. Hey, there’s a place called the rest of the world that MMS and other features work fine, guys!

7) People who have used a Mac only once ever in their lives, which was in 1987, and will never, while their hearts are still beating, ever touch another Mac again, considering them some sort of Fisher-Price toy that couldn’t ever do any serious work, ever. Welcome to 2009, try a Mac before you spew out your bigotry. Related to this is how some people still think a Mac comes with a one-button mouse out of the box, which automatically makes the entire platform invalid and broken, in their eyes.

8) Mac fanboys who think they’re invincible and click on links, view attachments, visit dubious websites and think that they’ll never get into trouble with viruses or malware. That day will come, one day. And you’ll be screwed.

9) People who take advantage of the no serial number policy of Apple when it comes to OSX and just pirate the software. Snow Leopard is only forty freaking dollars — don’t be a tight arse.

10) MS users who rubbish any major 10.x.0 OS X upgrade as just a service pack. Uh… no. They’re paid upgrades, and are worth as much IMO. Funnily enough, the “paid service pack” philosophy that they poo-pooh so often is perfectly acceptable when Microsoft do it for Windows Vista (version 6.0.6002) upgrades to Windows 7 (version 6.1.7600). Here’s the proof of the version numbers. Talk about double standards.

What aspects of OSX, its culture, or its perceptions from outsiders tick you off?

The cool thing about Services is that it’s been around for ages and no one really used them :) Actually the most cool thing I found about Services is that it’s targetable; you can pick between text services (normal text, URLs, addresses, phone numbers, dates or email addresses) or file services (files, folders, files and folders, documents, image files, PDF files, movie files, audio files or text files) and you can even target in which application the Service can be invoked.

To create a Service, open Automator in your /Applications folder and you will be greeted with the following requestor:

Selecting the Service template will display a blank canvas on which to work from. Note that you can select the target that you need for your Service – for combining PDFs, I selected the drop down values to read “Service receives selected PDF files in any application“.

The action that is central to the whole functionality of combining PDFs is, funnily enough, the Combine PDF Pages action. It is available under the “PDFs” menu in the Library. Drag it over to the blank canvas.

The thing that you would need to consider when using this action is what state should the files be when invoking it. Personally, I thought that I would most likely be selecting all the PDFs I want to combine and then invoke the command (either through the Services menu option in the Apple menu, or through the contextual menu).

So to make this work, you need to add the Get Selected Finder Items action – this is available via the Files & Folders menu in the Library. Drag it to the canvas, above the Combine PDF Pages action.

I like to have some ability to interact with the Automator action, so I have ticked the Show this action when the workflow runs checkbox under Options.

If you were to run the Automator action right now (select some sample PDFs in Finder and then hit the Run button at the top right corner), you will find in the Result pane for the Combine PDF Pages action a brand new spankin’ PDF file, but named with some random characters and at a location that’s not readily accessible (it’s actually in an OS X temporary folder). This is where you will need to add some more Automator actions to move the file to a more accessible location. You can start by adding the Rename Finder Items action, found under Files & Folders in the Library.

We want to change the basename only (the file name, not including the extension), so change the Add Date or Time drop down list to Name Single Item, and enable the Show this action when the workflow runs checkbox under Options to allow you to enter in a name when the Service will be invoked.

When dragging this action into the canvas, you may come across a requestor asking if you want to add another action to copy the file instead. Since the file we want to move is already in a temporary location, and have no interest in keeping it in there, we should select Don’t Add.

Finally, you would want to move the resulting file out of the OS X temporary folder and into a location that’s accessible from the Finder. You will need to drag in the Move Finder Items action (available from the Files & Folders menu in the Library), and turn on the Show this action when the workflow runs checkbox under Options.

You can test your workflow by selecting some files in Finder, and then hitting the Run button. You might get a requestor saying that the service cannot receive input while in Automator; just hit OK and continue the test. Once you are happy with the workflow, you can now save it as a Service. Hit the Save As function from the File menu, call it a name (I chose “Combine PDF documents”) and you’re done.

If you select a PDF or a group of PDF files and then right-clicking to invoke the context menu, you will find near the bottom of the menu your new service. It will also be available under the Services menu in the File menu. Note that the service is not exposed to the user if there is a file other than a PDF selected — this is directly controlled by the Services targetting as described above.

Congratulations, you’ve just created your own Snow Leopard Service!

Over the following months, I had slowly collected the bits and pieces I needed to repair or replace the broken items and try to get the poor old Wallstreet as close as I can back to its original condition. I gave up looking for a great condition external case, as most if not all replaceable parts would be “reconditioned” or pulled from other second-hand laptops, which wouldn’t be in much better condition. I had however found another laptop battery (sold cheap – previous owner wasn’t sure of its condition, but it can hold at least 2 hours charge!), a replacement PRAM battery, replacement trackpad (both new), 256MB RAM (originally had only 32MB) and a CD-ROM drive that can be swapped out with the included floppy drive.

RAM is a cinch to upgrade – basically remove the keyboard and heat shields, and the RAM can be clicked into place without having to remove the CPU card at all. The PRAM battery needs access to the underside of the top cover / wrist rest, and since the trackpad which is also located here needed replacing, this worked out well as I could knock two birds with one stone.

I followed the disassembly steps from iFixit’s PowerBook G3 Wallstreet guide, which had told me while I was researching that I would need to remove the display to get further into the machine and replace the PRAM and trackpad. I found this daunting when reading about it at first, but when I got around to actually doing the transplants it was really easy. iFixit says that the difficulty level is “Difficult” but as long as you know what you’re doing and have some experience with computer disassembly and reassembly and know the basics about electronics and static electricity, it’s not very difficult at all. Reassembly / installation was, as they say in the Bentley Car Repair manuals, is the reverse of removal!

This was the first serious repair of a computer where I extensively used Blutack for the saving of screws and such. Can I say that this is an excellent idea (not wanting to gloat, but I did think of it myself – I’m sure I’m not the first to though), and with the different sized screws used in the Wallstreet, it was very handy as I didn’t need to write anything down or remember anything.

After the transplants, I put everything together but realised as I was installing back the keyboard that the CD cover / flap on the right side of the machine wasn’t aligned correctly – it had popped out between the upper and lower case. So I had to disassemble EVERYTHING again, pop it back in, and then reassemble everything again! Not to worry, it’s good to practice these things!

Anyway, here are the happy snaps I took. Once everything was put together, I pushed the power button and everything turned on and worked, flawlessly.