Matthew Cooke

I mainly do Java development using Eclipse with SVN but recently I've been playing around with a bit of iphone development using XCode.

I've included some below some Gotchas about using XCode with SVN in the hope that it might save someone else making the same mistakes as me...

• The left hand navigator pane in xcode labelled files and groups does not show a filesystem view of the folder containing the project files.
• XCode projects need files adding in manually - the project structures does not have to match file system directory structures at all.
• You will probably want to exclude the build directory - XCode will not do this for you.
• Be aware that's it's easy to accidentily create links to files in the projects rather than putting the files into the project folder itself. Make sure when you drop a file into the project that you are copying it into the actual project and not just linking to an external file.
• Committing the files to version control. When you are committing you will probably also want to commit the project file itself, you may this file if you aren't looking for it but it should show up in the SCM section. This file contains the list of all the files that are actually in the project, so if you don't commit this then the files will all be under version control but when you checkout the project on a fresh machine the files won't be included in the project, probably leaving the project with breakages.
• New files that are placed in the project will not be added to version control even if the parent folder is already under version control and the entire project was checked out from an SCM such as SVN originally.
• When using XCode to check out from a repository - you probably then want to tell XCode that the project is from that repository.
• There is no way to get a graphical project level diff within Xcode, such as the syncronization view in Eclipse which helps you to merge and rollback changes prior to doing a commit. File level diffs can be done and to get an idea what files in the project have changes you can right-click the groups and files header on the left hand navigation panel and select SCM, this put a letter next to files depending on their state.
• You may want to exclude your user files inside foo.xcodeproj/blah.pbxuser as this has user specific settings

This is how I managed to resize a VMware image for Fedora 8.

I started with a VMware Fedora 8 from thoughtpolice and a copy of VMWare Fusion.

Step 1 Resize the virtual disk

Under OS X run:
/Applications/VMware Fusion.app/Contents/MacOSdiskTool -X 40Gb fedora-8-i386.vmdk

(where fedora-8-i386.vmdk is the VMWare disk image file)

Step 2 Create an Ext3 partition in the free space.

Download the latest GParted ISO.Connect it to Vmware Fusion (VirtualMachine | CD/DVD | Choose Disk Image)

Restart Vmware but during the initial boot go into the virtual bios settings and change the boot order to make CD boot before hard disk.

Restart VMware to boot up GParted. (You can not resize the partition as it shows as unknown - but do not cry at this point!)
Select the free space and turn it into an ext3 partition.

Shutdown and disconnect the Virtual GParted CD Image.

Step 3 Adding the new partition into the Logical Volume.

I booted up into fedora to change the Logical Volume size - this may not be the best way to do it but it worked for me. then as root i executed the following.

pvcreate /dev/sda3

vgextend VolGroup00 /dev/sda3
vgdisplay -v VolGroup00

Somewhere it will display a number for Free PE on /dev/sda3

Now enter
lvextend -l xxxx /dev/VolGroup00/LogVol00

where xxxx is the Free PE number.

Finally the last step is a bit scary it resizes the partition to make use of the larger volume whilst the filesystem is mounted. But it did seem to work for me!

resize2fs /dev/VolGroup00/LogVol00

After a while the result should show something like:

resize2fs 1.40.2 (12-Jul-2007)
Filesystem at /dev/VolGroup00/LogVol00 is mounted on /; on-line resizing required
old desc_blocks = 1, new_desc_blocks = 2
Performing an on-line resize of /dev/VolGroup00/LogVol00 to 8380416 (4k) blocks.
The filesystem on /dev/VolGroup00/LogVol00 is now 8380416 blocks long.

And bingo my disk size has gone up from 7gig to 30Gig

[root@localhost dev]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
31G 3.1G 27G 11% /
/dev/sda1 190M 13M 169M 7% /boot
tmpfs 125M 12K 125M 1% /dev/shm

“In the middle of difficulty lies opportunity.”

Developers love redeveloping the wheel and writing caching code is a typical example of this. I have seen several examples of developers writing custom caches inside their web applications without considering if they would be better off using standard proxy caching.

Sometimes you do need to write your own caching code. One case you might need to write your own cache (or wrap ehcache) is if you need partial page caching - but for a lot of cases using standard HTTP proxy is a much better option.

Here are some of the many advantages of using standard HTTP proxy caching:

• Faster pages since resources can be served from the Web-browser cache, ISP caches, office caches and various other caches on the internet which are closer to the client than your server.
• Save bandwidth since you have to serve less content from your origin server(s).
• You can add caching directly on your server by installing one of several free high performance reverse-proxy caches.
• Configure expiry times for resources in one place on your server for *all* the caches, and have all these caches work in a hierarchy right back to your server cache - totally transparently.

That is the beauty of using standard proxy caching.

So, how does it work and what do you need to do?
Let's look at the steps involved to make use of all the caches between your server and the client and to add an additional cache on your server (a cache of last resort!).

Step 1 - Set Correct Expiry Headers for Web Pages you Serve.

For each resource you serve that you want cached, you need to set caching header that the server will use in the HTTP response. There are various headers related to caching but one that you can use is the cache-control with the max-age directive. You can google to find out how to set this for a resource on your particular application server or web server.

Step 2 - Test the Expiry Headers are Working.

There are many ways you can test if the headers are being set successfully. The easiest may be to check in the browser cache to see when the content expires. If the content is not being cached properly you probably want to check that the server does actually send the headers correctly that you tried to configure in step 1. You can install livehttpheader to see headers in firefox or you can use ethereal to scan the network traffic and get the headers from that (ethereal can take a while to get to grips with but it is really neat).

Step 3 (Optional) - Adding a Reverse Proxy server

If you want additional caching on your server to further offload resources from your application server you can install a reverse proxy cache. This article explains how to configure squid as a reverse proxy, I have done this for viralvideochart.com and it works nicely acting a cache that sits in front of our application server.
There are many other reverse proxy caches around (the full version of the Resin application server has one built in for example).

Step 4 - Enjoy Blistering Fast Serving Speeds!

That's right with the correct HTTP headers set and a reverse proxy configured on your server, as the load on the cacheable resources goes up a reasonable reverse-proxy should be able to approach static file serving speeds! Thus offloading a lot of needless work from your application and database server without the need to write yet another application cache.

"...when this baby hits eighty-eight miles per hour... you're gonna see some serious shit."