My previously blogged about methods for updating multiple iPhones in a household are no longer necessary. The 5.0.1 over the air software update was a manageable 44MB and very kind on my bandwidth (even when downloading it more than once to upgrade each phone over our household wireless).

iOS 5.0.1 Release Notes

• Fixes bugs affecting battery life
• Adds Multitasking Gestures for original iPad
• Resolves bugs with Documents in the Cloud
• Improves voice recognition for Australian users using dictation

Download URL

The iOS 5.0 firmware update file (.ipsw) is available at:

• http://appldnld.apple.com/iPhone4/041-8358.20111012.FFc34/iPhone3,1_5.0_9A334_Restore.ipsw

Update

Updating each iPhone as per my previous post resulted in a strange 3002 error.

I finally managed to solve this by placing the downloaded .ipsw file in the following location on each Mac:

• /Library/iTunes/iPhone Software Updates

Create the folder if it does not exist. Clicking on the update button in the iPhone Summary page in iTunes will update your iPhone. Repeat with each Mac and iPhone combination.

iOS 4.3.5 Release Notes

Fixes a security vulnerability with certificate validation.

Download URL

The iOS 4.3.5 firmware update file (.ipsw) is available at:

• http://appldnld.apple.com/iPhone4/041-1966.20110721.V3Ufe/iPhone3,1_4.3.5_8L1_Restore.ipsw

Update

Update each iPhone as per my previous post.

iOS 4.3.3 Release Notes

This update contains changes to the iOS crowd-sourced location database cache including:

• Reduces the size of the cache
• No longer backs the cache up to iTunes
• Deletes the cache entirely when Location Services is turned off

Download URL

The iOS 4.3.3 firmware update file (.ipsw) is available at:

• http://appldnld.apple.com/iPhone4/041-1011.20110503.q7fGc/iPhone3,1_4.3.3_8J2_Restore.ipsw

Update

Update each iPhone as per my previous post.

I run my MacBook through a 24” Samsung SyncMaster T240 and use the wired keyboard and wired mouse. This gives me a nice desktop setup and when I need to be mobile the 13” form factor is perfect.

Lately I have begun to feel the limits of the stock 2GB RAM and the 160GB HDD. So it is time for an upgrade. This post marks the completion of a 2 part project to upgrade both the RAM and the HDD of my MacBook.

• Part 1 – Upgrade RAM from 2GB to 4GB
• Part 2 – Upgrade HDD from 160GB to 500GB

No Space

Right clicking on Macintosh HD > Get Info showed that I had around 5GB of HDD space left on my MacBook. I bought the replacement drive for this little project over a year ago but had been putting off replacing my HDD – it was finally time …

HDD Specifications

I read a number of reviews and posts on various forums and blogs about what an ideal replacement drive would be. I looked at the prices between 320GB and 500GB HDDs (remember this is over a year ago) and finally settled on finding a HDD with a capacity of 500GB. My logic was that the bigger the drive was, the less likely I would have to do this again during my MacBook’s lifetime.

The next challenge was whether to get a 5400RPM or 7200RPM drive. Again there was heated debate in the forums and on blogs. The two contenders for me were:

• Seagate Momentus 7200.4 500GB SATA 3.0Gb/s, 16MB Cache, 7200RPM
• Western Digital Scorpio Blue 500 GB, SATA 3 Gb/s, 8 MB Cache, 5400 RPM

I liked the fact that the drive in my MacBook was so quiet and wanted to maintain that experience. Western Digital advertised WhisperDrive technology on their Scorpio Blue drives which was meant to yield the quietest 2.5 inch drives on the market. This claim seemed to be held up in the forums and since I was not doing anything seriously IO intensive on the MacBook I decided to go with the 5400RPM Western Digital Scorpio Blue 500GB. I also ensured that the drive was no higher than 9.5mm due to ongoing debates on various forums.

Cloning the HDD

This is the part of the process that kept me from upgrading months ago. The contents of the existing HDD in the MacBook would have to be cloned to the new HDD. I had read a number of blog posts on using the SuperDuper! or Carbon Copy Cloner utilities and it all seemed simple enough – but I was still a little nervous. I finally settled on using Disk Utility which is bundled with Mac OS X and is all you really need for cloning your HDD. A simple and easy to understand post by Daryn Cox got me started.

I mounted my new 500GB HDD into an external USB enclosure. I fired up Disk Utility via Applications > Utilities > Disk Utility and selected the Restore tab. I dragged the icon of the existing Macintosh HD from the left pane into the Source box and the icon of the new external 500GB HDD from the left pane into the Destination box. Ensure that the Erase destination checkbox is checked. Double check that your existing HDD is the source and that the new HDD is the destination before proceeding.

Click the Restore button.

Confirm the erasure of the destination drive by clicking on the Erase button.

Then wait… My estimated time fluctuated between 3 and 6 hours initially but I left it running overnight so I’m not really sure how long it actually took. It is probably better if you don’t use your MacBook while this operation is taking place.

Verify Clone

Once the cloning process has completed you need to verify that the clone was successful. The easiest way to do this is to boot from your new HDD. There are two ways to do this in Mac OS X:

Option1: System Preferences > Startup Disk

Navigate to the Startup Disk section of System Preferences. Select the new external 500GB and click the Restart button.

Confirm the restart by clicking on the Restart button.

Option 2: Option Key at System Boot

Hold down the option key during system boot.

Select the new external 500GB.

Once I had confirmed that my drive had been correctly cloned, it was time to install the new HDD into the MacBook.

Installing the new HDD

Apple provide fairly detailed instructions via their support site on how to upgrade your HDD. See Chapter 3: Boost Your MacBook > Replacing the Hard Disk Drive of the manual for the MacBook 13" Aluminum (Late 2008). I had my cloned HDD, some decent precision screwdrivers this time around and was ready to begin.

Opening up the MacBook

Turn the MacBook over and push down on the door latch to release the access door. Remove the access door and the battery. The battery has a handy tab on it to make lifting it out of the bay easier.

Make sure to ground yourself before touching anything inside your MacBook.

Removing the old HDD

The old HDD should be visible on the bottom left of the MacBook.

Remove the bracket holding the old HDD using a #00 Philips precision screwdriver. I finally found a decent #00 Philips and the experience removing my HDD was much better than when I upgraded my RAM… If the only advice you take away from this is to find a really decent precision screwdriver then you will be halfway there.

Lift the old HDD out of the bay using the clear tab and then gently wiggle the connector off the HDD. Remove the mounting screws using a Torx T6 precision screwdriver. Again I will say it – spend the cash and get a decent screwdriver.

Installing the new HDD

Remove the clear tab from the old HDD and attach to the new HDD. Screw the mounting screws into the new HDD using the Torx T6 screwdriver.

Place the new HDD into the drive bay.

Replace the bracket using the #00 Philips screwdriver.

Closing up the MacBook

Place the battery back into the bay and then replace the access door. Press it down gently until the latch moves to the closed position.

Confirmation

Switch on the MacBook and make sure it boots. Right clicking on Macintosh HD > Get Info now shows my new 500GB HDD and plenty of free space.

Using a proxy

I again used Charles to capture the url of the iOS 4.3.2 firmware update file (.ipsw). I had to enable the SOCKS proxy options this time to capture the traffic successfully.

Enable the SOCKS proxy in Charles by clicking on Proxy > Proxy Settings in the menu and checking the Enable SOCKS proxy checkbox in the Proxies tab.

Also check the Use SOCKS proxy in the Mac OS X tab.

Download URL

The iOS 4.3.2 firmware update file (.ipsw) that iTunes was downloading is clearly visible in Charles:

• http://appldnld.apple.com/iPhone4/041-0662.20110414.byQ84/iPhone3,1_4.3.2_8H7_Restore.ipsw

Update

Update each iPhone as per my previous post.

This is the final part of my journey into learning Git, using GitHub and contributing to an open source project.

• Introduction
• Part 1 – Install Git
• Part 2 – Set up GitHub
• Part 3 – Fork project
• Part 4 – Contribute code
• Part 5 – Submit pull request

GitHub Workflow

As I discussed in an earlier post, the typical workflow of contributors to an open source project hosted on GitHub can be a bit intimidating. It involves the following steps:

• Fork
• Clone
• Write and commit code
• Push
• Submit pull request

I have gone through forking a project and cloning the repository. Writing and committing code to your local repository. Pushing those changes up to your cloned repository on GitHub. Now all that is left is to submit a pull request to the master project.

Pull Request

A pull request wraps up a number of commits so that another interested party can review them and decide whether or not to include them in a master project. GitHub makes this incredibly easy.

I navigated to my paulbouwer/SolrNet repository on GitHub and after confirming the commit details via the Commits tab clicked on the Pull Request button.

I wrote a comment around the commits I was submitting in the pull request. GitHub always makes it clear as to what is going on. Note the You’re asking mausch to pull 1 commit into mausch/master from paulbouwer/master.

GitHub allows you to verify the commits included in the pull request via the Commits tab.

GitHub allows you to verify the files and diffs on those files included in the pull request via the Files Changed tab. I had a number of issues with line ending differences on my files vs the master project – so a great tip is to pay attention to these. Mauricio kindly resolved these for me.

GitHub allows you to preview your pull request message via the Preview submenu on the Preview Discussion tab. I finally submitted the pull request by clicking on the Send pull request button.

The pull request has now been added to the pull requests queue of the master project mausch/SolrNet. GitHub again makes it clear as to what is going on. Note the paulbouwer wants someone to pull 1 commit into mausch/master from paulbouwer/master.

Clicking on the Pull Requests tab in the master project mausch/SolrNet shows the current pull request queue and confirms that my pull request is in it.

Acceptance

I was notified by GitHub via email that my commit had been accepted by into the master project mausch/SolrNet. I confirmed this by clicking on the Commits tab on the master project page.

I also confirmed that the feature I had worked on was now closed in the SolrNet issues list. It felt good – my commit had been accepted into the master SolrNet project.

End of a journey

This has been an incredible journey and I can highly recommend dedicating some time and code to an open source project. The satisfaction of contributing to a project used by a community is something else. You also get a lot back – my knowledge of Git has improved and the insight into how other people code and their thought and design processes has been invaluable.

There’s nothing stopping you – find a project that you believe in and help out !

This is part 4 of my journey into learning Git, using GitHub and contributing to an open source project.

• Introduction
• Part 1 – Install Git
• Part 2 – Set up GitHub
• Part 3 – Fork project
• Part 4 – Contribute code
• Part 5 – Submit pull request

The feature

The feature in SolrNet that I was interested in updating revolved around using the built in Service Locator to support multi-tenancy.

No one had volunteered their time to implement this feature as can be seen by a thread in the SolrNet Google Group, so I decided to jump in and implement the feature.

Committing the implemented feature

After implementing the feature I was ready to commit my code to my local repository which was located in my C:\Projects\GitHub\SolrNet folder. I ran the git status command via the Git Bash shell. This will show any new files that I have created or any changes to existing files that I have made.

git status

The Changed but not updated list refers to files that have been modified in the working directory but have not yet been staged. The Untracked files list refers to new files in the working directory that Git does not have in a previous snapshot (commit). All these files need to be added to the staging area in preparation for the commit.

The staging area is where changes can be grouped before being committed. This gives you a lot of flexibility in what actually goes into a commit. There is a nice explanation on the git ready site.

I ran the git add command via the Git Bash shell for each of the files that I needed to add to the staging area.

git add

I then ran the git status command via the Git Bash shell again to confirm that the files were now all in the staging area of my local repository.

I ran the git commit command via the Git Bash shell to commit the changes from the staging area. The -m switch allows you to specify the commit message. I used the issue details Issue 83: Support for multi core using ServiceLocator as my commit message.

git commit -m

I ran the git status command again via the Git Bash shell again to confirm that all staged changes had been committed in my local repository.

Pushing commits to public repository

You may have noticed the following message in the last screenshot: Your branch is ahead of ‘origin/master’ by 1 commit. This is showing that my local repository now has a commit that is not in my public paulbouwer/SolrNet repository. To confirm that the name origin references my public paulbouwer/SolrNet repository I ran the git remote command via the Git Bash shell. The -v switch switches on verbose messages and the show -n action and switch specifies the name of the remote.

git remote -v show -n

I next ran the git push command via the Git Bash shell to push my commit to my public paulbouwer/SolrNet repository on GitHub. I am pushing my local changes to the master branch on my origin remote. Note that the password here is not your passphrase but your GitHub account password.

git push

A final git status command via the Git Bash shell confirms that my local branch is no longer out of sync with my public paulbouwer/SolrNet repository on GitHub.

Confirmation

The commit pushed up to my public paulbouwer/SolrNet repository on GitHub is clearly visible under the Commits tab. Clicking on the commit hyperlink for the commit will take you to the details of the commit.

Next is submitting a pull request and getting the code accepted into the master repository …

This is part 3 of my journey into learning Git, using GitHub and contributing to an open source project.

• Introduction
• Part 1 – Install Git
• Part 2 – Set up GitHub
• Part 3 – Fork project
• Part 4 – Contribute code
• Part 5 – Submit pull request

Configure Git Options

Since I was about to fork a project and start dealing with code it seems like a good time to configure my identity within Git. Git uses your name and email address to sign your commits.

This can be achieved via the Git Bash shell by typing the following commands:

git config --global user.name "your_full_name" git config --global user.email "your_email_address"

The global switch applies this information to all of your projects. If you would like to override options for a particular project leave out the –global switch when in that project.

The following command will list out all your configured options:

git config --list

GitHub Workflow

The typical workflow of contributors to an open source project hosted on GitHub can be a bit intimidating. It involves the following steps:

• Fork
• Clone
• Write and commit code
• Push
• Submit pull request

I’ll discuss the first two steps (fork, clone) in this post and will cover the remainder in the next two posts.

Forking the SolrNet Project

The SolrNet project was created by Mauricio Scheffer and is hosted on GitHub at https://github.com/mausch/SolrNet.

To contribute code to a project on GitHub typically starts with you having to fork the project. Forking the project creates a copy of the master repository with a complete history under your GitHub account. This is great since it allows you to start contributing code and have the changes publically available to anyone who wants them – you don’t need commit access to the master project.

I navigated to the master project mausch/SolrNet page and clicked on the Fork button.

GitHub managed the forking of the master project and created a forked copy for me. It is now available at https://github.com/paulbouwer/SolrNet. GitHub also clearly shows that the project has been forked from the original project mausch/SolrNet.

Git is a distributed version control system which allows greater flexibility in how developers contribute and collaborate on projects. I don’t have commit access to the master repository mausch/SolrNet so GitHub helped me fork the repository to create a public repository paulbouwer/SolrNet to which I have read/commit access. So now I can commit changes into my paulbouwer/SolrNet repository and Mauricio can pull any of my commits into the master mausch/SolrNet repository (if he wants them).

Cloning your GitHub repository

A typical and common workflow in Git is to have a private local copy of your public repository. This allows you to have a working space that is under revision control. Once you are happy with the changes you have implemented you can roll them up into a single commit to your public repository and ask the maintainer of the master project to pull your commit into the master repository.

Obtaining a private local copy of your public repository is achieved using the git clone command. As the name suggests this is a clone of the repository (as opposed to a checkout in SVN). The cloned repository contains its own copy of the entire history of the project.

First we need the public repository URL from GitHub. I was having some firewall issues with SSH so decided to use my HTTP URL.

I ran the git clone command from the C:\Projects\GitHub folder via Git Bash shell. When prompted for a password enter the key passphrase for the SSH key registered with GitHub.

git clone https://paulbouwer@github.com/paulbouwer/SolrNet.git

This successfully cloned my public paulbouwer/SolrNet repository into my C:\Projects\GitHub\SolrNet folder as can be seen above. You can also see that the master branch is the active branch at the moment.

You can also clone a repository via TortoiseGit by clicking on Git Clone … on the right click context menu in Windows Explorer in the C:\Projects\GitHub folder.

After providing your SSH key passphrase TortoiseGit will begin the clone.

TortoiseGit has successfully cloned my public paulbouwer/SolrNet repository into my C:\Projects\GitHub\SolrNet folder as can be seen above. This is missing some of the contextual information we saw in the Git Bash shell such as the current active branch. I prefer using the Git Bash shell as it gives me more information and finer grained control. I will continue purely with the Git Bash shell for the rest of this series of posts.

Adding remotes

Now that I have a local copy of my repository I need a mechanism to manage changes between it and my public repository paulbouwer/SolrNet. I also need to manage changes between my local repository and the master repository mausch/SolrNet. This is achieved using the remotes concept in Git.

From the Working with Remotes section of the Pro Git book:

Remote repositories are versions of your project that are hosted on the Internet or network somewhere. You can have several of them, each of which generally is either read-only or read/write for you. Collaborating with others involves managing these remote repositories and pushing and pulling data to and from them when you need to share work

I obtained the HTTP URL of the master repository mausch/SolrNet.

I added a link to the master repository using the git remote command via the Git Bash shell. I used the typical remote name of upstream to denote the master repository mausch/SolrNet. I used the git remote command to also verify that the remote was added correctly.

git remote add upstream https://github.com/mausch/SolrNet.git git remote –v

The remote link to the master repository has been successfully added under the name upstream. But what is that remote named origin and how did it get added? When you clone a repository, Git automatically adds a remote to the repository you have cloned with the name of origin.

I then ran the git fetch command via the Git Bash shell. This fetches any changes from my upstream remote and pulls them down into my local repository. I did not do this for my origin remote since I know that I have just cloned my local repository from it.

git fetch upstream

The git fetch command fetches changes across all the available branches.

The final step is now to run the git merge command via the Git Bash shell. This will merge the fetched upstream changes into my local repository.

git merge upstream/master

I was only concerned about the master branch changes and therefore that is all that I merged in from the upstream fetch. You can also see that since I had just forked my public repository and cloned my local repository from that there were no changes to merge in.

Now I have a public repository that I can use for pull requests and an up to date local repository that is ready for me to start coding in. Next is writing some code …

This is part 2 of my journey into learning Git, using GitHub and contributing to an open source project.

• Introduction
• Part 1 – Install Git
• Part 2 – Set up GitHub
• Part 3 – Fork project
• Part 4 – Contribute code
• Part 5 – Submit pull request

What is GitHub ?

GitHub is the popular web-based hosting service for projects that use the Git revision control system. It has a large number of project management, code hosting and community based features.

Sign up for GitHub

GitHub offers a free account for open source projects. This account has an unlimited number of public repositories and public collaborators. There are also plans that cater for private repositories and collaborators.

The source code for the SolrNet project is hosted on GitHub so I signed up for the free plan and created myself an account on GitHub.

Once you have updated the Public Profile and Email Addresses sections of your account you will notice that you need to associate an SSH public key with your GitHub account.

Generate an SSH key

Fire up the PuTTY Key Generator executable puttygen.exe found in the PuTTY install folder.

Select the SSH-2 RSA radio button and ensure that the number of bits is set to 1024. Click the Generate button to generate the public/private key pair.

Cryptography calls for unpredictable random numbers. A simple way to obtain this randomness is to generate it from the user. The PuTTY Key Generator uses random mouse movements to generate randomness.

Give the generated key a comment and provide a passphrase. The passphrase provides an extra layer of security for your key. This is not my actual key but even if it was – all that is visible here is my public key which is meant for public distribution anyway …

Create a .ssh folder in your home folder. I created a C:\Users\paul\.ssh folder. Save your public key into this folder by clicking on the Save public key button.

Save the private key into your .ssh folder by clicking on the Save private key button.

You should now have a public/private SSH key pair for GitHub. My public key is github_rsa and my private key is github_rsa.ppk. Never let anyone have access to your private key !

Add public key to GitHub

Now we are ready to add our newly generated public SSH key to GitHub. Highlight the text in the Public key text box and copy it to the clipboard (CTRL-C).

If you have already closed the PuTTY Key Generator I’ll show you how to load the key back up. Fire up the PuTTY Key Generator executable again and click on the Load button.

Select your GitHub private key file and click on the Open button.

You’ll be required to provide your passphrase to load the private key.

Now highlight the text in the public key text box and copy it to the clipboard (CTRL-C).

Go back to the SSH Public Key section in your GitHub account. Click on the Add another public key link.

Paste (CTRL-V) the public key from your clipboard into the Key text box. Provide a Title for your key and click on the Add key button.

GitHub is now set up with your SSH public key.

Next is forking the SolrNet project …