After much speculation yesterday, marked by a leaked web comic and finally an acknowledgment by Google, Google Chrome, the much anticipated web browser, is here.

I encourage you to download it and give it a try, as I did as soon as it came out. Here are some of my initial impressions.

Overview

Google released a fairly long web comic that delves into quite a bit of detail about Chrome - it’s not your typical comic! Touted as being built “from scratch”, Chrome uses the WebKit rendering engine, the same one that powers Safari and Konqueror.

The first thing you notice is how minimal the “Chrome” or UI of Chrome is. If you’re used to a half-dozen toolbars, buttons and widgets all over the place, Chrome will seem like a greenfield to you. By default, there is only a tab bar and then an address bar containing back, forward, a combined reload-stop button and the address bar. There are also buttons for bookmarking a site and for page and browser settings. The bookmarks bar is not displayed unless you specifically change that setting.

Keyboard shortcuts are also present so that you don’t have to click through context menus. If you’re used to the keyboard shortcuts of Firefox and IE7 you’ll be pleased to know that most of them transfer over without change: Ctrl-T opens a new Tab, Ctrl-W/Ctrl-F4 closes a tab, Alt-D focuses the address bar and Ctrl-J opens Downloaded Files.

The address bar also functions as a search bar, and this combination just makes sense. It’s something I’ve always been doing using Firefox Quick Searches

By default the home/start page is set to set to show an Opera-style “Speed Dial” page containing most recently-accessed pages/bookmarks. You can also configure Chrome to restore the previous tabs/websites on startup, which is my personal preference ever since I started using Firefox.

Features

Chrome integrates Google Gears to speed up supporting web applications and is an obvious effort by Google to self-promote. This is substantial since the download link for Chrome is on the main Google search page - no small feat considering only the most popular/important services get that sort of attention and furthermore the link is positioned dead center beneath the search field.

The address/search bar

Chrome allows for quasi-Site-Specific Browsers by use of “Application Shortcuts”, which can be set for any website but are meant to be used mainly with web applications. These allow you to open the target URL in a browser window that does not have the menu or address bars and essentially serves as a blank canvas upon which the web application’s own UI can be displayed.

This is similar to other SSBs such as Mozilla Prism or Fluid for the Mac, as they aim to bridge the gap between desktop and web applications to make their integration more seamless.

However, like Google Blogoscoped points out, using such non-browser interfaces may condition the user to be more lax when entering their credentials and makes phishing attempts more viable since no URL is displayed. This is curious since security, “sandboxing” and general safe browsing were so high on Chrome’s feature list - this feature seems to help undo some good user practices of always confirming the URL before entering credentials.

There are also some nice little enhancements as well - the combined address bar/search bar is very much like Firefox 3’s “awesome bar”. Chrome also allows you to dynamically resize any textarea element, without the site designer having to code this specifically in JavaScript or some other client-side technology.

Performance

Each tab/window is a separate process and thus will show up separately in Task Manager; Chrome also offers its own Task Manager but the memory usage reported here differs from that in the Windows Task Manager. To get the full picture, you have to click on the “Stats for nerds” link, which takes you to about:memory

This page displays the full memory usage details, and also, surprisingly, displays memory usage for any other web browsers also currently running! (I have confirmed that it will display Firefox 2/3, IE7 and Opera 9)

Much talk has been made of this feature; indeed while it does use more resources, it also prevents a single site from bringing down the entire browser as only that tab/window will be affected. To test this out, just terminate one of the instances of chrome.exe and you will see that tab’s screen into a “sad tab of death” with an amusing message.

JavaScript

Though JavaScript falls under the category of `Performance` I felt it deserves its own section because of the importance of JavaScript in web applications. Chrome uses the Google-developed V8 JavaScript engine, which has also been released as open source.

The main points of V8 are outlined at the Google Code page for the project, and are quite interesting. One of the main improvements in performance is the use of a Virtual Machine (VM) for processing JavaScript.

The V8 Virtual Machine is different from say, the JVM (Java Virtual Machine) in that it compiles JavaScript source directly to machine code; there is no intermediate byte-code representation used and hence no interpreter is needed for this. This seems to indicate that JavaScript performance might be faster on Chrome since there’s no intermediary. Google provides some benchmarks to confirm this.

From some informal/unscientific preliminary testing, the V8 JavaScript engine in Chrome does appear to be quite fast; loading the same Digg topic in Firefox took longer than it did in Chrome. (Roughly 14 secs vs. 8 seconds over a few trials - and Chrome did not have the benefit of AdBlock Plus) I’d be very interested to see how Chrome stacks up against Firefox 3.1, considering the rumoured performance boosts coming with it.

If Chrome has anything going for it, it’s definitely the lightning fast JavaScript performance. Coupled with the crash-proofing this makes it ideal for use in web applications.

Development

Chrome comes with a nice DOM inspector reminiscent of Firebug. Using it is dead simple; you just right click and select “Inspect Element” and the inspection window will pop up with the element highlighted. Here you can see the full DOM tree as well as the computed CSS styles for the element.

There’s an included JavaScript console for executing code/commands/expressions on-the-fly and while there is a JavaScript debugger included, it seems at this time to be a command-line only tool, far less user-friendly than Firebug.

Not ready for prime time yet?

Of course, Chrome is marked as Beta by Google, something we’ve come to expect since Gmail has been in beta for longer than the company has been publicly traded. Nonetheless, there are still some features that are sorely missed.

The one thing I absolutely love about Firefox is the vibrant developer community and subsequent widespread availability of quality, useful extensions. This has produced such gems as the aforementioned Firebug and Adblock Plus.

For now, extensions/addons are not part of Chrome but may be added in a later version. In the meantime I don’t think I’ll be even close to ready to switch, as I’m very stubborn. I don’t use that many extensions but the few that I do are “must-haves” and I just can’t browse without them.

Lastly, there are always privacy concerns, especially from a company as big an involved as Google. Though you can turn off the sending of usage statistics, there will always be some with their tinfoil hats on.

Conclusions

All things considered, Chrome is a very good entry into the browser market. While I don’t think it’s ready to take on Firefox or IE yet, it does provide competition. So as long as Chrome continues to support standards (which I think it will, since it uses the WebKit renderer and Google has also been forthcoming with their support for web developers), I won’t have a problem with it. I won’t be switching over to it anytime soon, but at the very least it’ll be a useful development tool to verify/test my websites on to make sure they look proper in Safari/Konqueror/Chrome.

This made it somewhat tedious to decode them, as the only way to get the original list of points was to create a GPolyline and then pull out the points from that object. This is not ideal since the work must always be done on the client side with JavaScript and using Google Maps.

To solve this, I quickly ported the algorithm over to PHP from the JavaScript source. Please feel free to download/modify/use this script.

Since the encoded polyline format offers numerous benefits (and because I had data already stored in this format) I did not want to move away from it. At the same time, I needed access to the points for working with things like Google Static Maps, which curiously does not accept the encoded polyline format for displaying paths. (Probably to reduce resource usage on their end, since decoding takes CPU time)

Thankfully the polyline decoding algorithm was already available at Mark McClure’s site. I spent a few minutes understanding the process and porting it over to PHP. The source is attached above and is released under an MIT license. Basically, the only change I had to make was to use some PHP functions to convert characters to their ASCII code, since PHP doesn’t have a charCodeAt() function.

Please let me know if you find it to be useful.

However, it was a project that I intended to learn from, and in that regard, I think I’ve succeeded - and that’s really what I want to continue doing for the rest of my life. Furthermore, while the project was an exercise in improving my web and software development skills, the end result will also be something that I will actually use myself - not just some pointless academic exercise. Another nice effect was the experience of seeing a self-directed project come to fruition over the last few months - albeit at a slow rate, usually only several hours per week, but nonetheless I’ve improved my self-discipline as a result.

I will say that you can get somewhat of an idea of what this site will be about by browsing through some of my previous posts. But, that’s all I’m going to say at this point.

I had been using input validation, but my validation procedure was not stringent enough to detect the improper parameter. This was tied to the fact that before the implementation change, things worked perfectly fine even with the improper inputs. However, the implementation change “broke” this work flow. All of this has led me to believe in the great importance of:

1. Draconian validation: For inputs, only accept what you say you will accept. Nothing else should pass.
2. Proper unit testing: Test your method with a variety of inputs, both expected and unexpected or non-conforming. You never know what callers will pass into your methods.

Let me go into some more detail.

Unintended consequences

I had written a method that would accept a FQDN (Fully-Qualified Domain Name) as its argument. The purpose of this method was to retrieve some information over HTTPs from the web server running on the server with the specified domain. Since domain names are protocol-neutral (i.e. they aren’t preceded by something like “http://”), I ended up forming a URL object based on the FQDN, since eventually I’d be retrieving information over HTTPs anyways:

final URL url = new URL("https://" + fqdn + "/path_to_service");

I figured that this was enough protection in terms of input validation, since the constructor for URL throws a MalformedURLException if something goes wrong. (There was other code to check if the web server at the specified URL could actually be contacted and this was contained in the actual retrieval)

However, it turned out that callers had started using this method by passing in not just an FQDN, but an FQDN followed by a port number in the following format: host.name:portNumber. This was being used so that servers operating on non-default HTTPs ports could be contacted.

Initially, this worked, as then the statement above was executed with something like this:

// With fqdn == "some.host.name:portNumber", nothing fails.
final URL url = new URL("https://" + fqdn + "/path_to_service");

This was because the URL formed was still valid. However, this was an invalid use of my method because we had never specified that this sort of input was allowed. It just happened to work. The issue of non-default HTTPs ports and the usage here was never discussed and because it seemingly worked, nothing was done about it.

Changing times

Some time went on until I decided to make an implementation change. Instead of retrieving the information from the web server itself, I would instead retrieve it directly from the TLS handshake process using a API provided to me. (The information was related to the certificates)

This API accepted two parameters: The server host name or FQDN, and a separate port number. Not realizing that callers were passing in non-default port numbers in the first place, I ignorantly just passed the FQDN supplied to me into this API along with the default HTTPs port. (443)

As expected, this broke the functionality that callers had come to expect of my API, namely, custom HTTPs ports specified alongside the FQDN in the argument. It was only after these complaints were filed that I realized my API was expected to take not just the FQDN, but something like “server.host.name:8080″.

The causes

The problem was quickly fixed as the solution was fairly trivial, but the causes have taught me several lessons.

1. Be Draconian in your input validation

   Or, don’t trust your callers to read your documentation. Initially, I thought my method was to accept only an FQDN. Even though I was wrong in this respect, the problem could’ve been identified earlier if I had coded my method to fail (i.e. throw an exception) if anything that was not an FQDN was passed in. (Simply forming a URL object around it was not stringent enough) This way, things wouldn’t have initially worked by coincidence and I would’ve had an earlier opportunity to correct my mistake.

2. Unit test for exceptional cases

   My unit testing of my method was not extensive enough. Though I coded both pass and fail tests using JUnit, I did not test for cases where someone would (very likely) try to pass in a port number along with the FQDN. This step goes hand-in-hand with the above: Code your methods to accept only what you’ve said they’d accept, and fail on everything else. Then, unit test to make sure this contract is fulfilled.

While the problem was frustrating, I’m glad to have learned these lessons.

I’ve been playing around with the Google Maps API for a bit and it’s turned out to be a great way to get started with “mashups” and the like. One of the best uses of the API is the ability to create paths or routes on the map.

This is done by creating GPolyline object and then adding it as an overlay to the map. Basically, a polyline is just an ordered list of geographical points/coordinates on the map, each of which is a GLatLng object. For serialization/storage of polylines, there is an algorithm you can use to Base64-encode a series of points; the resultant string can later be passed directly into a factory method to regenerate the GPolyline. By using encoded polylines, you also get access to a few more interesting and useful options related to rendering and performance issues.

Encoded Polylines

Despite the algorithm for encoding polylines being readily available on the Google Maps API documentation site, there is no built-in functionality within the API for generating the encoded polyline string from an existing GPolyline object. This might be a bit strange, but it’s probably because the encoding process requires some extra values that aren’t available in the typical polyline.

As specified on the algorithm page, you also need to specify a list of encoded “levels” in addition to the points themselves. These levels tell the the Google Maps renderer when certain points can be omitted from the polyline depending on the zoom level. For example, with a polyline with n points, you’ll always want to show the first and last point, no matter what the zoom level. However, intermediate points can potentially be omitted at low zoom levels and only shown when the map has been sufficiently zoomed in to warrant the detail. This sort of optimization cannot be done with the typical GPolyline constructor that just takes an array of points. (GLatLng objects)

Making things easy

If you’ve looked at the polyline encoding algorithm, you’ll probably notice that it’s a bit tricky unless you’ve taken course in CS or done a lot of this stuff before. (At least it was tricky for me) Google has an interactive utility for generating the encoded polyline format for you. The results can then be stored and later fed into a call to the factory method GPolyline.fromEncoded() to regenerate the polyline.

However if you want to generate the encoded polyline format on-the-fly as part of your application, the interactive utility is not really an option. Instead of coding the algorithm from the ground-up, there’s a much better way of doing things, thanks to the PolylineEncoder class and other utilities provided by Mark McClure.

The PolylineEncoder class is written in JavaScript and is very straightforward in its usage. (It has been ported to several other languages as listed on his site, in case you need to use it in different contexts)

Using this class allows you to quickly and easily convert a GPolyline into a compact encoded format useful for serialization or storage. You can also use the class to convert arrays of points into encoded polylines, thus gaining the benefit of optimized rendering at different zoom levels. McClure goes into an in-depth, but easy to understand explanation of the encoding algorithm used complete with animations that show exactly how the polyline approximations work.

I highly recommend the usage of his polyline encoder as it saves you the headache of implementing it yourself. It’s well-written, thoroughly documented and is free for usage. (It isn’t licensed under open-source terms but has instead been placed in the public domain - which is perhaps even more “free”) McClure also has a few other interesing Google Maps projects that you may want to check out.

Some documentation warnings

The Google Maps API documentation is fairly thorough, but it’s out of date in some places, as some people have found. Indeed, in this case, it appears that the GPolyline.fromEncoded() is documented somewhat wrongly in the API reference, though curiously, is used properly in their examples page.

Specifically, you should not use:

GPolyline.fromEncoded(color?,  weight?,  opacity?,  latlngs,  zoomFactor,  levels,  numLevels)

if you want to generate a polyline from the encoded format. Instead, you should use something like:

GPolyline.fromEncoded({
    color: "#FF0000",
    weight: 10,
    points: "yzocFzynhVq}@n}@o}@nzD",
    levels: "BBB",
    zoomFactor: 32,
    numLevels: 4
});

This is because the API has been updated to accept an object of options instead of separate parameters. This, in my opinion, is better for readability and takes advantage of JavaScript’s ability to define inline anonymous object literals.

As a side note, the example actually calls something like new GPolyline.fromEncoded, but I’ve found that you don’t need the new keyword, and in fact, it’s a bit confusing that the example has it and that it would work - after all, you are calling a factory method that returns a type of GPolyline, and not directly instantiating an object. (At least as far as JavaScript uses the new keyword)

I’m currently using CakePHP and finding it to be quite useful. The “automagic” handling of tables is useful for basic relationships, though more complicated setups usually require manual work. The MVC implementation has also clearly drawn inspiration from Ruby on Rails, which may be advantageous to some, though this has no bearing on me. Though there are a few things that nag me about CakePHP (such as lack of a good testing suite, though that’s supposedly fixed in 1.2, which really should be marked as version 2.0), overall it’s a great framework that adds badly-needed structure to PHP and has saved me time.

One thing I’d like to see, however, is a proper exception handling model. I realize this would require making it PHP 5-only, but in my opinion, PHP 5 adds some sorely-need features, such as the aforementioned exception handling model and a class/object system more in line with other languages.

Signaling intent

I’ve written about the benefits of exception handling before, so I won’t delve into those details again. In short, using exceptions is a better way for a method to signal to a caller that something went wrong rather than just returning a special/reserved value as an error code.

In particular, saving of models would benefit from this. Currently, if you want to check if the model was saved properly, you have to do something like this:

if ($this->ModelName->save($this->data))
{
  // Model saved properly, can continue normally here.
  ...
}
else
{
 // Model did not save properly.
}

It’s a little bit kludgy, but isn’t actually that bad since Cake simplifies form validation a lot with the HTML helper in views. You can simply put something like $html->tagErrorMsg('Post/title', 'Title is required.') in your view to display that error message when a particular field does not validate. This removes a lot of the tedium out of making your forms return proper error messages in situations with bad input.

Exceptional cases

However, in some situations you might want to execute your own logic when a call to Model::save() fails. In this case, having that method throw a proper exception would allow the error to be propagated to the controller nicely and would remove the need to make a call to Model::invalidFields() to get the reason.

Coming from a Java background, this makes more sense to me, since I consider its exception handling model to be one of the language’s strong points. It has numerous benefits to improving readability and maintainability of code.

However, there are some drawbacks, since this requires the use of PHP 5. As CakePHP is designed to be PHP 4 and 5 compatible, exception handling is really not an option. However, since PHP 4 is so old, I’d eventually like to see a move to PHP 5, especially for its better OOP model and exception handling. Additionally, PHP 6 is just around the corner, so I don’t really see a need to stick with PHP 4 for that much longer.

Additionally, if you’re just saving one model (as the result of a form submission) it doesn’t really make sense, nor is it necessary, to have exception handling since CakePHP already takes care of displaying error message for the invalid fields:

// Controller:
...
if ($this->Post->save($this->data))
{
  $this->flash('Your post has been saved.','/posts');
}
...

// View:
...
<?php echo $html->input('Post/title', array('size' => '40'))?>
<?php echo $html->tagErrorMsg('Post/title', 'Title is required.') ?>
...

In the above example, taken from CakePHP’s own blog tutorial, you don’t really need exception handling since the appropriate actions are automatically handling by Cake. If the save succeeds, a positive message will be displayed and the user forwarded on. Otherwise, the controller proceeds to render the given view, where $html->tagErrorMsg displays the given error message if the associated field was marked as invalid by the model during the save attempt.

For more complicated situations where you’re saving multiple related models in a single controller action, exception handling would be helpful in reducing the number of branches, since you wouldn’t need to have so many if ... else blocks muddling up the flow of the code. However, it’s not straightforward to integrate this into Cake, since for most of the time, people won’t need the exception handling capability if they’re just doing a simple save as outlined above.

The easiest way I see of accomplishing this is to define your own method that wraps around the existing Model::save() method so that proper exceptions can be thrown. This would, of course, create confusion as then there would be two ’save’ methods.

All things considered, Cake is still a strong framework, so I will continue using it. For all the slight concerns I have, it’s still very much beneficial to me. If there’s one more thing I could ask for from Cake though, it would be for better documentation! Maybe I should start contributing…

After seeing glowing recommendations for the heuristic-based ThreatFire anti-malware app from PC Tools, I decided to install it to complement my antivirus scanner and other anti-spyware tools such as Spybot-S&D and Ad-Aware.

Initially, it worked fine. While I don’t know how much protection it really added, it was intuitive, easy to configure and didn’t slow down my system like many other real-time scanners might have. However, I ran into some trouble with my web development environment, consisting of Apache, MySQL and PHP (in the form of XAMPP) that I could only attribute to ThreatFire’s presence.

The symptoms

With ThreatFire installed and enabled, requesting any pages from Apache that would result in MySQL access took painfully long. Accessing static pages or scripts that did not use the MySQL database did not hang. At first, I thought it was a problem with the application/scripts I was working on, but other popular third-party scripts, such as phpMyAdmin, were also slow or unresponsive. The server appeared to “hang” for about 10-15 seconds before producing any response. This was on a local server.

I tried several different courses of action, such as:

• Enabling logging of slow queries with the --log-slow-queries option.
• Adding the MySQL binaries (mysqld.exe and mysqld-nt.exe) to the ThreatFire exclusion/ignore list
• Reinstalling XAMPP

None of these worked. In particular, logging slow queries did not produce any logs, which seemed to indicate that MySQL was hanging even before the queries were executed. Surprisingly, logging the execution time of PHP scripts did not seem to indicate any problems either. The queries I was executing and that datasets I was working on were also small and unlikely to be a contributing factor - any query, no matter how simple, seemed to hang.

When I suspended or removed ThreatFire, the problems immediately went away. Strangely, as I noted above, adding the MySQL binaries to the exclusion list did not help. What was more interesting is that ThreatFire did not popup any warnings. Usually, when “suspicious behaviour” is detected, ThreatFire will prompt you for a decision. I did not notice any of this.

ThreatFire is not bad

The purpose of this is not to bash ThreatFire; it’s clearly a good tool and has definitive advantages, but just may not be well-suited to development environments where multiple servers are running. I also wanted to provide this information to anyone else who may have been struggling with a slow/unresponsive server because of the same situation as mine.

* Sensationalist headline inspired by previous posts

Eclipse is my IDE of choice, as you’l probably have noticed from some of my previous articles. I had been wanting to write an article about why I use it (and why I switched to it), but kept putting it off. Recently, Matt Mullenweg wrote about his problems with Dreamweaver, and this perhaps prompted me to organize my notes on why I’ve chosen to use Eclipse. Don’t get me wrong - I’m not advocating that you immediately switch and throw out your current editing tool (the headline above, as noted, is purely for sensationalism) - but rather I’m just urging you to consider Eclipse for your next project.

Changing Gears

Like many, before switching to Eclipse I had been using a pure text editor, Ultraedit, for most of my web-development activities. Ultraedit seemed fine for most things, offering basic features like code highlight and autocompletion. However, it lacked a certain finesse when it came to dealing with larger projects. For example, if you’d defined a class, its members wouldn’t be available for autocompletion. Something else was needed. I finally decided to take the plunge, and switch over to Eclipse for all my development towards the end of the summer last year.

Some might wonder why I was even using a text-editor in the first place for development. For those coming from a traditional programming/development background, the idea of not using an IDE (Integrated Development Environment) is silly. This is because a lot of programming languages are compiled, and in this case, it just makes sense to use an IDE since it’s easier to write code, compile and debug using one tool instead of multiple ones.

However, for scripting languages, especially those meant to run on a web server, one can “get away” with not using an IDE quite easily. This is because the scripts are not run standalone but are almost always executed in the context of a web server; thus you’re usually editing code that you then run on a development web server, without the need for a special tool like a compiler. Additionally, it’s easy to view the output using any web browser. These reasons are what allowed me to persist in using a text-editor for so long.

No turning back

However, once I started using Eclipse, I was hooked. I downloaded Eclipse PDT (PHP Development Tools), which is basically a version of Eclipse bundled with the tools/plugins necessary for setting up a PHP development environment. Besides offering everything Ultraedit did, it also offered nice features like easy ‘Todo’ lists, (just type ‘todo’ anywhere in a comment and it’s automatically indexed by Eclipse into a list), code completion for built-in PHP functions and your own as well as a multitude of other advanced features that IDEs have. Oh, and it’s also FOSS. (Free and Open Source Software)

However, perhaps the best part about Eclipse is its robust and well-supported plugin system. This allows Eclipse to pretty much assume any feature that someone is willing to write a plugin for. This is what really sold me on Eclipse, because this almost makes its abilities endless. Some of the plugins I use are Subclipse for SVN integration, Mylyn for Trac integration and JSEclipse for JavaScript editing. This is part of the reason why Eclipse is the basis for many other IDEs out there.

Some other nice features are the ability to link the IDE in with the Zend Debugger, thus allowing for proper debugging sessions with PHP.

Spoiled

However, I’ve been pampered somewhat and have found a few things to complain about, at least when it comes to Eclipse PDT. I use Eclipse JDT (Java) a work and its advanced refactoring abilities are a feature I find myself wanting in the PDT version. Have you ever found yourself wanting to rename a variable to something more descriptive but putting it off because you’re afraid you’ll mess something up by forgetting to change the name somewhere?

With some IDEs, you’re left having to just do a search-and-replace in order to accomplish what should be a trivial name refactor. Even if your editor supports regex searches, things can still be tricky - what if you’ve used the same name, but in a different context, and thus shouldn’t change the variable there? The point is, the process still has to be human-supervised and is tedious. With Eclipse JDT’s advanced refactoring, you can rename the variable once - and the IDE is smart enough to know where else to change it to keep the code consistent - very neat, and I was amazed when I first used it. Other refactoring abilities include extracting methods out of blocks of code in order to clean up lengthy methods. All of this makes your life 10 times easier and allows you focus on real programming rather than annoying tasks.

However, Eclipse PDT doesn’t support this for PHP code, yet. I hear that it may be supported in a later release, so I have my fingers crossed. Perhaps accomplishing these refactoring tasks is easier in Java because of its compiled nature or because the JDT project has received more attention. It’s definitely possible in PHP, as some IDEs, such as the Zend Studio (which is based on Eclipse) support this ability. Zend Studio, however, is a commercial solution and I haven’t tried it out yet.

Nothing’s perfect

Eclipse does have its downsides as compared to a traditional text editor. First of all, it’s a memory hog - though most IDEs are. I have regularly seen Eclipse eat up 300-400 MB of RAM if I’ve been using it for a long time. However, it should be noted that I have not had it crash once, so it’s been rock-solid as far as stability goes. Nonetheless, I recommend you to have at least 2 GB of memory if you really want to use it properly, since you’re likely to have other programs open. This is especially important if you’re running Windows Vista. RAM is quiet cheap nowadays, and you can easily pick up 2 GB for $50 or less and upgrading is a painless process, so there’s no reason not to.

Finishing up

Eclipse has changed my life. Okay, so perhaps I’m exaggerating a bit. But, I can say that development, at least for me, would be much harder without Eclipse. If you’re still using a text editor for development, I urge you to give Eclipse a try - just for 30 days, and see how you like it. I don’t guarantee results as good as mine, but you may be pleasantly surprised.