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.

One day a small business owner, known to dabble in the do-it-yourself arts, was reading the visitor statistics from the website that his nephew had made him. Disappointed by the long page loads, low traffic, and cross-browser inconsistencies, the small business owner went to his kitchen for a glass of water. He turned on the faucet and nothing happened. A minute later, water started pouring out from under the sink. Quickly, he turned off the water and rushed back to his computer and looked up the name of a local plumber, he called, and had a plumber dispatched immediately. By chance, he also saw an advertisement for a local “low-cost, satisfaction guaranteed, web developer” and called him as well.

Twenty minutes later, they both arrived. Apologizing for the timing and offering a cup of coffee, the small business owner asked if the web developer wouldn’t mind waiting while he got the plumber started. The web developer, figuring he’d only had six cups of coffee today, decided a little waiting was not a problem.

The small business owner took the plumber to the water shut-off valve, and the plumber quickly shut it off. While discussing the solution, the small business owner told the plumber that he would like all of the pipes from the valve to the sink to be replaced with PEX pipes instead of the existing copper. Concerned, the plumber warned that there was nothing wrong with the existing copper pipes and that he was unsure if PEX was even allowed by local commercial building codes. The plumber even offered to first double-check the codes, but in a hurry to get back to the web developer before he drank all of the coffee, the small business owner told the plumber to just do it. He blindly signed the contract, completely ignoring the written warning about violating building codes, and left the plumber to do the job.

Relieved to have one problem scratched from his list, the small business owner left the plumber and returned to the web developer, who had already drank all of the coffee. Annoyed, the small business owner began making a new pot of coffee while explaining the problem with his website. Hearing the same thing a thousand times before, the web developer began his speech about web standards, usability, accessibility, and information architecture. Within seconds, the small business owner’s eyes had glazed over, and he began ignoring everything the web developer said.

A few hours passed. The plumber finished the job, the small business owner signed the web developer’s boiler-plate contract with 100% satisfaction guarantee, and both the plumber and the web developer left the small business owner to finish his list of things-to-do.

About a month later, the web developer returned to the small business owner’s office to show him the finished product. Coincidentally, the city building inspector arrived at the same time. Learning his lesson about web developers and coffee from the last visit, the small business owner told the building inspector that the work was done down the hall in the first room on the right, and left him to his job.

The small business owner and the web developer went to a computer and the web developer showed the small business owner the finished product. Unimpressed by the lack of motion, flashing, and changing colors the small business owner said that the new site was “nice, but needs something.” The web developer, who truthfully knew this was coming, began regretting his 100% satisfaction guarantee. By the time the small business owner was done stating his “satisfaction requirements,” the site had lost its information architecture, the typography was small and low-contrast, the flash-intro was back, and bigger than ever, and the back end programming was changed from a lightweight CMS to a large enterprise framework that the small business owner’s friend had heard about at a trade show. Concerned for his portfolio, but tired of this particular client, the web developer left the small business owner’s office; defeated and hoping to just get the job done as soon as possible.

Glowing from his victory against the tasteless web developer, the small business owner went down the hall to find the building inspector. The building inspector was sitting in the corner of the room finishing up his report on the plumbing changes. He looked up from the paper and told the small business owner that all of the PEX pipes had to be removed because it was against code in a commercial building. Aghast, the small business owner quickly called the plumber to chastise him for performing such a blatant building code violation. Unimpressed, the plumber simply referred the small business owner to section 4c of their signed contract where it stated that the small business owner had been informed of all building codes to the best of the plumber’s knowledge and that any specific requirements performed by the plumber per the customer were the responsibility of the customer. The plumber also stated that he would be glad to come out and replace all of the PEX with brand-new copper, under a brand-new contract.

About a month later the “improved” website was live and still suffering from the same long page loads, low traffic, and cross-browser inconsistencies. The web designer however, had already folded his company and taken up a new career as an apprentice to the local plumber.

The Morals

Mostly everything we do as web developers is according to some specification or recommendation, but it’s still very easy to ignore them all and still produce a “functioning” website. We compete in an amazing marketplace against everyone from the boss’ nephew to Fortune 500 companies. Because of this, highly skilled web developers working at small companies or even as freelancers often make stupid promises, including 100% satisfaction guarantees. These guarantees do not help anyone because the client is rarely satisfied, the end result isn’t worthy of the web developer’s portfolio, and none of the original problems have been solved.

Plumber’s have the law, the union, air-tight contracts, years of collective experience, and the fact that there’s no such thing as WYSIWYG plumbing software to keep the average Joe from calling themselves master plumbers.

The Soapbox

I’m not sure if it’s a question of attitude, experience, or the fact that there are parts of the plumbing profession that literally stink, but people rarely tell a plumber how to do their job, and I doubt many plumbers would even let someone if they tried. To the same extent, a plumber’s work is usually not up for scrutiny in the public eye, in fact other than in basements and under sinks, it’s rarely even visible to the proerty-owner’s eye.

So what’s my point? With the amount of very talented web developers and designers available world wide, the web has the potential to be a very beautiful, very usable, and very accessible place. However, the web wasn’t build by graphic artists, typographers, interactive designers and information architects, it was built by tinkerers, inventors, and do-it-yourselfers, kind of like the first indoor plumbing. We have a long way to go before there are laws requiring best practices, and professional reputations that allow us to say “this is the way I’m going to do it, and it’s non-negotiable.” But that doesn’t mean we should stop educating our customers and return to table based layouts and excessive use of the blink and marquee tags. It means there’s a light at the end of the tunnel. Until until we reach that time, sell the fact that you’re an expert and not the fact that you’re guaranteeing satisfaction. Let your work speak for itself, a well-designed and well-implemented site will just work and will lead to a satisfied customer, whether or not it’s been guaranteed in writing.

Michael Martinez over at SEO Theory recently posted an interesting article on contract law, terms of service, and how they apply to the web. It’s worth a read and raises some interesting points, but my main beef is the loosely stated complaint about Webmaster Guidelines, specifically those of everyone’s favorite search engine. This complaint, and variations on it, have been bouncing around the SEO/M and Affiliate communities for a while now and I’ve heard more than enough whining on the subject. Frankly stated, it seems they don’t like the fact that they actually need to work in order to keep their spam profitable on the search engine result pages.

Google, as with most other search engines, is a business. In order to actually remain in business, contrary to popular belief on the web, they need to make a profit. In most web business models profit is proportional to the number of users. So far, at least in my opinion, all of this is web business 101. Google has its number of users for one reason, as of now it’s arguably the easiest and most accurate search engine available. Google will retain its users as long as it remains the easiest and most accurate search engine available.

Easy is something that Google has down pat, you can’t get much easier than a single input and a button, accurate is where it gets interesting. In order to remain accurate Google needs to be unmanipulatable. Their algorithm needs to return the most relevant and authoritative content possible, and that means excluding spam. If you’re not publishing the most relevant and useful content out there you don’t deserve to be listed, let alone rank on the first page.

For better or for worse, the bulk of SEO exists to manipulate the search engines, and if you think otherwise you’re seriously deluding yourself. Don’t get me wrong, I believe SEO is absolutely necessary, if you don’t at least try to be listed in the search engines there’s a pretty good chance your site will never be found. However, SEO is only the start, it’s the framework to build your content upon. Good SEO establishes a solid base for accessibility, findability, and information architecture, which is a good thing. Good SEO, however, is not magic. If you do it the Google-approved “right” way it will probably take a decently long time to get a specific ranking, but once you have it, it should be pretty difficult to lose. Taking a shortcut and ignoring the webmaster guidelines may prove useful and in some cases successful, but comes with the underlying risk of being delisted altogether.

Basically, what I’m saying is that SEO, be it black hat or white hat is a gamble. It’s a simple question of risk versus reward, and relies very heavily on your business model. If your business model is to make a quick buck over a short-term, by all means, go black hat, but don’t complain when you’re discovered and your profit dries up. However, if your business model is to make a long-term name for yourself or your business, go white hat, take your time producing quality, relevant content, and rely on Google to keep the spam from appearing ahead of you in the SERPs.

Either way, Google will continue doing what they do, producing to the best of their ability the most relevant SERPs for a given query, and they’ll change their algorithm whenever necessary to make it happen. Instead of complaining about the Webmaster Guidelines, thank Google for them, without them you’d be shooting in the dark. Instead of complaining about quality guidelines, thank Google for them, the higher the consistent quality of the ads and results Google displays the greater the chance they’ll be clicked on.

Complaining about and attempting to change Google’s practices on these points will not help you in the long run. Take a second and think about this. If Google lowers its quality control standards to appease the SEO’s and affiliate marketers, Google becomes less useful to the end user. If Google becomes less useful, less end users will actually use it. If less end users actually use Google, you have less potential customers, and like it or not your profits are going to be less as well.

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.

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.

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.