It turns out that the answers to those questions are: Yes. No. What money?

I wanted a challenge. I wanted something that would transcend the way I’ve been thinking about programming. I wanted something that I knew would make me a better software engineer. I wanted something more expressive and powerful.

Luckily, the past two weeks I’ve had an excellent opportunity at work to apply and push my learnings of Clojure further. I thought it would be an opportune time to share the good, the bad, and whatever else in between. A reflective and honest “disclojure”.

It seems that the best way to learn a new language is finding well documented source code and blogs from likeminded people. Clojure is a “newer” burgeoning language so it goes without saying that there are far fewer comprehensive online resources to tap into. The blogosphere is actually a bit sparse on Clojure. I’d strongly recommend having a couple Clojure e-books at your fingertips for reference. Speaking of books, don’t expect to learn Clojure by reading a stack of books for 5 months and think that it will magically flow from your digits. It’ll never ever happen. The best recipe for me has been a 1:1 ratio of time spent reading and coding. If you’re in pursuit of books that might help you on your quest to learning Clojure, remember Clojure is a Lisp. The Little Schemer and The Seasoned Schemer have been priming Lisp programmers for decades. If anything reading these two books will make you hungrier for more, wink wink nudge nudge.

Github has been an invaluable asset when looking for good source code examples. One of the questions I continue to ask myself while coding, “Is the code I’m writing idiomatic?” That is important to me because one of my main objectives is to transcend my thinking and programming style. So before you add that dependency to your Leiningen project.clj have a peek at the author’s source. In reality, you might often find yourself sifting through source because of the lack of documentation or examples. Actually I read other developers source code daily for this very reason. So let me re-phrase that, while you’re trying to figure out how the heck some library or “clojar” works, be mindful of the coding style. Undoubtedly you will pick up something useful.

I had a perplexing problem the other day and for the life of me I couldn’t figure it out. I simply lacked the context necessary that other more advanced Clojure developers have. I found my answer after posting my question on the Clojure forum hosted on Google Groups. More specifically, I was using lein run to execute a simple database preparation task, but the process was hanging on well after it completed. It wasn’t until someone informed me that I should use (shutdown-agents) after the task I was running finished because of the way the agent thread pool delays shut down. See my gist here. The turn around time on the Clojure forum varies. I think it took 2 or 3 days before my post was moderated and then received a response. Most if not all of the Clojure core developers answer questions in this forum so the responses are of high quality and are super helpful.

Sometimes you’re totally stuck. Even after using your e-book as a reference and reading the source code it just doesn’t make sense. Enter Clojure IRC! During the daytime it is bustling with chatter. Lots of the folks who answer questions on the Clojure forum hang out here too. In my experiences, the community that gathers here is friendly and willing to help.

Clojure is as expressive, powerful, and succinct as advertised. The Java interop with Clojure is about the simplest and cleanest I’ve seen thus far and that includes JRuby and Scala. I’m impressed with the clean HTTP API Ring has to offer and using the Clojure JDBC API is really nice. If only JDBC were that easy in Java there would be no need for heavyweight clunky ORMs. In terms of testing, speclj is a pretty awesome testing framework that mirrors Ruby’s RSpec API. I also have enjoyed rolling my own solutions for things that aren’t available yet. And one of the most important parts…it is fast and performs very well under load. I don’t make these claims falsely either, we ran a load test today at work and we were absolutely thrilled with the response times and throughput. I look forward to posting more about Clojure in the coming weeks. Stay tuned!

Attaching to a process remotely might seem difficult or impossible, but if you are able to use X11 window forwarding through SSH it is a nice option. Check your /etc/ssh/ssh_config and make sure that you see ForwardX11 is set to “yes”, sometimes it is X11Forwarding, check your Linux distribution to be sure.

Host *
#   ForwardAgent no
   ForwardX11 yes

Once you have made this change, restart your ssh service /etc/init.d/ssh restart or service ssh restart. Voila. Now ssh onto your remote server with the X option

ssh -X user@remote.server.com

So once you’ve SSH’d into your remote server startup jconsole, assuming it is in your PATH you should be able to just type it straight away. You should then immediately see that jconsole has started up through X11 as if it were running on your local machine. Just select the PID and you will be able to start monitoring memory, threads, garbage collection, etc.

jconsole

Generally when I am load testing an application (I use JMeter) on the JVM I will crack open jconsole to see if there are any blaring memory leaks or memory consumption problems.

Observation

I’ve had the opportunity to work with many Ruby code bases the past few years. One reoccurring theme I keep seeing is bloated models. Fat chunky ugly bloated models. Literally thousands of lines, mixing in of modules, and extensions galore. All of which are convoluting the notion of two completely separate things, data access and business logic. The phrase “fat models” has been taken too literally. I have one question. Why?

I am officially declaring it an anti-pattern for the Ruby community. A “model” is supposed to be an object representation of the underlying data your application needs. So when working with a _data_ model, you ought to stay laser focused on the DML behavior. Get your data and get out. Move on to the next set of objects that are responsible for determining, strategizing, composing, decorating, and displaying (these action verbs should sound familiar) the object representations of your data.

Remarkably most Java projects I’ve seen get this one right. Typically there is DAO, there is an entity, and beyond those two objects that are focused on DML, there are other objects that responsible for doing “things” with that data. I say “things”, but I am referring to whatever your business or domain does with the data beyond creating, reading, updating, or deleting it.

Real World Example

Here’s a solid example for the sake of discussion. Every e-commerce site has some notion of a product or service. Suppose you are modeling a “Product”. Your product has some attributes regarding description, size, weight, color, etc. You get the gist. Let’s not forget pricing, every product has some type of pricing. I see pricing go sideways almost every time. Pricing always starts out simple. You might have a “base” price and “selling” price. The “base” price is your company’s cost, and the “selling” price is your customers cost. Shortly after you deliver that functionality your product development team will undoubtedly come up with all kinds of pricing strategies.

These should all sound familiar:

• site wide sales
• single use coupons
• volume discounts
• bundling discounts
• affiliate pricing tiers
• employee discounts

Wrong

This is where it goes sideways. It’s so easy, right? Just fetch the “selling” price within an instance of the “Product” model and being applying the business rules inside your model.

Right

I hinted a couple times in that this is a perfect application for the strategy pattern. Not familiar? Each individual pricing type should have it’s own strategy. It is safe to let a “Price” object flow though the strategies. The pricing strategies classes can then apply the discounts and the appropriate pricing separately. One of the golden rules is that composition is almost always better than inheritance and that is the construct the strategy pattern embraces.

That should look and feel better on many different levels. You should observe the freedom to add or remove pricing features without the tight coupling to any particular model. In the case that your business evolves, and it inevitable does, your pricing strategies should be flexible enough to handle any sort of pricing irrespective of whether it has anything to do with a “Product” or not. It should also be easier to test. There are no worries about the creation of database objects or fixtures, simply assert the strategies of pricing with a “Pricing” object. Also as the pricing strategies grow in size and complexity it will certainly be easier to abstract away into a separate library.

Facetious Wonderment

Here is where my “wonderment” comes into action. How is it possible that so many “Rubyists” are ignoring traditional OO programming techniques and patterns when coding at the data access layer? Is it possible that the suggestive nature of the most popular and opinionated Ruby framework has created some psychological voodoo on developers making them believe that classes only come in 4 flavors (models, views, controllers, and helpers)? Is it really that scary to add new directories or categorize your classes differently? Perhaps it is the dynamic nature of the language? Can it be the power and “expressiveness” of the language? A language wherein the lack of true interfaces, strict type checking, and the magical injection of behaviors and methods has lead its developers down a path of wicked and corrupt habits. Gosh…why should I create a new class when I can just inject a few unrelated wacky ass methods to the String class? Is it laziness? Could it be that Ruby has given way and lowered the barrier to entry for people who shouldn’t be programming at all? Or perhaps it is a lack of classic OO programming training?

Conclusion

Draw your own conclusions. The major takeaway for me is that I’m sick of it; or rather I’m sickened by it. Unwavering I will remain steadfast on an ever-quest to right the wrong where ever my fingertips land regarding this matter. You should too. There are some great code katas that focus on this very problem set. Give the Gilded Rose kata a whirl. You might be surprised by the harshness of my befuddlement and/or the generalizations I’ve made about the Ruby community. Don’t get me wrong. There are many super intelligent people out there that swear by Ruby, who are doing the right thing, and you know who you are. I am just saying based on my observations and experiences there are many more people doing the wrong thing, specifically in the data access realm, that outweigh the right-doers. But hey that’s the case with most things in life, isn’t it?

 
require 'rubygems'
require 'rspec'
 
module Enumerable
  def inject(*args, &block)
    if(args.size == 2)
      inject_binary_operation(args[0], args[1], self)
    elsif(args.size == 1 && !block_given?)
      inject_binary_operation(self.first, args[0], self.drop(1))
    else
      the_memo = args[0] || self.first
      self.each { |item| the_memo = yield(the_memo, item) if block_given? }
      the_memo
    end
  end
  alias :reduce :inject
 
  private
 
  def inject_binary_operation(the_memo, operator, enum)
    raise TypeError.new("#{operator} is not a symbol") unless operator.is_a?(Symbol)
    enum.each { |item| the_memo = the_memo.send(operator, item) }
    the_memo
  end
end
 
shared_examples_for "an Enumerable object" do
 
  describe "inject" do
 
    describe "given there is a specified memo value" do
 
      it('should return the newly injected "memo" value if using a block') do
        enumerable.inject([3,4,5]) { |memo, enum_item| memo.include?(enum_item) ? memo : memo << enum_item }.should == [3, 4, 5, 1, 2]
      end
 
      describe "when it is a binary operation" do
 
        it('should return a TypeError because the single argument is not a Symbol') do
          lambda { enumerable.inject(2) }.should raise_error(TypeError)
        end
 
        it('should add the values') do
          enumerable.inject(2, :+).should == 8
        end
 
        it('should multiply the values') do
          enumerable.inject(2, :*).should == 12
        end
 
        it('should subtract the values') do
          enumerable.inject(2, :-).should == -4
        end
 
    end
 
    end
 
    describe "given there isn't a specified memo value" do
 
      it('should return the newly injected "memo" value if using a block') do
        enumerable.inject { |memo, enum_item| memo > enum_item ? memo : enum_item }.should == 3
      end
 
      describe "when it is a binary operation" do
 
        it('should add the values') do
          enumerable.inject(:+).should == 6
        end
 
        it('should multiply the values') do
          enumerable.inject(:*).should == 6
        end
 
        it('should subtract the values') do
          enumerable.inject(:-).should == -4
        end
      end
 
    end
  end  
end
 
describe Range do
 
  it_should_behave_like "an Enumerable object" do
    let(:enumerable) { (1..3) }
  end
 
end
 
describe Array do
 
  it_should_behave_like "an Enumerable object" do
    let(:enumerable) { [1,2,3] }
  end
 
end

I especially like the RSpec documentation format because it provides such great readability. When appropriate the “shared_examples_for” is also nice to keep your test suite DRY.

$ rspec injectable.rb --format documentation
 
Range
  it should behave like an Enumerable object
    inject
      given there is a specified memo value
        should return the newly injected "memo" value if using a block
        when it is a binary operation
          should return a TypeError because the single argument is not a Symbol
          should add the values
          should multiply the values
          should subtract the values
      given there isn't a specified memo value
        should return the newly injected "memo" value if using a block
        when it is a binary operation
          should add the values
          should multiply the values
          should subtract the values
 
Array
  it should behave like an Enumerable object
    inject
      given there is a specified memo value
        should return the newly injected "memo" value if using a block
        when it is a binary operation
          should return a TypeError because the single argument is not a Symbol
          should add the values
          should multiply the values
          should subtract the values
      given there isn't a specified memo value
        should return the newly injected "memo" value if using a block
        when it is a binary operation
          should add the values
          should multiply the values
          should subtract the values
 
Finished in 0.007 seconds
18 examples, 0 failures

And of course the gist…
https://gist.github.com/1096650

I’d like to offer up a pattern I follow when writing JavaScript.
Let’s take a look at the JavaScript MVC pattern I follow.

First things first. In your JavaScript directory, create the following folders.

• controllers
• models
• views
• handlers
• pages

Handlers? Pages? What? No worries. I will discuss each of these and of course you can fit and mold this pattern to your needs. My examples assume you’re using jQuery, but you could use MooTools, prototype, or none of them.

Models:

As an example lets say you have some data that represents projects. Create a file under your models directory called project.js. I like to do “Object-Oriented” JavaScript so maybe your project.js would look like this.

Project = function(projectId) {
  this.projectId = projectId;
}
 
Project.prototype.find = function(projectId) {
  $.getJSON('projects/' + this.projectId + '.json', function(data) {
    //do whatever with your data
  }
}

I’d also like to point out that I often like to write the JSON or XML I need (when I can) to the page so that I don’t make superfluous network calls. In this example I created a function called find that makes an Ajax call, but it could be just as simple to read JSON from a hidden element with a custom attribute called “data” on it like so.

/*
* Reads JSON from a hidden element on the page with an attribute called 'data'
* Example: <input type="hidden" />
*/
 
Project.prototype.all = function(dataSelector) {
  return $.parseJSON(dataSelector.attr('data'));
}

My philosophy on JavaScript models is to keep them centered on the retrieval of the data they represent. Nothing more, nothing less.

Views:

This is the area where I feel most people go wrong and is generally my biggest gripe. How many times have you cracked open a .js file and found N-instances of the selector flying all over the code. Let me clarify. For example, you have a project carousel widget on your site and the selector has an id, namely projects. So everywhere, you look

 $('#projects').something

is recklessly abundant all throughout the code. Good luck re-factoring or repurposing that, even _with_ tests, especially after a few months.

Now, had you captured all the selectors for your projects view in a file managed under the views directory and properly added a layer of encapsulation. It would have taken you 2 seconds to swap whatever existing selectors there were with a new one or perhaps extended your projects view. Sometimes I like to use a view factory to encapsulate my views. Again, you don’t have to use the factory pattern you could just run the prototype pattern directly. Here is an example:

ProjectViewFactory = (function() {
 
  function BaseProjectView() { this.name ="baseProjectView"; }
  BaseProjectView.prototype.getProjectDataSelector = function() { return $('#projects'); }
 
  function CarouselProjectView() { this.name = "carouselProjectView"; }
  //I hand rolled a simple inheritance mechanism, you can find it under my Github account as inheritance.js
  CarouselProjectView.inheritsFrom(BaseProjectView);
  CarouselProjectView.prototype.getProjectDataSelector = function() { return $('#carouselProjects'); }
  CarouselProjectView.prototype.getNextSelector = function() { return this.getProjectDataSelector.select('.next'); }
  CarouselProjectView.prototype.getPreviousSelector = function() { return this.getProjectDataSelector.select('.previous'); }
 
  return {
    getCarouselProjectView: function() {
      return new CarouselProjectView();
    }
  }
}();

The fundamental concept is to align your view widgets on a page to a file managed under the views directory. Anytime, you use a selector it better be in a file like this. Never leak a selector outside the views directory. It is a very simple and straightforward rule to remember.

Controllers:

I like to keep my controllers slim and trim akin to the principle used very often in the Rails community.
Your controllers should be passed the appropriate views required to activate and listen for the appropriate binding events (ie click, mouseover, etc). The controller should only bind the events and then hand the rest of the actual duties off to what I call a handler (we’ll discuss handlers next). Here is an example:

ProjectsController = (function() {
 
   return {
 
   bindEvents : function(projectsView) {
     var projectModel = new Project();
     var projectHandler = new ProjectHandler(projectsView, projectModel);
 
     projectsView.getNextSelector.click(function() {
       projectHandler.updateToNext();
     });
 
     projects.getPreviousSelector.click(function() {
       projectHandler.updateToPrevious();
     });
    }
  }
})();

Handlers:

I’d like to introduce one more letter in the MVC acronym, “H”. A handler is in charge of the dirty work bound to the event triggered. So you can imagine that with a project carousel with a next and previous button that several different things might happen like an image transition, description, numbering, etc.

ProjectHandler = function(projectView, projectModel) {
  this.projectView = projectView; this.projectModel = projectModel;
}
 
ProjectHandler.prototype.updateToPrevious = function() {
  // fill in the details here
}
ProjectHandler.prototype.updateToNext = function() {
  // fill in the details here
}

Pages:

The last and final piece of the puzzle. So a page may consist of many different things including a project carousel, recommendations, comments, and whatever else you can dream up. Assuming you followed the rules given above that means you’ve developed a projects, recommendations, and comments controller along with their corresponding views, models, and handlers.
So a page might look something like this:

SomeAwesomePage = (function() {
  return {
    bindEvents: function() {
      //initialize the views needed here
      ProjectsController.bindEvents(projectsView);
      RecommendationsController.bindEvents(recommendationsView);
      CommentsController.bindEvents(commentsView);
    }
  }
})();

Following this pattern lends itself to a very flexible and modular design. It is totally agnostic to other frameworks that you might already be using. The beauty part of this approach is that you can take a pure JavaScript approach without the bulkiness or dependency on yet another pre-defined framework and spin it to the needs of your project. I always encourage testing JavaScript. Recently I’ve been pairing this pattern with Jasmine.

Here is the second part of the presentation I gave:
http://techwhizbang.com/2011/01/mongodb-part-2/

It is sort of crazy to think that the JVM has been overlooked and misunderstood by so many for so long. Most developers think the JVM is a platform/OS agnostic place where Java byte code gets executed. Partly true. It is platform agnostic. Funny thing is the JVM doesn’t know a damn thing about the Java syntax as we developers know it, all it knows about is the specific JVM byte code format it knows how to interpret. So this means if you can “compile” a .rb or .clj file and if it outputs the expected JVM class byte code format, you’re ready to rock. This ought to dispel some of the perceived magic involved in getting other languages running on the JVM. Just stop and consider what an amazing forethought that was, or was it?  In any case, brilliant.

You might be wondering why this JSR is even needed if these dynamic languages are already running on the JVM? The truth is the implementers of JRuby, Clojure, etc have gone through great lengths and round-about ways to make them work. Some would even call these solutions creative and innovative hacks. Personally, I am overjoyed that people are thinking out of the box and have pushed the JVM to new horizons and given it new life. Here is interesting article that I found that answers these types of questions.

http://java.sun.com/developer/technicalArticles/DynTypeLang/index.html

This JSR is part of a bigger and broader vision of the JVM known as the “Da Vinci Machine Project”.

http://openjdk.java.net/projects/mlvm/

Most developers know that the Java language is dated, it’s old news, but it seems many have a hard time coming to grips with it. The JVM is the future, not the Java language. But wait, what about the argument of Java’s excellent performance, what about all the great libraries and tools that have been built over the years? We need to embrace the good things, but move on to greener and more productive pastures. The beauty part of the new JVM languages is that you can intermix and mingle Java libraries with your choice of language. Check the facts, some of the “newer” languages to run on the JVM are on par with Java or close to it.

Evolve and rise above so as not to become stoic boilerplate funk. The JVM is the future where all languages may frolic about.