Introducing Subversion (SVN) Into Your Team

Here’s a listing of items that may be of challenge when introducing it to a team who has no previous SVN experience. Version control is a rewarding experience, and once you get the hang of it, you’ll be wondering how you lived without it.

1.  (Most) everyone using SCM for the first time. Have to be familiar with:
  a.  Subversion concepts
    i. Terminology
    ii. Best practices
  b. Tools:
    i. Tortoise Concepts
    ii. Subclipse (Programmers)
  c.  Quirks
    i. Sometimes the icon overlay won’t show in Explorer
    ii. Thumbs.db file can make the status of the directory misleading
    iii. Updating code in MacOSX’s finder can corrupt the SVN metadata 
         because a native SVN shell (e.g. Tortoise) isn’t being used.
  d. Troubleshooting (I sent out a list of 10+ SVN issues and how to 
    i. What do you do when you get this type of error?
  e. Undoing the way things were done before an SCM tool was used
2.  SVN Performance
  a.  Performance of the SVN repository is dependent on use
    i. If programmer-A does intensive SVN operations, like checkouts, it 
       slows down operations for everyone else – programmer B has to 
       sometimes up to 20 minutes to view the revisions of 1 file. 
  b. Performance of SVN client is dependent on network
3.  Development Workflow between all members  
4.  Deployment to STAGING + PRODUCTION
  a.  A better process for deploying to STAGING:
    i. If a change set that has to be deployed to STAGING is small 
       (e.g. <10 files under 1 folder), it can be done manually, which 
       takes seconds.
    ii. If a change set is large (10 files, however, dispersed 
        throughout a code base), gets more error prone (done by hand) 
        and is better done through automation.

Tag a Revision using Subclipse

Tagging a revision is a simple task if you’re using the subclipse plugin for Eclipse. For this example, we’re going to tag the trunk in our repository. This also assumes that your repository uses the traditional “3 directory setup” of branches, tags, and trunk.

1. Make sure you have a SVN View tab in Eclipse.

To do this, go to:
Window > Show View > Other > SVN > SVN Repositories

2. Under “WebSites” (in the following screenshot), right click on the trunk, and select “Branch/Tag…”:

3. Make sure you use the appropriate tag version that adheres to your versioning needs. Also, make sure it’s under the “tags” folder: svn://WebSites/Project-2/tags/

World’s Smallest Program

Ouch, I guess the dream I had for having the world’s smallest program has been crushed. I made a program a long long time ago in Assembly using Windows 95’s DEBUG.EXE that rebooted the computer. The reason why it’s so small is that it reboots the computer, so once the BIOS Interrupt executes, there’s no need to do any other clean-up or maintenance. Unfortunately after Windows 95, Microsoft got smart and disabled DOS from executing these interrupts from DEBUG.EXE. Here was the code:

A 100
INT 19

But what I really want is to see the code for this 0-byte code program written in C.

Recursion vs For-Loop

So I’m currently in process of reading the infamous “Code Complete” by Steve McConnell. So far it’s been an amazing book and I definitely guarantee it to any programmer out there. I’ve just read the section on recursion and it mentioned how doing recursion for a factorial (or fibonacci) function is not as efficient as a for-loop iteration. I guess I never thought about it, since in computer science I was always shoved recursion down my throat when doing factorials. I agree with him that computer science professors are eager to apply the idea of recursion on factorials, but I’ve never remembered a professor mention that it’s not the most efficient way. McConnell states in the book that doing recursion in factorials:

  1. Is not as fast as a for-loop.
  2. Not as clear to read as a for-loop.
  3. Use of run-time memory is unpredictable.

Just for fun, I wanted to test his point on speed. This is a Python script that tests the average speed of a factorial using a for-loop or recursion. I noticed that for numbers less than 3000! the time it took for both functions were exactly the same. It was only when I bumped it up to 5000!, which is a huge number (16,327 digits). Luckily Python lets you work with very large numbers easily. Just had to increase the number of recursion calls in Python from the default 1000.

import win32api
import sys
def factorial_forloop( n ):
  count = 1
  for i in range( n, 0, -1 ):
    count = count * i  
  return count
def factorial_recursion(n):
  if n == 0:
     return 1
     return n * factorial_recursion(n-1)
total_time_recursion = 0
total_time_forloop   = 0
number_of_tries      = 500
for i in range( 1, number_of_tries ):
  start = win32api.GetTickCount()
  factorial_recursion( 5000 )
  end = win32api.GetTickCount()
  total = end - start  
  total_time_recursion += total
  start = win32api.GetTickCount()
  factorial_forloop( 5000 )
  end = win32api.GetTickCount()
  total = end - start
  total_time_forloop += total  
print "\n"  
print "Average time for recursion: ", ( total_time_recursion / 10 ) * .001
print "Average time for for-loop: ", ( total_time_forloop / 10 ) * .001

So in 500 tries, the results were as follows:

Average time for recursion:  1.284 seconds
Average time for for-loop:   1.083 seconds

It doesn’t seem by much but the results are interesting. But then again, a factorial is a very simple algorithm. In future posts I’ll try to test more complicated algorithms and see how they battle out. Also, this is Python. The results for C, C++, or Java may differ.

High Performance Websites

This was a great read. Certainly learned a lot of useful lessons on front-end optimizations. Written by Steve Souders (previously lead Optimization efforts at Yahoo!), who also developed YSlow! – a Firefox add-on (actually an add-on to the Firefox add-on called Firebug) that gives your web pages a grade from A through F and tells you how to make it better.

If you have a build script, you may be able to automate a lot of these things, like combining JS and CSS files, and optimize PNG files (check out to see how to optimize from the command line). If you’re going to optimize JavaScript, I would recommend YUI Compressor ( since it’s not as greedy as Google’s Closure Compiler for JavaScript. The Closure compiler ( is relatively new and you may get even smaller files, but if your JavaScript is complex, it may have bugs because it’s a greedy compiler.

Anywhoot, here’s what I got from it:

  1. Reduce as many HTTP requests as possible.
  2. Minify JavaScript (don’t obfuscate, because it’s more trouble than it’s worth for the benefits you get)
  3. Minify CSS and optimize it (reduce duplication).
  4. Future-expire resources for caching (PNG, JPG, GIF, JavaScript and CSS).
  5. Minify HTML (get away from tables)
  6. Put CSS at the top, put JavaScript at the bottom.
  7. For design components (background images, button images, nav images), use CSS sprites.
  8. Use PNG for design components (they compress better than GIF, have partial transparency, and can have greater color palettes).
  9. Gzip non-binary data like HTML.
  10. Combine CSS and JavaScript into single files to reduce HTTP requests.

A summary of his optimization rules are found here, but of course, it’s not as detailed as the book: .

Stoyan Stefanov, another prominent developer who’s written tons on JavaScript and optimization, published 24 articles this month on optimization. I find these articles invaluable. It’s recent and he does actual optimization tests and tells you what tools he uses. Here’s the site:

Handy Free XML Tools

Here are two handy apps I use when I have to parse XML data.

firstobject XML Editor – This is a great tool that I primary use for formating XML into a more readable format. I just paste it in the editor, hit F8, and it beautifies it. It does more than that, but that’s what I use it the most.


Buba XPath builder – This is a nice tool where you can create an XPath search string and it shows you the results in real time by applying it to your XML data.


JSDB from Aptana Studio

Aptana Studio is a great free IDE for JavaScript. By default, you can use the its Jaxer engine to interpret your JavaScript code. However, if you prefer to use JSDB, a more console-oriented interpreted based on Mozilla SpiderMonkey, keep reading. This will set you up so that from Aptana Studio, you can write JS code, and interpret it by hitting F5 and seeing results in the bottom panel.

1. Select External Tools


2. Enter the following in the textboxes:


Make sure the path to your project doesn’t have spaces! (bug with Eclipse)

3. Set the hotkey to F5 so it runs the external tool:


Best Practices for Speeding Up Your Web Site

Yahoo has this awesome article on speeding up your web pages. Granted, most of this could be plucked out directly from your site using the Yahoo! YSlow Firefox add-on, but I highly recommend you checking it out. Here’s a summary of what they have to offer:

  1. Minimize HTTP Requests
  2. Use a Content Delivery Network
  3. Add an Expires or a Cache-Control Header
  4. Gzip Components
  5. Put Stylesheets at the Top
  6. Put Scripts at the Bottom
  7. Avoid CSS Expressions
  8. Make JavaScript and CSS External
  9. Reduce DNS Lookups
  10. Minify JavaScript and CSS
  11. Avoid Redirects
  12. Remove Duplicate Scripts
  13. Configure ETags
  14. Make Ajax Cacheable
  15. Flush the Buffer Early
  16. Use GET for AJAX Requests
  17. Post-load Components
  18. Preload Components
  19. Reduce the Number of DOM Elements
  20. Split Components Across Domains
  21. Minimize the Number of iframes
  22. No 404s
  23. Reduce Cookie Size
  24. Use Cookie-free Domains for Components
  25. Minimize DOM Access
  26. Develop Smart Event Handlers
  27. Choose over @import
  28. Avoid Filters
  29. Optimize Images
  30. Optimize CSS Sprites
  31. Don’t Scale Images in HTML
  32. Make favicon.ico Small and Cacheable
  33. Keep Components under 25K
  34. Pack Components into a Multipart Document

Another great article to check out is this one.