Dynamic languages, once relegated to hobbyist and small mom-pop development shops, now (as in the last 2-3 years) seem to be the latest fad in "enterprise" development shops. I think this was largely due to the success of Ruby on Rails and Python which showed that you can write maintainable large scale software using dynamic languages.
Groovy appears to be the Java community's answer to dynamic languages. Groovy is a superset of Java which means that your existing Java code should mostly work in a Groovy interpreter. Groovy provides many of the syntactic sugar that you see in dynamic languages such as key-value dictionaries (hash tables), named parameters, closure, and etc.. Groovy has been submitted to Java Community Process program for standardization.
I'm still a bit mixed about using dynamic languages because I like the security of compile-time type checking. However, I do see myself using Groovy to write my unit tests since the syntactic sugar can potentially make my unit tests easier and faster to write.
Saturday, June 20, 2009
Tuesday, June 9, 2009
Spring MVC
Here is a nice link describing the features of Spring MVC:
http://www.infoq.com/articles/spring-2.5-ii-spring-mvc
The information may be outdated with Spring 3.0 just around the corner.
One of things I like about the Spring Framework in general is that it's not very intrusive. Depending on your requirements, you can use the Spring Framework without: extending any class, implementing any interface; nor writing any adapter classes. This makes the framework extremely flexible because you are not locked into their application programming interface (API). If you're reading this blog, then you probably know that using open source frameworks is a way to avoid vendor lock-in. However, using open source alone is not enough to prevent vendor lock-in. We also have to think about API lock-in. The more your framework requires implementing/extending framework specific interfaces/classes, the more at-risk you are to API lock-in.
The Spring Framework also has a la carte style approach of integration into your existing software components. You use what you need and can add the incrementally framework as you evolve as a developer. In my current project, I started off using Spring's mock (stub) objects for testing (instead of writing my own MockHttpServletRequest). Then I used Spring's Object/XML Mapping (OXM) framework to domain convert objects to XML and vice versa. Now I'm looking to use Spring's MVC framework and eventually move all my object configuration and construction using Spring's core bean container.
http://www.infoq.com/articles/spring-2.5-ii-spring-mvc
The information may be outdated with Spring 3.0 just around the corner.
One of things I like about the Spring Framework in general is that it's not very intrusive. Depending on your requirements, you can use the Spring Framework without: extending any class, implementing any interface; nor writing any adapter classes. This makes the framework extremely flexible because you are not locked into their application programming interface (API). If you're reading this blog, then you probably know that using open source frameworks is a way to avoid vendor lock-in. However, using open source alone is not enough to prevent vendor lock-in. We also have to think about API lock-in. The more your framework requires implementing/extending framework specific interfaces/classes, the more at-risk you are to API lock-in.
The Spring Framework also has a la carte style approach of integration into your existing software components. You use what you need and can add the incrementally framework as you evolve as a developer. In my current project, I started off using Spring's mock (stub) objects for testing (instead of writing my own MockHttpServletRequest). Then I used Spring's Object/XML Mapping (OXM) framework to domain convert objects to XML and vice versa. Now I'm looking to use Spring's MVC framework and eventually move all my object configuration and construction using Spring's core bean container.
Friday, June 5, 2009
Failed Searches
I'm lazy. Very lazy. I don't like keyword searches that do not return what I want on the first page. I don't like it because I have to make extra mouse clicks to find what I want. And I don't like extra mouse clicks because I'm lazy.
I'm sure I'm not alone. As obvious as this may seem, many commerce websites don't get it. They develop interfaces that make me perform unnecessary mouse clicks. They make me turn pages. If I have to turn to the next page of a results set, then your search has failed. Your search should have return the relevant results on the first page. Many sites also make me sort my search results. If I have to waste mouse clicks to sort my results, then your search has failed. Your search should have returned in the order of most relevant results. Some sites have even gone as far as making me filter my results set. If I have to filter the results set, then your search has failed. Your search should have returned only filtered results.
This all may seem a bit harsh. The point, however, is not to set unrealistically high criteria of what constitutes a good search engine. Rather, I'm suggesting that as developers we need to value mouse clicks. Every mouse click is precious and should not be wasted on paging, sorting, and filtering -- none of which would be needed if the search was done right in the first place. In the end, paging, sorting, and filtering are all crutches for broken searches.
I'm sure I'm not alone. As obvious as this may seem, many commerce websites don't get it. They develop interfaces that make me perform unnecessary mouse clicks. They make me turn pages. If I have to turn to the next page of a results set, then your search has failed. Your search should have return the relevant results on the first page. Many sites also make me sort my search results. If I have to waste mouse clicks to sort my results, then your search has failed. Your search should have returned in the order of most relevant results. Some sites have even gone as far as making me filter my results set. If I have to filter the results set, then your search has failed. Your search should have returned only filtered results.
This all may seem a bit harsh. The point, however, is not to set unrealistically high criteria of what constitutes a good search engine. Rather, I'm suggesting that as developers we need to value mouse clicks. Every mouse click is precious and should not be wasted on paging, sorting, and filtering -- none of which would be needed if the search was done right in the first place. In the end, paging, sorting, and filtering are all crutches for broken searches.
Subscribe to:
Posts (Atom)
Posts
