Deprecated: Assigning the return value of new by reference is deprecated in /home/edelabar/ on line 472

Deprecated: Assigning the return value of new by reference is deprecated in /home/edelabar/ on line 487

Deprecated: Assigning the return value of new by reference is deprecated in /home/edelabar/ on line 494

Deprecated: Assigning the return value of new by reference is deprecated in /home/edelabar/ on line 530

Strict Standards: Declaration of Walker_Page::start_lvl() should be compatible with Walker::start_lvl(&$output) in /home/edelabar/ on line 594

Strict Standards: Declaration of Walker_Page::end_lvl() should be compatible with Walker::end_lvl(&$output) in /home/edelabar/ on line 594

Strict Standards: Declaration of Walker_Page::start_el() should be compatible with Walker::start_el(&$output) in /home/edelabar/ on line 594

Strict Standards: Declaration of Walker_Page::end_el() should be compatible with Walker::end_el(&$output) in /home/edelabar/ on line 594

Strict Standards: Declaration of Walker_PageDropdown::start_el() should be compatible with Walker::start_el(&$output) in /home/edelabar/ on line 611

Strict Standards: Declaration of Walker_Category::start_lvl() should be compatible with Walker::start_lvl(&$output) in /home/edelabar/ on line 705

Strict Standards: Declaration of Walker_Category::end_lvl() should be compatible with Walker::end_lvl(&$output) in /home/edelabar/ on line 705

Strict Standards: Declaration of Walker_Category::start_el() should be compatible with Walker::start_el(&$output) in /home/edelabar/ on line 705

Strict Standards: Declaration of Walker_Category::end_el() should be compatible with Walker::end_el(&$output) in /home/edelabar/ on line 705

Strict Standards: Declaration of Walker_CategoryDropdown::start_el() should be compatible with Walker::start_el(&$output) in /home/edelabar/ on line 728

Strict Standards: Redefining already defined constructor for class wpdb in /home/edelabar/ on line 306

Deprecated: Assigning the return value of new by reference is deprecated in /home/edelabar/ on line 103

Strict Standards: Redefining already defined constructor for class WP_Object_Cache in /home/edelabar/ on line 425

Deprecated: Assigning the return value of new by reference is deprecated in /home/edelabar/ on line 21

Deprecated: Assigning the return value of new by reference is deprecated in /home/edelabar/ on line 623

Strict Standards: Redefining already defined constructor for class WP_Dependencies in /home/edelabar/ on line 15

Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/edelabar/ on line 311
java archive at Eric DeLabar

Archive for the ‘java’ Category

Jack of Even More Trades, Master of Even Less?

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.

JavaOne 2008 – Day 4

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!

JavaOne 2008 – Day 3

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.

JavaOne 2008 – Day 2

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!

JavaOne 2008 – Day 1

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!

Grow Up and Code

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:

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.