Nicholas Hagen

As part of a load testing project, I needed to collect and store data as fast as possible in a multi-threaded environment. This meant synchronizing on collections to avoid collisions. Synchronization is always a bad idea in any performance critical application. In my simple testing, adding to a synchronized ArrayList can be almost 4x slower than a non-synchronized ArrayList. Then, I had an interesting idea of what would be faster: a synchronized list or a hash map keyed off the local thread id? In my testing, the map was actually faster as it required no synchronization…almost 2x faster. It is still slower than non-synchronized list, understandably so, but it at least gets to within 2x worse. The hash map example works since upon retrieval, you are guaranteed that the list being added to cannot collide except with itself as the list is tied to a specific thread. This is similar to a ThreadLocal, except ThreadLocal is even slower performance. The downfall of this method is that it assumes you are primarily concerned with ‘add’ and that reads only occur at the end at which point you have to merge. This also assumes that order does not matter. In my load testing project, all of that holds true. All I care about is storing metrics as fast as possible without colliding.

I have long had mixed feelings on the future of JavaScript. Many people believe it is the future. Others believe it is the new VM of development (similar to Java). Others believe it as the sole language across server and client-side development (one language to rule them all). So, where do I stand? I stand somewhere between I guess. I believe the concept of JavaScript as a VM supporting new languages like CoffeeScript, Dart, TypeScript, etc. In fact, I applaud those efforts. JavaScript, as a language, moves at such a snail pace due to lack of quick browser integration. As a result, the language, syntactally, is out-dated, whereas the newer languages such as CoffeeScript, Dart, and TypeScript compile into JavaScript but provide several syntactic sugar syntaxes. My biggest issue is that these languages still have to compile into JavaScript and be at the mercy of server side providers (V8/Node.js) and browser vendors. I’m also not a believer in JavaScript as a scaling language, performance and development-wise, at least compared to other languages (Java, Ruby, Python, etc). JavaScript is definitely a great language, but it has several pitfalls that I believe the “cool-factor” simply ignores in order to tout its resurgence. JavaScript definitely has a place, but often times there are better choices that developers fail to utilize because they want to use JavaScript as the cool kid on the block. The right tool needs to be used for the right job to be successful.

(more…)

As mentioned in my previous post, this article series is around my Budget Analyzer application that I built using Grails and jQuery Mobile frameworks. I hope to present this as a more real world example of using Grails along with using jQuery Mobile for the client side responsible design that can scale to any sized client (phone, tablet, desktop, etc). The jQuery Mobile framework is an excellent library that simplifies that approach dramatically.
(more…)

In this post, I will present one of my newest applications that I built using Grails and jQuery Mobile frameworks. I hope to present this as a more real world example of using Grails along with using jQuery Mobile for the client side responsible design that can scale to any sized client (phone, tablet, desktop, etc). The jQuery Mobile framework is an excellent library that simplifies that approach dramatically.
(more…)

One of the recent additions to TeaTrove I am making is adding the between and in operator. This may seem trivial, but they are quite powerful as well as generally better performing, not to mention easier to read. The SQL standard has had these operators for decades because they just make sense. I’m rather surprised by how many modern day languages do not have it. Many of the languages do have support for the in operator, which is a good addition, but it’s not a suitable replacement as the between operator.
(more…)

Although some would say there are two competing standards for handling live events on the web, websockets and server-sent events (event source), they are really very different from each other with their own use cases. I have always been a proponent of websockets as it is bi-directional and as a result more powerful. Although in reality, there are few cases where you truly need bi-directional support. Nonetheless, I’ve always been of the opinion of “what if” one day you need bi-directional support. It’s better to be on a platform today that supports it tomorrow. As a result, I’ve never had a good use case for server-sent events. Today, I came across one.

(more…)

To Whom It May Concern at AT&T:

From the rest of the community who is fully confused by the latest announcement from AT&T concerning Facetime over 3G and the requirement for the new shared data plans, we would like to have some questions answered that would help to further solidify your position and rationale for this announcement.
(more…)

Web applications in Java EE (and even SE) have many components from MDB configuration to JMS configuration to Servlet configuration to JPA/database configuration. Each of these components has their own methodology of configuration. Further, some are easier to manage than others. The reason this is important is when it comes to managing your environments from development to test to production. The most ideal situation is a single build and archive (WAR, EAR, etc) that you can deploy to any environment and change the settings at the container level. This blog article hopes to explain some methods of managing those configurations.
(more…)

In the previous two blog articles (simple projects) (plugins), we touched on setting up standard Grails applications and plugins through Maven. In this article, we are going to talk about multi-module projects and how to build plugins and applications together as a single Maven build. (more…)

My last blog article explained using the Maven integration in the recently released 2.1 version of Grails on simple applications. Today, we are going to look at using the Maven integration and build, manage, and deploy plugins. Plugins and applications in Grails are very similar to each other. The big difference is that a plugin has a special plugin descriptor file named *GrailsPlugin.groovy where * is the name of the plugin. Other than that, they behave very similar to each other. Plugins generally do not have as many dependencies, however, as they are not required to include the web application environment typically. (more…)