Eric DeLabarWeb 2.0 from a Web Purist and J2EE Developer

In my last post I told a half-truth by ending with “If you need me I’ll be uninstalling Eclipse.” Honestly, I only removed it from my laptop because I rarely do any real Java development directly on my laptop, and should I need a quick code editor I have TextMate which handles most of my coding needs pretty simply. However, the commotion that the statement caused is what I’m going to address in this post.

If all you have is a hammer, everything looks like a nail.
-Bernard Baruch

To continue with my tools theme I’m going to address what I’ll call “tool-blindness,” the mentality that the tools you have and know how to use are perfect for every situation. In other words, if the tools you have require you to hammer screws then by-god you’re going to hammer screws.

Recently there has been a grass-roots, developer movement at my employer to switch from Ant to Maven. I love Maven, it’s leaps and bounds better than the way we were using Ant. (Notice I didn’t say Ant in general, I’m only planning on starting one holy-war with this post!) My last four projects have used Maven, and it makes the build and deploy process significantly easier, especially when it comes to dependancy management. However, everyone’s favorite Java IDE does not play well with Maven because Maven’s standard directory layout is significantly different from Eclipse’s convention. People have attempted to alleviate this problem by using the M2 plug-in and following the instructions here, but the result still feels like you’re forcing Eclipse to do something it doesn’t want to. Add that to the fact that the version of Eclipse we’re using crashes at least once a day, and you should be able to see why I’m looking for alternatives.

In short, our metaphorical hardware (the build process) has changed from nails to screws and our hammer (Eclipse) is no longer the best tool for the job. However, we’re still using the hammer because it’s what everyone knows how to use and only a few of us are not tool-blind enough to look for something else. It also doesn’t help that the alternatives that play nicely with Maven, namely IntelliJ IDEA and Textmate-and-a-shell are not “free as in beer.”

As I mentioned in the comments of my last post, Eclipse has been feeling a little more like this tool than this one. So maybe it’s time to ask which tool you really want on your tool belt.

In an interesting turn of events, Alex Vazquez over at Wufoo/Particletree is going through the same process with a different perspective. Alex is moving, based in part by recommendation and in part by language choice, from Java on Eclipse to PHP on Textmate, and he seems to be liking it so far. Alex does, however, sum up Eclipse rather nicely, and coincidentally within my theme:

The right development environment can save a programmer countless hours and is like a hammer in the carpenter’s tool belt. Since my background was in Java, my preference was for large sledge hammers and my development environment of choice was the de facto Java IDE Eclipse. It has a number of amazing features like autocomplete, refactoring and hundreds of plugins for every task imaginable. It’s no secret Java requires mountains of code, but Eclipse was made to move mountains.
-Alex Vazquez

I think Alex really nails (pardon the pun) the fact that if you’re going to be doing Java Enterprise development you need an IDE that can handle it. You need something that generates the code and provides the re-factoring tools and autocompletion to make it possible to “move mountains.” However I’d like to pose a question to all Java developers who use Eclipse; how much of Eclipse do you really use? Besides re-factoring, code completion/generation, and cvs/svn/scm integration, is there anything else you couldn’t live without? Anything else that Textmate doesn’t do? (Besides run on Windows, we’ll save that tool for a different day.) Look at all of the stuff Eclipse does that you don’t use, is the added bulk really worth it? How much memory is your Eclipse process using right now? (Mine’s got ~254MB, 5x more than the next largest memory footprint, and my Eclipse process is basically idle.) Just my two cents, please form your own opinions, after all I’m just a kid who couldn’t possibly have any experience.

Let’s face it, cross-browser JavaScript and AJAX without a helper library or framework is pretty difficult. However, these libraries can be pretty hefty when it comes to page download size, especially if sent uncompressed and un-optimized. Most of the libraries have a statement in their docs that says something along the lines of “grow up and compress your JavaScript” but not all of us have sufficient access to their web host to actually be able to do that. Enter Google. Google’s AJAX Libraries API serves as a content distribution network for providing pre-compressed versions of the web’s favorite Web 2.0 JavaScript libraries:

• jQuery
• prototype
• script.aculo.us
• MooTools
• dojo

Access to these libraries is quite simple, in fact loading prototype can be accomplished with the following four lines of code:

<script src="http://www.google.com/jsapi"></script>
<script>
	google.load("prototype", "1.6.0.2");
</script>

Pretty simple, but let’s look at some metrics.

As you can see, the Google version is significantly faster and smaller on the initial load, subsequent loads a little less obvious, but still slightly faster. However, this test was not all that scientific, since I really only have the ability to do this with Firefox and Firebug, I only did it once, and my network speed can vary significantly from request to request. Despite all of that, testing this across a few other browser/OS combinations does reveal a pattern where the Google AJAX Library API pages do feel faster, even if only by a fraction of a second. I’ve provided my test pages, with Google and without-Google, for you to perform your own tests, and I’d love to hear what other people think and see their results.

The verdict, I like it, but I have a few caveats. First, as pointed out to me by the Unscrutable Designer, you’re relying on a third party site to host your scripts, in this case it means you need to trust Google to not be evil. Personally, I do, but that is a decision to be made on a case-by-case basis. Secondly, you have to trust the reliability of your content distribution network, can you risk your JavaScript functionality if Google’s server goes down? Thanks to progressive enhancement, having no library should be basically the same as no JavaScript, so my properly implemented site should still function, so this is personally not a show-stopper for me.

Now, one last thought. Keep in mind that this is not the most optimal solution since it still makes a request for each library you load and the libraries themselves are not optimized, but it does bring along with it an interesting benefit. The more sites that use this service the higher the chance of getting a local cache hit on one of these files, which of course means one less download.

By my definition of Web 2.0, one of the key requirements for any application is cross-browser compatibility. As a company, my employer defines this as IE 6+, Firefox 2+, and Safari 3 beta; all tested on Windows. It’s not ideal, but it covers a huge chunk of the market. This stack is pretty easy to test, but occasionally one of the browsers will throw a curve-ball and that’s where a typical the members of my team, or J2EE developers in general, get lost.

When somebody comes across some weird client-side error and they come looking for my help, I start with three questions:

1. Does it validate? (Is it a strict doctype?)
2. Is it in quirks mode?
3. Did you separate content from presentation from behavior?

I think one and two are pretty obvious, if you’re not following the standards the browser can (and will) do what it wants with your page. Follow the rules and your playing field becomes a lot more level. Number three is a design choice that I prefer for keeping things clean; if your layers are separated, you know what behavior is coming from where. What does this mean? It means style is always stored in an external StyleSheet, JavaScript is always stored in an external JS file, and your HTML markup has no inline event handlers, script blocks, or style attributes. Not only does this make things easier to find and debug it also encourages progressive enhancement and accessible design.

Now that you’ve made sure those three cases are taken care of, do you still have the problem? I’d say 50% of the time the problem is solved, for the rest, here’s what I do. (First things first, make sure your toolbox is in order.)

For debugging CSS, use Firebug’s Inspect tool to make sure the correct CSS rules are applying to your element, this will show you which rules are applying and more importantly, which one is winning in the case of a conflict. If the problem is not showing up in Firefox, I’m guessing it also works in Safari, so it has be an IE issue. Check your floats, check your widths, and make sure you’re not relying on anything IE doesn’t support, like min-height or max-height. If you’re still not sure what’s going on, checkout the Microsoft Developer Toolbar. To get it, go to Microsoft.com and search for “Developer Toolbar,” I’d post a link, but every time I try bookmarking the page it moves, so it’s probably just easier to search for it. The Developer Toolbar works similarly to Firebug, but is definitely lacking. If your problem is in Safari, get a copy of the Webkit Nightly and enable the Web Inspector. It’s definitely better than the IE Developer Toolbar, but still not Firebug. In a pinch, try out the WestCiv XRAY and MRI bookmarklets which are easy enough to install and uninstall on a workstation that is not your own.

If you’re debugging JavaScript, the Firebug console is definitely the way to go for tracing, and you can even make it work on other browsers with their handy JavaScript-based utility. For IE specific errors you can try your luck with the Microsoft Script Debugger (again, search for it), but I find it to be a little bloated. At the time of this writing Webkit offers its own debugger in the form of Drosera, but it’s Mac-only, so unless you’ve got one you’re out of luck there. Finally, you can try out Aptana Studio which offers JavaScript debugging in Firefox (also in IE if you’re willing to pay for it), but I haven’t had a chance to really give it a test drive and at initial glance it seems a little clunky when working with J2EE.

There’s a ton of tools out there for debugging client-side problems, and with a little practice you’ll be debugging like a pro in no time at all. But please, remember one thing, the best offense is a good defense, separate your layers, avoid CSS hacks, and do things the right way the first time.

Continuing our thread on tools, we’re now going to have a look at setting up a simple test server environment.

As I explained last time, I typically develop on a Windows and Linux, so I prefer a tool that works well on both platforms. Coming from a Java development background, there is one tool that meets this requirement, and more; and as you may or may not know, works with more than just Java. That tool is of course, the Eclipse Framework, a Java-based development platform.

Out of the box, Eclipse provides the hooks necessary to support helpful features such as syntax highlighting and code-completion; with the help of a variety of plug-ins you can very easily enable these features for Ruby, PHP, Perl, C, or pretty much whatever language you prefer to develop in. For this tutorial, we’re just going to get the basic HTML, CSS, and JavaScript editors installed and configured.

Start off by downloading the latest version of the Eclipse Framework, at the time of this writing, that was 3.2.2. To install it, simply unzip it to your hard drive; to make your life easier, drop it in the root of a drive (i.e. c:\). (Make sure you have a JDK/JRE installed, if you don’t, grab the latest from Sun.) Once installed, start it up by running eclipse.exe (just press OK at the Workspace Launcher prompt for now) and go directly to the Help > Software Updates > Find and Install... menu. Select the Search for new features to install radio button and press Next >. Check the box to search the Callisto Discovery Site and press Finished. On the next screen, expand the Callisto Discovery Site node, and then expand the Web and J2EE Development node. Check the box for the following nodes:

• Graphical Editors and Frameworks
  • Graphical Editing Framework
• Models and Model Development
  • Eclipse Modeling Framework (EMF) Runtime + End-User Tools
  • XML Schema Infoset Model (XSD) Runtime + End-User Tools
  • Java EMF Model
• Web and J2EE Development
  • Web Standard Tools (WST) Project

Read and accept the license agreements and press Next >. Press the Finish button, and let it do its thing. If you receive a Verification window, press the Install All button. When prompted to restart Eclipse, select cancel, and close Eclipse. Congratulations, Eclipse is installed and now we’re ready to install Apache HTTP Server.

You may be wondering why it’s necessary to install an HTTP server when you can open an HTML file directly from the file system in most browsers. The simple answer is because this is a development environment and the code you produce locally should run on the server without modification. With some site file system layouts, paths, such as those to images or stylesheets, may be different on the server compared to your local machine, especially if using URL rewriting techniques. As a benefit for more advanced users, you can also configure apache to run PHP, Perl, or the server side language of your choice. Now, back to our tutorial.

First, download the latest version of Apache. (We’re assuming you’re on Windows here, if you’re using an alternative OS, this exercise is left to you…) At the time of this writing, the best version is 2.2.4 and Win32 Binary (MSI Installer) is probably the easiest to deal with. After it’s downloaded, run the installer. The install process is pretty standard; for server information you probably want to use localhost for your Network Domain, unless your desktop has a fully qualified domain name, and your machine name for Server Name, on the Server Information screen. From that point, the Typical install will probably do just fine. When it’s finished, Apache will be conveniently started, and you’ll be ready to move on. To test your result, load up a browser and check out: http://localhost/; if it worked, your browser will display an oh-so-descriptive page stating “It works!” Now that you have a working web server, let’s create a convenient shortcut to open Eclipse in the htdocs directory of Apache.

Browse to your Eclipse install directory (probably something like: c:\eclipse) and right-click on eclipse.exe. Choose Create Shortcut from the context menu. Rename it to “Apache HTTP Server Workspace” and drag it someplace convenient (like your desktop.) Right click on the Shortcut and change the Target field to look something like this: C:\eclipse\eclipse.exe -data "C:\Program Files\Apache Software Foundation\Apache2.2\htdocs", where the italic text is replaced by your Eclipse install directory and Apache install directory respectively. Press OK to save your changes. Now start up Eclipse by running your new shortcut, and you should not be prompted to choose a Workspace. Congratulations, Eclipse is now configured, now let’s get a project setup and give a quick tour of the Eclipse functionality.

To clear the Welcome screen, press the “X” on the Welcome tab at the top of the screen. By default, you’ll be setup in the Jave Perspective, this won’t be of much help unless you’re a Java developer, so choose the Window > Open Perspective > Other... menu. Choose the Resource perspective from the list and press OK. The screen layout will change and should now show the Navigator, Outline, and Tasks views (counter-clockwise from upper left.) Right click on the Navigator view, and select New > Project... from the context menu. From the Wizards tree, expand Web, and select Static Web Project and press the Next > button. In the project name box, type an appropriate name for your current project, in this example we’ll use demo, and press Finish. A new folder will appear in the Navigator view and inside of it will be a variety of folders and files, don’t worry too much about any of them, but you can get rid of the “WebContent” directory. This directory is now a subdirectory off of your localhost root directory (i.e. http://localhost/demo/.) Just to verify, create a new HTML document named index.html (Hint: try the New context menu off of the “demo” folder in the Navigator view view again) and paste the HTML from my second article into that file. Next, load it up and the server and inspect your handy work! (Try: http://localhost/demo/, it’s an oh-so-exciting blank page with a title. Hooray!)

That’s it! In my next article, I’ll take a look at setting up a simple directory structure and making more than just an empty web page.

After my last post, we have a nice, clean starting point for our website. Which is great, but in order to take it to the next level, we should probably get a nice development environment up and running.

First, we’ll start with the client side. At my employer, we develop entirely on Windows. In my spare time, I have a Gentoo (soon to be Ubuntu) Linux box at home. Because of these factors, my tools of choice tend to be cross platform. As far as browsers go, I develop strictly in Firefox due to its ease of debugging with tons of useful plug-ins (Firebug, Web Developer Toolbar, DOM Inspector) and cross-platform availability. I of course have IE at work; where I’ve switched totally to IE 7, and I run the free IE 6 VM provided by Microsoft for testing in IE 6. I also have access to a Mac running Safari, a variety of Windows Mobile smart phones, and a few versions of Opera, including the Wii Beta version. Do I cover all of my bases? Probably not, but I’m at least over 95% of the user base.

What I really want to talk about are the Firefox plug-ins I mentioned earlier; if these tools are used correctly, a properly coded site that works in Firefox works just about everywhere else as well. To start off, make sure that when you first install Firefox, the DOM Inspector is installed. To do this, on the “Setup Type” screen, choose Custom, and on the “Choose Optional Components” screen, make sure the “DOM Inspector” check box is checked:

Choose Optional Components…

Install DOM Inspector…

Ok, now we’re ready for plugins! My current must haves are as follows:

• Web Developer Toolbar — Tons of useful little tools that no web developer should be without. Just install it and play with it. Trust me.
• Firebug — Amazing debugging and profiling tools, plus the Inspect button which lets you see which CSS rules apply to any element in your doc, and a fancy colored overlay showing element, margin and padding.
• MeasureIt — Great tool for pixel-perfect measuring!
• ColorZilla — Quickly grab colors without viewing page source.
• HTML Validator — W3C Validation on the fly, and in your view-source window.
• View Source Chart — Great for dealing with tag-soup or server generated code that’s not nicely tabbed or spaced.
• Operator — A must have for developing with (and using) Microformats.
• Tails — Another must have for developing with (and using) Microformats.

If you’re still stuck in IE land, there’s still hope, Microsoft has released a half-decent copycat Web Developer Toolbar, and there’s hope for their (Java)Script debugger. If you have a Genuine Advantage copy of Windows it won’t hurt to try them out.

That’s it! Get those installed, play with them, and tune in next time for part 2, where we setup Eclipse and Apache as a test web server on Windows.