Nicholas Hagen

See my Gist below for more information.

In this article, I will talk about how Grails, GORM in particular, maps various types of queries into MongoDB queries. Understanding the query mapping is extremely important in order to help understand and identify how performance bottlenecks might incur. This is especially true in the non-relational aspect of MongoDB where it is entirely possible that Grails could end up making several roundtrips to MongoDB to fill out the entire object model. If you are unfamiliar with MongoDB within Grails and GORM, read my previous post.
(more…)

One of the newer, and extremely powerful and cool, features of Grails is the support for NoSQL dialects in GORM. If you are not familiar with GORM, it refers to the Grails Object Relational Model, and was initially developed alongside Hibernate primarily. It basically took ORM solutions like Hibernate, and Groovified them. The result is extreme simplicity in not only defining object models but also in querying data via dynamic finders and a custom DSL for criteria queries. In the 2.x releases of Grails, GORM was extended to support other options other than Hibernate. The first of these was NoSQL and in the newer releases since it is beginning to include support for REST as well. Grails now supports a variety of NoSQL dialects including Redis and MongoDB. The dialect I am interested in and will be demonstrating is MongoDB.
(more…)

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…)