hungtang.com

The one thing I like about IDEA is that there’s full of goodies waiting to be discovered. Like the other day, I discovered the “changes” panel (ALT-9 for toggling) that tracks the activity of my VCS. Just from a glance, it tells me what local files are non-committed and what incoming files have not been updated by refreshing my VCS at a specified time interval. Often I always forget to do an update before I start writing code which increases the chance of conflicts, but now IDEA can help me detect stale copies and recommends that I do an update, which is pretty convenient. Also it’s much easier to do “diffing” of locally modified or incoming files because all the information is presented to you in one “changes” panel. I don’t appear to find myself navigating through source trees to try to make sense of what changes need to be synchronized. There’s other stuff like “changelist” which I haven’t really use because I do incremental commits rather than batch commits but maybe I’m missing the point. Were all these available before v7? I missed out.

Alright fanboys, we know that you love your web framework and wishing others would see it the way you do. So you’re wondering why people don’t want to use your framework? Here’s my excuses:

• Seam: JSF ’nuff said….immediate=true anyone?
• Struts2: 5 years of Struts1 horror and you expect me to continue to follow the Struts tradition?
• WebWork2 (re-branded to Struts2): i have to implement some interface for my Action?
• Stripes: see WebWork2
• Wicket: hmmm I have to learn Swing again?
• Grails: why is my IDE-refactor broken??
• Tapestry5: 4 versions, so this is the groundbreaking release?
• Spring-MVC: sure when XML is cool again
• Vanilla Servlet+JSP: are you kidding me?

I wonder if I am the only one being inflicted with this kind of syndrome relating to software development. You learn a tool, and you begin to see it as the means to the end. It’s a mixed blessing that, on one hand, I felt that I learned a particular way at solving a problem. On the other hand, it’s annoying insofar that I feel my perception is warped as I find it increasingly difficult to rationalize with people who just don’t see it the way you do.

For example, when I first learned design patterns, I would try to find in previous projects to refactor existing or introduce new code into those patterns that I learned. Or when I learned how cool it was to understand what inversion-of-control means, and the next thing I realized that all my code is managed by Spring or whatever IoC container was popular then. I’m not one who’s afraid to think I’m wrong for behaving this way but it’s a problem I had to control over time with limited success. The new becomes old, and the vicious cycle repeats itself. I guess it’s understandable to see the giddy one gets from learning something new and feeling compelled to announce it to the world about their achievement. It’s like we’re kids constantly requiring approval that we are in fact learning and doing something right–and that’s okay. However, I think we all need to take a step back and reaffirm to ourselves that a tool is just one small piece of a larger puzzle that you’re trying to solve when you’re doing software development. It should rarely be deserving of your entire energy and focus.

Now having said that, these days I’m finding myself reading Groovy a little more than I should, and I think I maybe suffering again. Last time this happen to me was when I was looking up Seam and the syndrome lasted 5 months as that was the time it took to design and deploy the application into production.

I guess I never learn.

I really had no business delving into Groovy until I had recently attended a Groovy presentation at a local JUG meeting (thanks Jeff Brown). Sorry–I am a bit late to the coming-out party so excuse me if all this seems old news. But I came out of the presentation really impressed with the current state of Groovy. I was so impressed that I had quickly downloaded JetGroovy plug-in and began doing some simple and fun experimentation of the “differentiating” features in Groovy mixed with Java code! The soon-to-be-released IDEA7 supports Groovy/Grails, and from my VERY limited experience it does a pretty good job with the usual refactoring and smart capabilities that you have come to expect from IDEA. I love how Java and Groovy can interoperate with each other so seamlessly and effortlessly. It wasn’t always this easy in the past as I understood it; however, the soon-to-be-released Groovy 1.1 will address the ‘chicken-and-egg’ compilation-and-linking issue that made it difficult (but not impossible) to build mixed Groovy and Java projects. I’m excited for the Java platform.

On a related note, I am noticing Grails is seemingly gaining in attention, and, possibly even, some traction in the web-application framework space, and I am now beginning to find it intriguing after being exposed to Groovy. Cool stuff. Is there any reason for Java developers to even want to learn Ruby/Rails now?

OK, ya… so I ain’t afraid to admit that I’m an IDEA fanboy. So what do you think I did when I saw my new colleague whips out his Eclipse in his first day at work? That’s right–I tried to convert him. Any time you try to change someone’s habit, you got to be really really careful though. The wrong approach could make for an uneasy relationship down the road. My observations revealed to me it was doable. It wasn’t easy but I was convinced that if he would give it an honest trial then he would never go back to that crappy Eclipse. Boy I was right!

So I met him recently (we’re both with different employers now) that he told me he has officially been “converted.” While I’m not surprised, but that news brought a smile to my face which, then, leads me to think that there’s a lot more Eclipse-converts than we know. So where are you all at?

From my limited time using jQuery (a month now), I really came to enjoy this compact and powerful javascript library. I stumbled onto this while I was checking out Seam’s Wiki source. [Sidetrack–speaking of Seam’s Wiki, it’s now the web application that powers Hibernate blog–nice!] The only problem that I had with it was that it didn’t automatically bind event handlers to some selection of elements after the page is loaded. So I was looking for answers–and it came with the Live Query plugin, developed by Brandon Aaron. This is a really useful tool when you need to dynamically add and remove parts of a page dynamically by just updating the DOM via append(). I thought I maybe read somewhere that this plugin is in the road map to be part of the core of jQuery–good idea.

Do most coders that use open-source software ever take it for what it truly is? That the code is opened for them to see? I wonder how many people leverage the power of open-source software during development? Do you ever find yourself opening up the source for Spring or Hibernate or even JSF when you encounter problems that deal directly with them? My feeling is that most probably don’t. In my experience, I’d found that having the source code for the tools that I rely on for my projects to be essential. There were many times when I can’t find how to use a particular feature that I then turn to the source and use Find Usages in IDEA. Then, it usually doesn’t take very long to find out the solution. Or if the open-source project is any good, there’s got to test cases for you to look at–that’s the gold mine. Generally you need to have an idea about what the framework does before you actually try to delve into the source otherwise you could get lost pretty easily. Although once you get the hang it, you rarely find yourself stuck on a problem for long. Do most people just rely on the project documentation, books, tutorials, etc? What a waste it seems.

Just a thought here. Who’s willing to bet that we’ll soon see overuse and reliance on annotations? Don’t get me wrong; I think they are great to a certain extent. However, you now have several frameworks (most recently released Google Guice) that proclaim loudly annotations are the best thing ever that could happen for Java. The scary part is that I expect the number of existing and future frameworks to follow this paradigm shift as we are witnessing for better or for worse. My problem is now seeing too many annotations in my source. Recently, Seam introduced another annotation called @AutoCreate used simply as a marker for a component to be created automatically. I was shaking head. Ugh. I mean they could easily just extend the @Name annotation (I honestly think they should rename that to something more meaningful), and added the auto-creation attribute there instead of creating a whole new annotation thereby inevitably inviting users to ask what does that annotation do. Whatever. Someone should write a book on annotation-driven development (ADD) because it looks like it’ll be impossible to get things done one day without it. Funny I can already see it. We’ll be back to the discussion of wanting something simpler. When will this ever end?

I have been putting off looking at Stripes for awhile because I haven’t had the need to look elsewhere. But since majority of Stripes’ users marvel at the ease-of-use and simplicity of Stripes, I became curious and finally delve in the other day. Well after just only 30 minutes looking at Stripes, I have come to my own conclusion that it is a well designed, small, simple, compact but powerful MVC request-driven framework. Here are some other observations. Note that I’m coming from, primarily, a Seam user.

Good

• Small. 350K for the stripes.jar. No other non-standard dependencies required.
• Simple. Should expect zero-to-low learning curve for someone who is coming from MVC/Struts background.
• Annotations over XML for configuration. Seems like Annotations is fashionable nowadays in Java land.
• Conventions. e.g. URL–action mapping => easy to locate source files.

Bad

• JSP. (I just don’t like them)
• Validation redundancy in UI and domain layer.
• Rich conversational-model support lacking (although support is available for Wizard-like forms)
• Stateful component management still require much code (compared to that of Seam)
• Not purely POJO-based (hard dependency implementing ActionBeanContext)

I came out of my brief tour to appreciate the simplicity of Stripes. It definitely packs a lot of punch in such a compact framework. I can certainly see why and how it gets a lot of praises. So what did I get out of this? Just nice to know Stripes maybe my request-based framework of choice some day whenever that might be.

Whilst Intel is preparing for 80 cores some day, you got to be thinking that the field of Concurrency and parallel programming will garner much attention from current and prospective developers now, if not very soon. Yes, I know– Concurrency is damn hard and a majority of developers probably dread and fear the thought of ever writing a single line of multi-threaded code for their entire career. Or maybe they think they can get away by favouring towards the multi-process model which, arguably, can work just as well (see PostgreSQL). However, I don’t doubt this impending phenomenon is real and have started to embrace this new way of thinking before it gets too late. Imagine your boss orders a brand new, expensive 80-core server machine for the business and asks you to take full advantage of it. Don’t tell me your answer to him would be along the lines of “I don’t know how”. Yikes

Fortunately for Java, it is blessed with Doug Lea’s java.util.concurrent package which does an excellent job at simplifying concurrent programming–and I do wholeheartedly mean that. As well, I highly recommend Java Concurrency in Practice by Brian Goetz. I don’t buy many technical books nowadays, but found this one particularly engaging to read.

Update 3/15/07: A related discussion on TheServerSide on The Multi-Core Dilemma