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/

By default, CTRL+Tab (forward switching of windows) and CTRL+SHIFT+TAB (previous switching of windows) aren’t set in Eclipse to switch between editors windows. There are other Eclipse, non-standard defaults like CTRL+F6 for forward switching. To set these shortcuts, do the following:

1. Run Eclipse
2. Window -> Preferences
3. General -> Keys
4. Search for: Next Editor
5. Put the cursor in the “Binding” textbox and delete that hotkey. Then, press and hold CTRL+TAB
6. Hit Apply.
7. Search for: Previous Editor
8. Put the cursor in the “Binding” textbox and delete that hotkey. Then, press and hold CTRL+SHIFT+TAB
9. Hit Apply and OK.

Apply similar steps for Ctrl+Shift+Tab.

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:

N REBOOT!.com
A 100
INT 19
 
R CX
2
W
Q

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

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
 
sys.setrecursionlimit(10000)
 
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
  else:
     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.

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 http://www.phpied.com/give-png-a-chance/ to see how to optimize from the command line). If you’re going to optimize JavaScript, I would recommend YUI Compressor (http://developer.yahoo.com/yui/compressor/) since it’s not as greedy as Google’s Closure Compiler for JavaScript. The Closure compiler (http://code.google.com/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: http://stevesouders.com/hpws/rules.php .

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: http://www.phpied.com/performance-advent-calendar-2009/

Don’t know how long Google Code Playground has been around, but it’s a mini-editor that will let you code in JavaScript (with color coding!), interpret it on a bottom panel, and even show you results from various Google API snippets. Awesome tool.

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.

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:

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.

I’ve listed some of the technologies I’ve either worked with or want to add to my personal arsenal. It’s overwhelming sometimes how much a developer has to know. Here’s a mindmap neatly categorized (labeling/categorization can be debated).