Bright Future for Dynamic Languages
I find myself fascinated by the increasing popularity of dynamic languages. For many of us dynamic language introduction came by way of Ruby, Python, and/or Javascript. While my fascination with these languages hasn’t ended, I am more enthralled with dynamic languages whose strength is concurrency. Indeed, these are exciting times and there is a shift happening in the software community. Honestly, who hasn’t bragged on Twitter that they just finished reading the latest book on Clojure or Erlang? Clearly there is momentum and change in the air. The future of software and computing in the next 10 or 15 years is being shaped and molded with the underlying fundamentals and principles of these languages.
I’m excited about the evolution happening. There is a higher degree of maturity, professionalism, and most importantly scientific and mathematical infused creativity. We’ve all heard the anecdotal comparison of a craft like architecture versus software. Yes software as a craft is merely a fetus when compared to architecture. For centuries architecture has used equal parts science and artistry to build some of the most breathtaking sites in the world. I believe the software community has really begun using more scientific and mathematical backed artsy creativity. We must flex both sides of our brains to imagine the crazy, the impossible, and make it reality. I digress…back to the languages.
Why am I so fascinated? The bottom line is we are evolving and learning.
- Language composition and leverage
- Developer productivity
- Functional programming and concurrency
Clojure and JRuby both run on the JVM. Undoubtedly there are statistics somewhere showing that Java is one of the most popular languages of our time and it is probably running in your software shop in some capacity. As a result the barrier to entry for integrating and using these new languages has been lowered. It is comparatively easier than the transition when Java gained über popularity in the 90′s. However, this isn’t as important and _fascinating_ as how these languages integrate directly with the Java language. The number of possibilities for composing and leveraging preexisting Java libraries with these languages seems endless. This eliminates many reasons to reinvent a library or API. When you wish you could use some Java component, framework, or API, you can – easily! I’ve used this fact to my advantage using JRuby numerous times. The other really neat possibility that I haven’t messed around with yet is using Clojure in JRuby.
The next reason for my interest is directly related to why Ruby is hot and will remain so for a long time. On a side note, I feel the need to disclose that I am not a Ruby “fan boy”, I’ve spent my time in the ranks wrestling with C and Java and still have an fond appreciation for both. Back to what is important, developer productivity. Here are some of the things these dynamic languages really excel in, while keeping in mind that correlation doesn’t imply causation:
- It will make your developers happy to write less elaborate wordy boilerplate code
- Writing less boilerplate code usually results in writing more human readable and elegant code (it has been said before that code should be human readable first and just coincidentally interpreted by a machine)
- More human readable code can improve maintainability, health, and longevity of the code base
- Maintainability can result in greater agility to output more business value
Mathematicians have been joking that they’ve known that functional programming rocks for a pretty long time now. How could they not? Functions are the premise of their craft. It is true they’ve been using Lisp, Sage, and Python for years. I remember my MCS professors telling us in the late 90′s and early 2000′s that we better learn why these languages are kick ass (all the while they were teaching us the principles of OOP with this new language called Java). In fact, I noticed the other day that the new course outlines for MCS students at UIC have plenty of functional programming aspects using Python and Lisp. Sure Python isn’t a purist’s functional language, but anything with support for closures will do. Joining the bandwagon, I am trying to get good with Clojure at the moment with the trusty Pragmatic Programming Clojure book at my side. I am not going to lie, it has been tough to wrap my head around this concept (but doesn’t that generally happen with anything outside your comfort zone?). I would be remiss if I didn’t mention Erlang or Haskell in the context of popular functional languages. I suppose I could of chosen either one of those. I felt like Clojure was a better fit for me since it runs on the JVM, it’s dynamic, and the application of my learnings would be easier to integrate at work. So I have written fewer lines of code and as a result things are just concise. I am not sitting there worrying about immutability and concurrency they are just the fruits of my labor. I hope to extract some of the cool ideas out of the O’Reilly Collective Intelligence book and write them in Clojure.
I’m definitely stoked about the future with these languages. There is certainly so many possibilities and cool things to come. So the question is what will you be doing with these languages?
JRuby, ActiveRecord, JDBC to SQL Server
I recently had to figure out a good way to export data in XML form from a SQL Server database. I searched high and low for a good ActiveRecord adapter written in pure Ruby to talk to SQL Server. Unfortunately, the setup and overhead to get the right ODBC driver, DSN configs, and all those funky libraries to work properly on any *Nix-based machine were adding up way too quickly and complicating matters. So back to the drawing board.
RESTful service from .NET – no
Way too much work for such a simple task that only runs but once a week. Beside anything Microsoft is my nemesis and I am not even going to put my toe in that water.
SQL Server bcp export – no.
The bottom line – writing code in your database is always bad news. Sure the bcp export is the quick and dirty, but it might be too quick and dirty. It can make upgrades and migrations almost impossible. Just think how difficult it would be to migrate from SQL Server to say MySQL if the use of the bcp utility compounds over time. More importantly, how do you test it?
JDBC – yes!
Really? I was kind of shocked to learn that Microsoft jumped on the Java bandwagon and wrote a JDBC adapter. Woo-hoo! Wait…I don’t want to write a bunch of junky DAO’s in Java.
Enter – my good friends JRuby and ActiveRecord.
I can write sweet sugary Ruby code while utilizing the power of any or all of the existing Java libraries – which so happens to include JDBC!
So in order to glue this together it is quite simple.
- First install JRuby, it’s simple and there are 2 million blog posts about how to do this, all you need is Java pre-installed on your machine. Download it here from here.
- jruby -S gem install activerecord
- jruby -S gem install activerecord-jdbc-adapter
- Download the SQL Server JDBC driver JAR, I recommend getting version 2 or higher
- activerecord-jdbc-adapter is a nifty JRuby specific gem that acts as an adapter for ActiveRecord to speak JDBC (yet another thanks to Nick Sieger).
Once your have these things installed you can write a simple Ruby class to establish the connection and define any number of ActiveRecord classes to map to the tables you’re after. Here is a small snippet on how easy it is to connect to SQL Server using this technique.
#assuming this file is inline with your sqljdbc.jar or just put it into your $JRUBY_HOME/lib directory require 'rubygems' require 'active_record' require 'active_record/connection_adapters/jdbc_adapter' require 'sqljdbc.jar' config = {:url => "jdbc:sqlserver://localhost;databaseName=sucky_sqlserver_db", :adapter => "jdbc", :username => "user", :password => "pass"} ActiveRecord::Base.establish_connection( config ) class Person < ActiveRecord::Base; end people = Person.find(:all) ActiveRecord::Base.clear_active_connections! file = File.new("my_xml.xml", "w") file.write(people.to_xml) file.close
Approximately 10 lines of actual code and you’re done. It can’t be done any more elegant or simple than that. Here is the really beauty part, you can actually test your “script”. Use RSpec or TestUnit, but it is tested! Let cron or whatever scheduling mechanism of your choice run your script with confidence 
Rails 2.3.3 to 2.3.5 and Jruby 1.4 Upgrade Notes
Rails upgrade notes:
1.) Rails now has seeding functionality and along with it comes a new task, db:seed. If you use the seed_fu gem be aware that your db:seed call that worked with the gem is now executing the Rails version of db:seed. You will need to call rake db:seed_fu to get the gem version to work.
2.) ActiveSupport::JSON::ParseError no longer exists, so be sure to use ActiveSupport::JSON.parse_error.
3.) Update your rspec and rspec-rails gems to 1.3.x.
4.) Update your rack gem from 1.0.0 to 1.0.1
5.) Rails 2.3.5 works with the RailsXss plugin, in Rails 3 escaping content in erb will default, but if you want to ensure your site isn’t at risk of XSS, make sure you do this install.
Jruby upgrade notes:
If you are using Jruby < 1.4 and you use the net/http library, you better upgrade soon. We were having all sorts of problems with threading and exorbitantly long running requests. There were several bug fixes around the open and read timeout functionality in Jruby 1.4. Now network requests will timeout properly according to your open and read timeout settings.
jruby-quartz 1.1 released
Update: jruby-quartz is a gem at http://rubygems.org/gems/jruby-quartz
I just released jruby-quartz 1.1 on github. Notable changes include support for programmatically firing a job from the base job scheduler instead of relying solely on the scheduled job pool. As a side note, I just realized that github has temporarily stopped building gems since they’ve moved to Rackspace. So if you’re looking to use gem install, you are out of luck until they re-write that system.
MySQL fix for activerecord-jdbc-adapter 0.9.2
About 2 months back I was working on getting a db dump on my current project. I noticed a bunch of the primary keys were missing from tables in the dump file. Irked, I observed that many of tables we hook up to have residual Java Hibernate-isms with non-standard primary keys, basically not ‘id’.
After some digging I found a little problem with activerecord-jdbc-adapter, so I submitted a patch. The good news is that my patch has been included in the latest release. Thanks to Nick Sieger and the gang for including it.
== 0.9.2- The main, highly awaited fix for this release is a solution to therake db:create/db:drop issue. The main change is a new 'jdbc' railsgenerator that should be run once to prepare a Rails application touse JDBC. The upside of this generator is that you no longer willneed to alter database.yml for JDBC. See the README.txt for details.- Cleanup and reconnect if errors occur during begin/rollback(Jean-Dominique Morani, Christian Seiler) ...- Fix for mysql tables with non standard primary keys such that the schema dump is correct (Nick Zalabak)
Follow me on Twitter
My github repository
My LinkedIn Profile