We’ve implemented the famous sIFR technique to display headings in non-standard web fonts. Windows, Mac, and Linux do very few things the same way. The one thing they all do the same though, is render Serif, Sans-Serif, and monospaced fonts the same. While we’ve gone with a monospaced font for the content of this site (a homage to coders everywhere), it was our feeling that the headings should be much different. Keeping with the grungy theme of the vertical logo, we used the same font for the h2 and h3 headings.

We’ve also kept the base font-size at the default level. There’s a great article about this here, with a lot of reasoning for not altering the base font size. The takeaway for us: most screens aren’t that small anymore and small text is just too hard to read.

So, we’re all new. We hope you like it. You’d better …

No related posts.

With the disclaimer out of the way, I can say that I’m running Ubuntu 8.10 (Intrepid) on my 24″ iMac, alongside the typical OS X 10.5 (Leopard) software that comes with the machine. The results are stunning. I have never seen Linux look so amazing, as it does on the machine I’m writing this tutorial on. If you’ve got some patience, I highly recommend performing this.

So, I’ll presume that you’re already running OS X (Leopard) on the existing Apple computer. The first thing you’ll need to do, is to use the Bootcamp Assistant Utility to set aside some hard-drive space for Linux. This is a trivial task, but make sure you leave enough space for Ubuntu to run comfortably, as well as double your RAM amount (which will be used as swap space by Ubuntu).

In case that’s confusing, the amount to give Ubuntu = Ubuntu Disk Space + ( 2 * RAM)

Once you’ve done that, you’ll be prompted to start the assisted install of windows. DO NOT ALLOW THIS. Kindly click the ‘Finish Later’ button, and close the program.

The next thing  you’ll need to do, is install rEFIt. rEFIt modifies the boot setup for the Mac, to allow for multiple boot scenarios. This is a very necessary step, before trying to install Ubuntu on the freshly reserved hard-drive space. The install of rEFIt is easy. Mount the image that comes with the download, and run the package. No configuration required

Once you’ve gotten that done, you’ll need to insert the Ubuntu install disk into the CD / DVD drive of your computer, and restart. rEFIt is supposed to recognize the disk on boot, and provide you the option to choose what you want to boot from. This wasn’t the case for me however. So, just to be safe, when you restart your computer, hold down the ‘c’ key as soon as the machine starts back up. This should force the computer to boot from CD, thus allowing you to run the Ubuntu install.

Go through the typical steps to install Ubuntu, until you get to the disk options. Once there, you should be able to click the option to ‘install to the largest continuous free space’. Again, I was not able to do this. I got a bunch of errors when I tried to do this, so I had to setup the Ubuntu partitions manually.

If you don’t need to setup the Ubuntu partitions manually (i.e., the i’nstall to the largest continuous free space’ option works for you), skip past the next instructions.

If you do need to setup the Ubuntu partitions manually,  here’s how to do it:

1. Select the manual option instead of the ‘install to the largest continuous free space’ option.
2. Select the Free Space partition of the hard drive.
3. Create one partion, equal to twice the amount of RAM in your computer, and set it’s type to Swap.
4. Select the newly modified Free Space partition of the hard drive.
5. Create one partition, equal to the remaining free space,
6. Select the option to format the drive
7. Set the filesystem to ext3.

Click ‘Forward’ to proceed to the last part of the install. Once here, you’ll need to ‘Advanced’ button to specify where GRUB will be loaded. If you were able to use the ‘install to the largest continuous free space’ option, then select /dev/sda3, if you had to do a manual partition setup, then select /dev/sda4.

Finally, let the install proceed. Ubuntu usually takes about an hour to install, so go mow the yard or something. Once the install is done, the CD will be ejected. You’ll see a prompt to remove the disk, and press enter to complete the install. Do this.

When the computer reboots, you should see the rEFIt screen. This screen will have a few options, but one of them (a small option in the lower left of the icons) will be the partition tool. Run that option. A quick script will run, and you’ll be prompted to continue. Confirm this option. Afterwards, shutdown the computer. Do not restart the computer. You need to specifically shut it down.

Finally, turn the computer back on. You’ve done it. Hoo-ray.

I’d like to take the time to thank the MactelSupportTeam for the instructions they provided at their own site :

https://help.ubuntu.com/community/MactelSupportTeam/AppleIntelInstallation

They’ve provided a number of boot scenario tutorials that are amazing, and well worth the read.

No related posts.

At first, I figured I’d use the AppleCare plan we purchased to have the phone replaced / repaired. Apparently, Apple’s AppleCare plan’s do not cover accidental damage. They told us that the phone could be replaced at the subsidized cost ($199.99). As you can imagine, I was a bit upset with Apple.

Since I’m a technical guy, I figured I’d find a way to repair the screen myself. I found a site (pdaparts.com) that sells replacement screens for $49.99. That’s way cheaper than what I was expecting, so why not? I’ve replaced MacBook screens before, so how hard could the iPhone be?

The hardest thing ever.

PDA Parts has an excellent video detailing the steps to disassemble the iPhone, down to the glass-digitizer combination. After that, there are no instructions at all. The site’s narrative basically stops there and says ‘Good luck! Let us know if it works out for you.’. Once I realized this, I was already in too deep. So, I went ahead and finished the job.

The iPhone screen can be replaced, but it is definitely the most difficult repair I have ever done. If I had the chance to go back, I would easily take the $199.99 repair from Apple over doing this myself. It was immeasurably difficult, and I do not recommend it. for those of you with a strong stomach, here’s how it goes:

First, the video from PDA Parts :

From there, you’re pretty much neck deep in a disassembled iPhone. You’ll need to separate the existing glass from the chassis that houses both it, and the digitizer underneath. This is the especially tricky part. I was better able to do this, by utilizing the location where the existing glass on the phone was broken. Using an exacto-knife, I was able to separate the glass from the chassis.

I can’t emphasize enough how much care should be taken when doing this. First of all, every component of your iPhone is extremely delicate. Secondly, you are dealing with broken glass. I cut my hand a lot getting the glass off. That sort of thing doesn’t bother me, but if you’re not a fan of bleeding hands, be very careful.

Once the old glass has been completely separated from the chassis, use the exacto-knife to ensure all of the existing adhesive has been removed from the chassis. When you apply the new adhesive strips (yes, you must buy those too), you’ll need a completely clean surface to attach the new glass to.

After you’ve gotten this done, very carefully apply the adhesive strips to their respective places in the chassis. You’ll only get one chance at this, so make it count. There’s a pink covering on the front of the adhesive strips. Leave this in place for now. Once you have both the adhesive strips in place, then you can remove the pink coverings.

Now, you can put the new screen on the chassis. Make sure to remove any plastic coverings before doing this. Like I said: you only get one chance at this.

After the screen is on, you’ll pretty much need to perform the takedown, in reverse to put the iPhone back together again. This part isn’t exceptionally difficult, with one major exception

The cable marked ‘3′ that connects the digitizer to the main board is very tough to get back on. I managed to make this happen, but I’m certainly open to hear any suggestions on how to make this work.

No related posts.

So, enter the Decorator Pattern.

The easiest way to realize the decorator pattern, is simply to pass the decorated class to the decorator’s constructor function, then expose whatever functions of the decorated class you desire, adding functionality as necessary. So, here’s an example of a widget class (the decorated), that get’s decorated by the decorator:

class Widget
{
    /**
     * property to hold the data for the widget
     * @var array $_data
     */
    private $_data = array();
 
    /**
     * function to draw a widget from the existing data
     */
    public function draw ( )
    {   // CREATE a local variable to represent the result
        $markup = '';
 
        // ITERATE through each of the key/value pairs in the _data property ...
        foreach ($this->_data as $key => $value)
        {   // APPEND the key/value pair to the markup variable
            $markup .= "
<dt>{$key}</dt>
<dd>{$value}</dd>
 
";
        }
 
        // RETURN the result, wrapped in a dl tag
        return "
<dl>{$markup}</dl>
 
";
 
    } // END draw
 
} // END Widget
 
class WidgetDecorator
{
    /**
     * property to hold the item that will be decorated
     */
    private $_decoratedObject;
 
    /**
     * Constructor
     * @param object $DecoratedObject
     */
    public function __construct ($DecoratedObject)
    {   // SET the _decoratedObject property to the object that was provided
        $this-&gt;_decoratedObject = $DecoratedObject;
    } // END __construct
 
    /**
     * function to expose the draw method of the _decoratedObject
     */
    public function draw ( )
    {   // RETURN the result of the _decoratedObject's draw method, wrapped in a div
        return '
<div class="decorated">' . $this-&gt;_decoratedObject-&gt;draw() . '</div>
';
    } // END draw
 
} // END WidgetDecorator

While it’s common to talk about GUI implementations of the Decorator Pattern, there are several other implementations that fit the Decorator Pattern idea. You might need to wrap an event logger, that already logs events to one log, with a user notifying system that also notifies users. You might need to do all kinds of things.

The idea here, is that any time you need specific functionality added to a class (or set thereof), you might consider the Decorator Pattern.

Related posts:

1. Observer Pattern One of my favorite design patterns, is the Observer Pattern. The Observer...
2. Factory Pattern In following the theme of design patterns we’re starting this...
3. Singleton Pattern One of the things I see all the time with...

It’s a lot like a bunch of soldiers waiting for the order to charge. The general is observable, and the soldiers are observers. When the general gives an order, the soldiers react in a way appropriate to the order. This is the essence of the Observer Pattern. Here’s the class diagram of the situation :

The difference between the Observer Pattern and other design patterns mentioned here, is that there are (at least) two classes required to implement the Observer Pattern. One class is the Observable. It binds to events in the Observable class. The second class is the Observable class. This class is the traffic cop for the entire system. This class will define where the Observer will receive notifications regarding the state of the Observable object. Here’s some basic code to make the point:

< ?php
/**
 * Class that is the general to the soldiers
 */
class Observable
{
    private $_observers = array();
 
    /**
     * public function to add observers to the stack
     */
    public function addObserver (Observer $observer)
    {   // APPEND the provided observer to the observer stack
        $this->_observers[] = $observer;
    } // END addObserver
 
    /**
     * function to let the observers know to check the status of the observable object
     */
    public function notifyObservers ( )
    {   // ITERATE through each of the observers in the stack ...
        foreach ($this->_observers as $observer)
        {   // UPDATE the observer
            $observer->Update($this);
        }
    } // END notifyObservers
 
} // END Observable
 
/**
 * Class that is the soldiers to the genereal
 */
class Observer
{
    /**
     * Implementation of the observer's update function
     */
    public function Update (Observable $observable)
    {
        // do whatever it is that the observer should do when notified
    } // END Notify
 
} // END Observer

Related posts:

1. Decorator Pattern In our ongoing series about design patterns, we introduce the...
2. Factory Pattern In following the theme of design patterns we’re starting this...
3. Singleton Pattern One of the things I see all the time with...

A common example of this are configuration objects. Suppose you’ve setup a configuration for you’re application to use an XML configuration file to run. Now, let’s say for some unknown reason, you need to use an INI file for configuration. Or, let’s say that today you’re using MySQL for database storage, but tomorrow, you might be forced to use Oracle.

Having to find where you create the instances of classes could be difficult, or maybe even impossible. The solution to this dilemma, is to use factory pattern to produce objects where any future ambiguity might cause a disaster.

Typically, the way a factory is implemented is to implement some sort of class that acts as a quasi-gateway to the object that’s needed. To keep things simple, we’ll assume we’re trying to get a database object and we need to not worry about the actual implementation of the database

< ?php
class Database
{
    /**
     * function to return the type of database object required by the user
     *
     * @return DatabaseObject
     */
    public static function factory ( $type = 'mysql' )
    {   // SWITCH based on the type of database required
        switch (strtolower($type))
        {   // CASE the adapter requested is MS-SQL
            case 'mssql':
                return MssqlDatabase::getInstance();
                break;
 
            // CASE the adapter requested is SQL Lite
            case 'sqlite':
                return new Sqlite;
                break;
 
            // CASE the adapter requested is Oracle
            case 'oracle':
                return OracleDatabase::getInstance();
                break;
 
            // CASE the adapter requested is MySQL
            case 'mysql':
            default:
                return MysqlDatabase::getInstance();
        }
    } // END factory
 
} // END Database

Now, I threw the SQL Lite case in there to throw off the notion of just being able to dynamically call an adapter based on name required. Sometimes a simple call_user_func isn’t a possibility. On larger applications, it’s likely that there isn’t a rhyme or reason behind class names and methods being used to retrieve them.

Related posts:

1. Singleton Pattern One of the things I see all the time with...
2. Observer Pattern One of my favorite design patterns, is the Observer Pattern. The Observer...
3. Decorator Pattern In our ongoing series about design patterns, we introduce the...

The idea behind design patterns, is to make routine the typical problems encountered by most software development. It’s likely that any problem get stuck in when trying to write the next biggest app in the world, someone already figured out. So, in much the same way that Object Oriented programming lets applications reuse code, Design Patterns help developers reuse algorithms and ideas.

The most basic, and classic design pattern is the Singleton Pattern. The principle, as you might have figured out, is to ensure singularity of an entity. There are some objects that should never be duplicated throughout the life of an application. Great examples of these are database connectors, request dispatchers, registries, etc …

So, at it’s most basic, a singleton is a class. What make it special, is that it’s constructor is not publicly available. Instead, the instance of the class is publicly available through a special method, getInstance. This function handles the acutally getting of the instance, and prevents duplication of the class.

Easy enough, here’s an example in PHP :

< ?php
class Foo
{
    /**
     * Property to contain the instance of the class
     *
     * @var Foo $_instance
     */
    private static $_instance;
 
    /**
     * Privatize the constructor of the class, to prevent the public from getting crazy with it
     */
    private function __construct ( )
    {
    } // END private constructor
 
    /**
     * The function that makes it all happen
     *
     * @return Foo
     */
    public static function getInstance ( )
    {   // IF the _instance property is not already set ...
        if (! isset(self::$_instance))
        {
            self::$_instance = new self;
        }
        // RETURN the instance of self
        return self::$_instance;
 
    } // END getInstance
 
} // END Foo

Related posts:

1. Factory Pattern In following the theme of design patterns we’re starting this...
2. Observer Pattern One of my favorite design patterns, is the Observer Pattern. The Observer...
3. Decorator Pattern In our ongoing series about design patterns, we introduce the...