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.

I have read quite a few posts recently on the lack of quality programmers, web or otherwise, available in the current market. I’ve even written a post myself on some of the “differences” in the technology stack between now and when I started programming professionally just four years ago. Some people are saying we need to encourage children to become programmers, others are questioning the languages that are taught in schools, still others are criticizing the things that are not taught (or encouraged) during secondary education. I’m going to question how things are taught.

I spent my first year of college at RIT, not to downplay my last three years at Muhlenberg, but everything I really needed to learn I learned in three quarters at RIT. Computer Science 101-103 had labs in a Sun Unix lab. We wrote Java code using Emacs from a shell. We compiled it from that shell. We checked it into RCS from that shell. We ran diffs from that shell. We submitted our completed assignments from that shell. We loved that shell, whether we wanted to or not.

We did not have an IDE, not in today’s sense anyway; there was no code complete, re-factoring tools, or visual SCM merging tools. In the process we learned Unix, we learned how to grep, how to use sed and awk, telnet, ssh, and command line ftp. We learned how the internet worked by first learning how a network worked. We learned to write code, use a computer, and use the internet with the functional equivalent of hand tools. In the process we learned and understood how and why it all fit together.

As a matter of illustration, I’m reminded of the Home Improvement television show that was on when I was a kid. In it, Tim Allen plays Tim Taylor, the host of a cable TV tool show called Tool Time. He has an assistant, Al Borland, played by Richard Karn. On the show, Tim’s motto is “more power,” which usually leads him to the biggest Binford Tools power tools, disastrous projects, and eventually the emergency room. Al, on the other hand, is more of a renaissance man, appreciating the beauty, elegance, and simplicity of hand tools and the wood they’re used on. Although I don’t think it was ever stated, Al never ended up in the emergency room. Which character would you hire to work on your house?

But I digress, we’re seeing more and more computer science grads who have worked only on Windows. They’ve used Eclipse and Visual Studio. They know how to use the very basic IDE functionality with the mouse and they live and die by ctrl+c and ctrl+v. They were given power tools in the very beginning of their careers and now quite a few of them have figuratively managed to cut their fingers off. They’re crippled programmers because the “more power,” here’s-a-monsterous-power-tool-that-does-everything-you’ll-ever-need-really-fast attitude has physically removed their ability to operate the simple tools that solve their problems in an elegant manner. They’re afraid of the shell because they don’t know how to use it, but they’re not afraid of the IDE because it has a big, shiny button that promises to make their life easier if they press it. Power tools in the real world have warnings about loss of life and limb if operated incorrectly. Sadly, power tools in the digital world do not.

So, I propose my solution. Bring the hand tools back into the classroom. Eliminate IDE’s from the educational system. Teach students to use the shell, and with it the tools of our hacker forefathers. Let them nick their fingers with a hand saw instead of cutting them off with a circular saw. Encourage them to use open source. Encourage them to contribute to open source. The web in general runs on it, they should know how it gets made, and know how to give back to the community that has made a large part of their future pay possible. Teach them Emacs or Vi. Give them cvs, svn, or git, and teach them to read a diff. Make them create a website and share what they’re learning, or at least participate in the forums of some pet open source project. Do them a favor and scare the ones who aren’t meant to be doing this out of the profession. If they don’t have the passion to persevere they need to find something else to do. Ladies and gentlemen of academia, I ask you for one thing. Stop manufacturing cookie-cutter, power-tool graduates and start nurturing artesian, master programmers.

Thank you. If you need me I’ll be uninstalling Eclipse.

As I’ve covered before, ill-used JavaScript can lead to some serious performance problems, most of which are caused by simply not thinking about what the code is really doing. Recently I came across a site that provided digital photo printing, This site had a nice interface that allowed my to upload close to three hundred photos. On the resulting page, each photo was displayed with all of the available sizes as input boxes, which looked something like this. I liked the interface, but came across a very serious problem. The event handlers that updated the totals box ran on the keyup event and recalculated the total of the entire form! This worked fine with ten or twenty photos, but the 300 that I provided brought my browser to a screeching halt.

I’ve taken the liberty of creating a very simplistic mock-up of the form and a simplified version of the JavaScript, which is available in my examples section. The demo uses Firebug and Firebug Lite for logging just like I did in my dollar function article, and the benchmark class from that article as well. The site’s JavaScript was a bit more complex and actually did an AJAX lookup of the price on each keyup, but I’m more concerned with the JavaScript performance here, so I simplified the code to something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

var PhotoSelector = Class.create();
PhotoSelector.prototype = {
	initialize: function( name ) {
		var init = new Benchmark();
		init.start();
		console.debug( "Beginning Initialization!" );
 
		$A(document.getElementsByTagName("input")).each( 
			function( inp ) {
				inp.value = 0;
				if( Element.hasClassName(inp,"qtyInput") ) {
					inp.onkeyup = this.recalculate.bindAsEventListener( this );
				}
			}, this
		);
 
		init.end();
		console.debug( "Initialization Complete in " + init.inMillis() + " milli(s)." );
	},
 
	recalculate: function(e) {
		var calc = new Benchmark();
		calc.start();
 
		$("fourby").value = 0;
		$("fiveby").value = 0;
		$("eightby").value = 0;
		$("wallet").value = 0;
 
		var inputs = $("pictures").getElementsByTagName("input");
		for( var i = 0; i < inputs.length; i++ ) {
			var totalId = inputs[i].id.match(/([a-z]+)[0-9]+/)[1];
			var total = $(totalId);
			total.value = parseInt(total.value) + parseInt($(inputs[i]).value);
		}
 
		calc.end();
		console.debug( "Recalculation Complete in " + calc.inMillis() + " milli(s)." );
	}
}
var ps;
Event.observe(window,"load",function(e){ps = new PhotoSelector()});

Basically, on window load, this code grabs every input element, sets its value to zero, and binds an event handler to it. The event handler runs on key up and loops through every input box in the “pictures” list, and updates the totals inputs at the top of the page. As I said above, this code works fine with 20 pictures, but it starts getting slow around 300, and becomes almost unusable at 1000. Care to try 10,000? (Be careful, it crashes my browser!) To test it, simply enter values in the photo inputs and watch the totals boxes increment.

The main problem with this code comes from the recalculate function. Problem number one is my personal pet peeve, the dollar sign function is called at least six times! Well, I guess six times wouldn’t be terrible for the entire page, but it’s called at least six times on every key up event! Problem number two, the biggest problem, is the fact that this code re-crawls what amounts to the entire DOM every time the event fires. Obviously the larger the DOM, the more time this is going to take.

So, how do we fix it? Well, here’s how I fixed it, I’ll explain the details below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

var PhotoSelector = Class.create();
PhotoSelector.prototype = {
	initialize: function( name ) {
		var init = new Benchmark();
		init.start();
		console.debug( "Beginning Initialization!" );
 
		this.old = 0;
		var totals = {
			fourby: $("fourby"),
			fiveby: $("fiveby"),
			eightby: $("eightby"),
			wallet: $("wallet")
		};
		totals.fourby.value = 0;
		totals.fiveby.value = 0;
		totals.eightby.value = 0;
		totals.wallet.value = 0;
 
		$$(".qtyInput").each( 
			function( inp, index ) {
				inp.onfocus = this.enter( inp, this ).bindAsEventListener( this );
				inp.onblur = this.recalculate( inp, totals, this ).bindAsEventListener( this );
			}, this
		);
 
		init.end();
		console.debug( "Initialization Complete in " + init.inMillis() + " milli(s)." );
	},
 
	enter: function( inp, me ) {
		return function(e) {
			me.old = parseInt(inp.value);
		}
	},
 
	recalculate: function( inp, totals, me ) {
		var type = inp.id.match(/([a-z]+)[0-9]+/)[1];
		var total = totals[type];
		inp.value = 0;
		return function(e) {
			var calc = new Benchmark();
			calc.start();
 
			var newVal = parseInt(inp.value);
			if( me.old > newVal ) {
				newVal = ( me.old - newVal ) * -1;
			}
			total.value = parseInt(total.value) + newVal;
 
			calc.end();
			console.debug( "Recalculation Complete in " + calc.inMillis() + " milli(s)." );
		}
	}
}
var ps;
Event.observe(window,"load",function(e){ps = new PhotoSelector()});

To solve problem number one from above I created a simple object for storing references to all of the total input boxes (lines 9-14), now we have a simple associative array lookup whenever we need to update a total. Problem number two is mainly solved by recording the original value of the input on focus (line 22, 31-35), and then comparing them on blur (line 23, 37-54). Because we’re doing this on blur, we can update only the necessary total input (lines 45-49) instead of recalculating the entire form. I made one final tweak, mainly to make solving problem number one easier, and that is the recalculate function now returns a specific event handler for the given input so that the event handler itself does not need to call the dollar function.

So, comparing these in my regular, not-very-scientific fashion, I came up with the following results. I chose to measure the startup time, which will increase with the size of the page, as well as the event handler time. I also measured these times across a pretty decent amount of pictures, and across a few browsers.

Safari (OS X)

Internet Explorer 7 (Windows Vista)

28 seconds!? Why!?

Firefox 2 (Windows Vista)

The results pretty obviously speak for themselves, but there is one caveat, be sure to notice the initial load time. Since the event handlers still need to be assigned to each input on the page the more inputs there are the longer the page load takes, and the load time is even slightly slower on the optimized page. Be sure to consider this time, possibly by capping the number of inputs displayed, since the code itself is very processor intensive and appears to actually hang the entire computer while processing. Obviously, these fixes become more important as the number of inputs grows, but any speed increase when the user is directly interacting with the page is a good one!

This topic has been bouncing around my head for a while, but an article I stumbled across on Digg brought it to the front. In this article the author states:

My favorite variation of this is the concept that your pants make you a better programmer. If I wear khaki pants to work it makes me a better worker then if I wear denim pants. Though I don’t have a client-facing position, it still makes me more effective if my pants come from Banana Republic.

-Sara Chipps

I work for an east coast, software services company that has yet to realize that breaking the spirits, creativity and individuality of their programmers is not a good thing. Conceptually, I love my job, or at least what I do, however it has nothing to do with where I work. I have no problem with rules, in fact I realize in most cases they are a necessity. However when the rules exist because it’s how it’s always been done, I start to get a little annoyed.

We have a dress code, it’s business casual. On Monday we can wear jeans, as long as they fit properly and are not torn or frayed. Casual day is on Monday because that’s the day the country club is closed, so the bosses can wear jeans and not have to change before they go to lunch. In the “summer” (a vague term not actually defined anywhere) we can wear khaki shorts. Until this year, shorts were only allowed on Tuesdays and Thursdays, had to be crisply ironed, and cargo pants were unacceptable (good luck finding those any place your grandparents don’t shop). During the “summer,” casual Mondays no longer apply, you’re allowed to wear khaki shorts so why would you want to wear jeans in an office that averages a temperature of about 64 degrees fahrenheit? Although, I guess it is nice that I will be comfortable walking twenty feet from the door to my car after work. On occasion a big new customer will be brought into the office and we’ll be asked to dress extra-nice for the resulting dog-and-pony show, further proving that the standard day-to-day business casual serves no purpose.

So, an entire whiney paragraph about our dress code, boo-hoo, poor programmer how will you ever survive?

This is not a question about surviving, it’s a matter of thriving. I’m as much an artist as I am a scientist or a mathematician, and scientifically speaking I’m a better, more creative artist when I’m comfortable than I am when I’m not. A collar does not make my code faster. Brown shoes do not make me a better designer. Khaki pants certainly don’t make me a better programmer. I’m not going to say that my code will be directly improved by wearing a t-shirt, sneakers, and jeans, but wearing them will improve my morale and enhance my creativity, and that has a chance of improving my code, or at least my desire to be here.

But I digress. This is not about a dress code, it’s about a mentality, both management’s and employee’s. They call it herding cats for a reason. Programmers are a different breed, and if you think you can prove otherwise you’re not dealing with the right kind of programmers. Look at the companies out there making a fortune in this sector. The ones that attract the best and the brightest developers. Is there a dress code at Google? Facebook? Apple? I don’t think so. These companies provide creative benefits like free lunch, dinner, snacks and sodas, interesting and non-conformist workspaces and places, car washes, dry cleaning, and bike repair to name a few. They think outside the cube. If you keep your talent happy there is a higher chance of keeping your talent, unless of course you enjoy nurturing rock stars until they’re good enough to leave you in the dust for a greener pasture.

I’ve been at my current employer for over four years. We do Java-based web application development. Four short years ago, this industry was a different world. Web 2.0 didn’t exist. Ajax was a cleaning product. A website that only worked in IE 6 was good enough for most clients. Tables were a viable solution of any HTML markup problem, and the semantic web had something to do with a children’s book about a pig. Four short years ago we were the Jacks of all web-application development and we had it mastered.

When I started here our tech stack was pretty small, we wrote J2EE applications and we deployed them to WebSphere Application Server (WAS). We wrote these applications using WebSphere Studio Application Developer (WSAD) using a home-brew framework of GoF patterns and JSP scriptlets. JSTL was just entering the scene and JavaScript was a dreaded task used only for fly-overs and submitting forms with more than one possible action. CSS was used for changing font sizes and a table-based layout was not just the norm, it was expected. SEO was using alt attributes on your image element. You could learn this stack in a few weeks while studying for your SCJP cert, be a useful resource on small tasks in a month, and be the lead architect of major subsystems in six. A true master in six short months.

For this career, at least here, a B.S. in computer science was required (emphasis on the BS), but that just got you through the door. Everything else you needed to know you learned in the first six months to a year. You learned how to read code. You learned how to search Google for solutions. You learned how to search the CVS repository for the way we solved it last time for some other client. More importantly you learned how to learn.

Now, here we are four years later, the Web has reached its next version, and discussion has started on the one after that. Our tech stack is now outlined on a four-page spreadsheet. Home-brew pattern implementations are now a thing of the past. We have Spring for IoC and MVC on the middle tier. Hibernate, JPA, iBatis and JDBC for DB persistence, plus web services and SOA, and even a little JCR. The view is now at least JSP/JSTL, sometimes Velocity, sometimes even JSF, and they just generate the markup. CSS is a part of life, tables are for data only, and we sometimes write more JavaScript for a project than we do Java. We deploy to WAS, WAS CE (geronimo), Tomcat, JBoss, WebLogic, and insanely configured combinations of them all. We develop in Eclipse, Rational Application Developer, IntelliJ IDEA, and we might even try NetBeans. We test on IE 6 and 7, Firefox and Safari, we test with and without JavaScript. We advise clients on search engine marketing, social networking, tag clouds, URL rewriting, XML sitemaps, feeds, microformats, link building, link bait, and duplicate content, not to mention semantic HTML with a clean structure and accessible markup. We do automated unit and integration tests, performance testing, code coverage reports, and are discussing a continuous build server.

Our training program remains basically the same. We simply throw more words at the newbies and hope they’ll take the initiative to at least look them up. Now they can write unit test and perform AJAX calls, but they don’t know how to methodically test a simple web form submission. They avoid SQL, especially on a terminal. They regularly check broken code into CVS or foobar a code-sync to the point that work has to stop for hours to clean it up. They have even mastered the ability to create unit tests that provide 100% code coverage but don’t actually test that anything works. They know enough about the technology stack to be literally dangerous.

How do you train people for Web 2.0? I could write and teach a year-long course that covers all of the technologies, but I’m beginning to doubt it would matter, and they’d never take me off of the projects that actually make money to teach it for that long. I’m sad to say, but I don’t think the problem is the training, I think it’s the mentality. You went through college, you know how to write code. If you know how to learn, the size of the tech-stack shouldn’t matter. The tech-stack makes you life easier if you learn how to use it. You don’t learn Web 2.0 from a book or a class, you learn it by living it. You want to design web apps, where’s your website? At least tell me about your idea for the next killer web-app. You want to write code? Show me. What open-source project(s) do you contribute to? Write an awesomely bad and ironic implementation of the fizz-buzz problem and explain to me with a smile on your face why you did it. Tell me why Joel is your new religious leader, how Zeldman and Meyer are your preferred deities. Try and convince me that the CSS Zen Garden is bad, or voice your opinion on the IE 8 version-targetting debate. Show me you have passion. I’m tired of code-monkeys, show me you’re a rock star.

*Smashes keyboard, steps down off the soap box, walks off stage.*

But seriously, is it that much different? We still have the same GoF patterns, we just use somebody else’s named, branded, and marketed implementation. Web 2.0 is just doing the web the right way, it’s using now-established best practices that were still being invented four years ago. We can still be the masters of all things java web-app development, we just need to continue reading and learning. So how do we make the next generation of masters? To that I say you can’t. You need to find them. You need to find the people that have the pre-bubble mentality, the people with the passion and drive to love this stuff. Those people can be groomed to masters simply by showing them where to look. As for the others? Teach them how to use source control. Teach them how to test a web-form. Teach them just enough html to make something look the way the client wants it to in IE. After that, let them work on the .Net and JSF drag-and-drop component-based development. Let them build boring intranet applications that can run on IE 6 until the ancient machines they were designed for finally die. Let them stagnate in the Web 1.0 mentality, and when they’re obsolete, get them out of the way.

Groovy, like Ruby, is one of those DRY, elegant, and fun programming languages. In fact, one of the Groovy mantras is “the things you do the most often, Groovy makes the easiest.” That’s a pretty powerful statement, but with all things powerful, with great power comes great responsibility.

Groovy does some things that are inconsistent, for instance, consider running the following block of Groovy code:

1
2
3
4
5

def list = [1,2,3,4]
println list.class
 
dev map = [key1:"value1",key2:"value2"]
println map.class

Line 2 returns the class name of the list variable, in this case java.util.ArrayList; line 5 throws an error. This inconsistency is because Groovy allows the fields of a map to be accessed like a property, which means map.class is equivalent to map["class"] which refers to a key class in our map which does not exist. Because Groovy is interpreted and not compiled there’s no compiler to catch this error and it is possible that without an adequate amount of testing or review a piece of code like this could make it out as a bug. This point was brought up as a problem with Groovy to Jeff Brown, the instructor of the “Rapid Web Development with Groovy & Grails” Java University session at JavaOne. Jeff agreed that it was an issue, but basically just ignored it and moved on. I argue that it’s not a problem with the language it’s a problem with the developer.

Groovy’s documentation contains a list of things you can do with Groovy but probably shouldn’t, on said list, this problem is identified as number one. Groovy provides the ability to write unit tests, which if done correctly should catch this bug. But more importantly, a programmer should know the language he’s programming with, or his code should be reviewed by somebody who does. If your methodology allows for a bug like this to be released into the wild, you have bigger problems.

Groovy is a programming language for people who know how to program. People who realize the simplistic beauty of the syntax and the elegance it provides for solving problems in a DRY manner. Groovy is not for beginners, beginners need time to learn how to code before they should be allowed to take shortcuts. More importantly, beginners rely too heavily on tools, tools that more often than not act more as a crutch than an asset, and tools that cannot catch problems like the one above.

My solution? Grow up and code. When you’ve written enough code to realize that the best IDE is Vim, Emacs, or TextMate, and a terminal, you’re ready for Groovy and Grails. When the necessity of unit testing finally clicks in your head, you’re ready for Groovy and Grails. When you finally understand that code is poetry, you’re ready for Groovy and Grails. Until that point, keep writing code or find a new career. I can only hope that maybe one day you’ll understand, but if you never do, keep your opinions in your own space and don’t pollute our elegance with your misunderstanding. Just because you can’t write beautiful code doesn’t mean the rest of the world can’t.