Eric DeLabarWeb 2.0 from a Web Purist and J2EE Developer

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.

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.

Every time I read a new post on Andy Rutledge’s blog Design View I feel the need to comment. Andy has made the decision to not allow comments on his site so instead I’ll comment here. The latest article on Design View is about Pre-Bid Discussions, in it Andy explains how his company turned down a $50/60k project because they could not see the project succeeding according to their terms. For the fact that he turns down projects for integrity reasons, I applaud him! As far as the article, his analysis and process are insightful and I’d love to be able to use them, but for now I’d just like to expand on them.

I would like to add two questions to Andy’s list of five, and I’ll continue with his format of stating the questions and then coming back to them, so numbered for reference:

6. Am I or is my team able to develop with the technology stack?
7. Would I invest my own money in this project?

As Andy laid out in his article, these are questions that should be asked during the pre-bid discussion. There is nothing worse than blindly responding to an RFQ and winning the job only to find out that the client does not want somebody to help them implement a solution, they want somebody to blindly do their bidding without question. But I digress, ladies and gentlemen, the questions.

6. Am I or is my team able to develop with the desired technology stack?

I have seen this question extract chunks of flesh more times than I can count. Most programmers will tell you that programming is programming and the difference between languages is small enough that given a few weeks a real programmer can learn any language. I’ve said it myself, and I thoroughly believe it. However, I’d much rather have the end results from a programmer who’s an expert in a language or framework than a programmer that only learned it a few weeks ago. Think about these questions when discussing the technology stack:

• What version of X Technology are you using?
• Do you have internal coding standards to which we’ll need to adhere?
• Has something been developed and deployed to this platform before?
• Will your team be interacting with our code directly?
• Will we be interacting with your team’s code directly?

These questions are more technical than Andy’s, but they’re vital for determining the overall scope of a project which is necessary for placing a bid. Software versions can make huge differences. I whole-heartedly agree with coding standards, but if the standards say no open source or external code you may be up a creek if you rely heavily on Jakarta Commons. Is this stack even possible? Sure, the bigwig sales guy said a heterogeneous solution of Company A’s ORM and Company B’s DB and Company C’s development environment would work, but have you seen it and can you get support for it when it fails? Finally, if you’re co-programming this project with the company, will they be changing your code? Will you be changing theirs? What does their programming team think of bringing in outsiders? How long will it take them to make a code change that you need and who’s responsible for making up that time? Think about who’s making the rules, who’s following them, and who’s enforcing them.

7. Would I invest my own money in this project?

Nothing will kill the morale of your team like working on a project they think is doomed to fail. I really hate to tell you to judge somebody else’s ideas, and 9-chances-out-of-10 I’d take the client that has a few million in VC-backing, but sometimes it just doesn’t make sense. This especially comes true when the sales pitch for the idea starts with: “It’s like some-other-app but…” Let’s all face it, twitter is a huge surprise and everybody loves it, but that does not mean “It’s like twitter but instead of other users subscribing to your tweets you get to publish your tweets to the people you want to see them,” will ever make billions. If they’re not the first, the free, or the best, let somebody else implement the failure. I guess this is a bit of a sore spot for me personally, but ignoring that, here’s some questions to ask:

• Have you done focus groups or would you like us to help you do them to support the feasibility of this project?
• How do you intend to monetize this idea?
• How do you intend to build your user base or generate buzz about this idea?
• What happens if the users adapt your system for some other use beyond or in contrast to your initial plans?
• What is your reason for starting this project?
• What is your goal, how do you define success for this project?

No audience, no plans to obtain an audience, and no way to make money are surefire signs for failure. If you still like the idea and you think you can help, at least make sure you get paid up front. The next few really don’t have right or wrong answers, but the foresight to know that the agility to adapt might be necessary is a good thing to have. As for reasons, you might want to get out your moral compass, if it’s for world domination, drug trafficking, destroying the ozone layer or patent trolling you may not want your name attached to it as the implementor. Finally, it’s good to know the client has a plan, how can you define the success of this project if they can’t.

My Main Point

Like Andy, I’m definitely saying that if you establish your own rules up front it will make it easier to say no to a job no matter how big or easy is might seem. Unlike Andy I will say that I understand the necessity to bend these rules on occasion to at least keep your team busy, if not productive.

But let me stress the “on occasion” part. It is not good to be the bargain basement whore of web application design. Your reputation can mean the difference between finding jobs and having them find you; or playing the part of the expert-consultant or errand-boy slave. Your portfolio, client-list and case studies can speak worlds about your company, but not if every client that’s ever worked with you has gone out of business or insists on not being on the list. Even a big-name client means nothing if they’re using some propriety or ill-conceived tech-stack your team would rather quit their job than use.

Think about it. Make your choice. Reread the title.

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.

Day four at JavaOne was a bit of a blur due to it’s smaller population and shorter duration. Add that to the fact that I caught a red-eye back home and didn’t sleep all day on Saturday, and Friday and Saturday became one large day. But I digress.

Regretfully I left my notes at the office today, so check back tomorrow for the details on the sessions that belong in this paragraph. But until then…

The best part of Friday was the General Session demo of the Livescribe Pulse smartpen. The Pulse is a regular pen with an IR camera attached that scans a special kind of paper while you write on it. The pen features accelerometers and what I would assume is a pressure sensor that allows it to tell when, how, and what you are writing. It also records all sounds that are happening while you are writing, and can temporally associate the sounds to the written notes on the paper. This can all then be transfered off of the Pulse onto a (Windows only for now) computer and even published to the web, complete with sound and animated writing. The best thing about the Pulse is that it’s based on the Java ME platform and exposes a (apparently complete) development API, meaning pen-based applications can be designed that make use of all of the pens features. I have not yet had a chance to experiment with the API, but it’s on my schedule for tomorrow, so more details are to follow. Until then, check out these YouTube Videos for some more details.

For anyone interested in developing (or discussing the development of) Pulse applications, I started a Ning-based social network. If you were lucky enough to acquire a Pulse at JavaOne, please join!

Day two’s keynote was from Intel, basically the same as AMD’s evening general session yesterday. Blah, blah, blah, we improved JVM performance, blah, blah, blah.

With that out of the way, it was off to Groovy and Grails: Changing the Landscape of Java Platform, Enterprise Edition Patterns, which was unfortunately a bust. I think I’m grails’d out. The only thing new here was a couple new metaprogramming methods that I probably would have found by myself. Not that it was a bad session, it was just the same as the other Groovy sessions so far.

Next came Mylyn: Code at the Speed of Thought. Very cool. I can see Mylyn being very useful, especially when dealing with junior developers. Mik Kersten, the presenter and the Mylyn creator, also noted that there was a “statisticly significant increase in the productivity of a 100-developer test group.” Sounds promising, but I’ll need to play with it to see if it will fit into my employer’s methodology.

There were other sessions, but the only other one worth mentioning was Developing Semantic Web Applications on the Java Platform, which was a panel moderated by Henry Story, Sun’s Semantic Web Evangelist (I want an evangelist job title!) From this session, I was introduced to Twine, Tabulator, GRDDL, and Mulgara. Definitely worth a little more investigation!

Tonight was JavaOne after dark, the closing party held on Thursday night so that everyone can catch a red-eye home tomorrow night. This year’s bash featured Smash Mouth, and turned out to be pretty entertaining when they played a few Zepplin songs before closing the show. (An amused on-looker said they ran out of their own songs so they started playing something people would know!) I was able to grab some video with my camera, which I’ll post to YouTube when I get home, but sadly there was no encore and we were back in the hotel by 9pm.

The general session this morning was not quite the same as yesterday morning’s, which I suppose is understandable, but it was still pretty informative. Today Oracle showed off its developer tools, which are interesting, but being mainly JSF, not very appealing for my own use.

My favorite session of the day had to be Groovy, the Red Pill: Metaprogramming — How to Blow the Mind of Developers on the Java Platform presented by Scott Davis. This session was incredible. Scott speaks like a televangelist and by the end of the presentation seemed to have half the audience ready to stand, shout AMEN, and follow him as a new religious leader. I now have absolutely no doubt in my mind that Groovy is an amazing and powerful language and that I’m going to try my hardest to make it part of some project I’m doing in the near future.

My second favorite presentation was definately Creating a Compelling User Experience presented by Ben Galbraith. It wasn’t anything groundbreaking or new for me, but it was a very well-done presentation on design for the typical Java engineer. Ben made a variety of good points, including my personal favorite, pay attention to users goals but don’t let them design software.

Third runner-up for favorite goes to How to Implement Your Own OpenSocial Container on the Java Platform by Chris Schalk and Paul Lindner. This session basically covered Apache Shindig, which I did not even know existed. Also mentioned in the presentation were Guice and Enunciate, which I will definitely be investigating further.

Not much shwag today, and I didn’t win anything from any of the drawings (despite wearing my Swing Application Platform shirt), but overall a good day. Although if I can request anything from the JavaOne gods, how about a little variety for lunch, or at least a different kind of pasta salad with the sandwiches!

In case any of you missed my tweet, I learned so much today that it actually took me a good twenty minutes to remember what my first session was about!

I eventually remembered, it was The Duke and the Elephant: PHP Meets Java. Interesting concept, but doesn’t seem ready for prime-time quite yet because it does not support JIT compiling the PHP to bytecode like the other scripting languages like Groovy and JRuby do. If you’re interested, the project is WebSphere sMash and it is being developed by IBM and falls under the umbrella of the ProjectZero incubator. It is being developed transparently, the source code is available, but it is not open source.

Session number two was by far the best of the day, JAX-RS: The Java API for RESTful Web Services. This session covered the basics of REST and then went through an incredible live-coded example using the JSR-311 reference implementation Jersey. I love the simplicity of the annotations and the fact that Jersey can run as a Java SE app without a web container opens the door for some interesting implementations.

The next two sessions really weren’t that interesting, but after dinner I went back to the Moscone Center for Jersey - RESTful WebServices Made Easy. This session was not as technical as the JAX-RS session, but still provided some neat demos (including an example using a SunSpot), and offered some insight into the Jersey project. Because I enjoyed the REST sessions so much I’ll be checking out the blog’s of the presenters: Marc Hadley, Paul Sandoz, and Jakub Podlesak.

So far, other than the food, I’m very impressed with JavaOne, and I might even go as far as saying it is better than TheServerSide Symposium was last year. Although the Cult-of-Java is almost as extreme as the Cult-of-Apple, which I do find pretty odd. The keynote was entertaining and interesting, but not that interesting!

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.

If you’re here because of Josh Porter’s posts on social network and social niche sites on his blog Bokardo, you might find these posts interesting:

• Following The Conversation Elsewhere
• More On Identity
• Online Identity and the Social Graph
• Identity and OpenId

If you like what you’re reading, please subscribe! I post every weekday on “Web 2.0” topics like JavaScript, CSS, web semantics, and of course the social web.

(Please excuse the looks, I’m not quite done with the theme for this site yet, but it looks much better than a week ago!)