Archive for the ‘development’ Category
Ruby is the R in Rails
I would love to have attended RailsConf 2008 but alas you can only do so much in a day. Although this was a Rails conference, it seems that this year there was less talk about Rails and more about Ruby. This is hardly surprising really given that Rails is just a web framework. Yep, Rails is just a web framework. And just like any other web framework, its serves as a gateway from the web and into your enterprise. Now, after a year of doing Rails, you’re basically done. Coasting. Yes, there are tips and tricks you can pick up along the way but for all intense purposes you’ve got the badge. You’re done. You know Rails.
Now the more pressing problems and prickly questions around the enterprise, integration and scalability need to be addressed and this is where Ruby is amore compelling story. In fact, things in the Ruby space are really moving forward at break neck speed. It’s not surprising really, given the relatively few Ruby conferences there are each year, that Ruby gets to play out and steal some of Rail’s thunder at RailConf.
So what is going on in Ruby space that’s so interesting?
Ruby Implementations - Where integration is Key
First up there’s JRuby. This is a 100% pure Java implementation of the Ruby programming language. And right there is JRuby’s sweet spot. The ability to seamlessly integrate with the Java platform through Ruby is a big win for some. So running Rails under JRuby and using it as a web gateway into your Java enterprise, together with the ability to leverage mature/known Java tools and the free performance hikes that accompany it has been a very appealing proposition to some. A prime example being the ThoughtWorks Mingle product. Also, having access to the abstract syntax tree which can be shared between multiple Ruby runtimes hosted within the same JVM process is pretty neat and a highly efficient way of managing memory.
MacRuby! As a Mac User I’m excited by this implementation of Ruby 1.9. With MacRuby you can write Mac OS X applications in Ruby without the performance hit typically attributed to standard Ruby and Ruby Cocoa. MacRuby is native to Mac OS X core technologies. Damned quick with all the elegance of Ruby to boot.
IronRuby, backed my Microsoft and sits on top of its Dynamic Language Runtime (check out John Lam’s talk on the DLR), is a .NET implemention of Ruby. IronRuby enables Ruby programmers seamlessly integrate with the .NET platform, in much the same way that JRuby does on the Java platform. Ruby.NET is open source .NET implementation that does not have the same pull as IronRuby.
In fact, the main draw for Ruby developers that target JRuby, MacRuby, Ruby.NET or IronRuby is integration with the Java, Mac OS X or .NET plaforms respectively.
Ruby implementations - Standards are key
Let’s park integration. Let’s focus upon Ruby developers building Ruby apps with an Ruby-oriented environment. Both Rubinius (a spec led Ruby implementation) and MRI/YARV (currently the official Ruby) are competing VMs for running Ruby applications. Everyone started with Matzs Ruby Interpreter (MRI) but now we have many more alternatives. The Yet Another Ruby VM (YARV) project has officially merged into MRI as of May 2008 to combine the best of both worlds to enhance the official Ruby implementation.
RubySpec
But unlike Smalltalk that was really killed by competing implementations, the Ruby community, through RubySpec are collaborating on standards and competing on implementation. This is good. No, hold up, this is great! This will hopefully provide more choice to the developers to select the appropriate Ruby implementation that best fits their solution requirements. Hopefully, this will hold the community together and keep everyone pulling in the same direction. So far, that appears to be the case…
..but then there was Ruby for Scale - Maglev
Maglev is a Ruby implementation built on top of Gemstone’s VM that is written in Smalltalk. Chad Fowler goes into the why and when you would choose to use this Ruby implementation other the others. But the problem is very few people have access to Maglev. It promises the world and come on guys its time to show me the money! The community has seen is a presentation. A damned fine presentation I’m told but Charles Nutter of JRuby is not convinced and other people are already dismissing outright Maglev’s claim to scale. 100 times performance improvement is a big claim. One to watch I guess.
And Finally!
Take a look at the following code snippet:
#!/usr/local/bin/ruby require 'scalability' # your code
Now the Twitter guys must be get this all the time. Twitter is growing in size and its architecture will mature and incorporate different technologies I’m sure that best fits their current problems. Time will time. But to say its Ruby’s fault is a little naive at best. That said, wouldn’t it be just great if only you could include scalability in Ruby applications, Java apps, .NET apps, or whatever the platform.
Now, that would be awesome. But the simple fact is you can’t include it, you have design it in. Boooooo say the crowd. Kill joy chant the business. But unfortunately, like so many things in the software industry, you have to go the long way round (read as experience) to get desired results. Because there are no short cuts (read as foolish hacks, or inexperience) on the road to scalability…only blood, sweat and tears! But there are leg ups, tools and techniques and people to assist, but that’s any story for another day…
Busy Java Developer: Stop, Look, Listen and Live
Back in the seventies, the “Stop, Look, Listen and Live” UK campaign was used to teach kids road safety. Funnily enough, the Green Cross Code Man, who became the face of this road awareness campaign, went on to become Darth Vader!
It is now time for Java Developers to Stop, Look, Listen and Live! The climate is changing. Java the language is entering middle age. Java is not the first language that developers are picking up. These days when I talk to young non-Microsoft developers, a lot of them don’t know Java and have no plans to learn it either. Dynamic and functional languages are on the rise. The web IS a viable platform for business. More and more applications are moving out of datacentres and into the clouds. Since Java 1.4, the interest shown by experienced Java developers suggests that are not focussing on Java the language. A lot of Java developers have not developed against Java 5. Even less against Java 6. As a Java developer, do you know what’s coming in Java 7? Do you care? Do you, Mr. Busy Java Developer, really care? If so, here’s a couple of things I reckon you should, if you haven’t already done so, think about this year as a Java developer.
The Three Gees: Groovy, Grails and Gant. Groovy is a dynamic language for the Java Platform. In short, building on top of Java, it injects a degree of flexibility in the way Java-based software systems are created and continue to evolve. As a Java developer, you are seriously missing a trick if you do not have Groovy in your toolbox.
Grails is damned fine web framework. The Grails/Groovy pairing brings the same advantages to the table that Rails/Ruby does. Now I’m a big fan of Ruby, for the busy Java developer I think that JRuby/Rails/Ruby is more of a distraction than the Grails/Groovy option. Groovy’s support for Java frameworks such as Spring and Hibernate are too good to ignore. Also, if you already know Groovy, Grails is a no brainer. In fact, at the Java Web Frameworks Tournament 2008, Grails made it into the semi-finals. Not bad…JRuby on Rails won 
Finally, we move onto Gant. Which is like Ant but the language is Groovy not XML. With Gant plugins for Maven 2, your build options are trivial. The only real contender to Gant is Buildr which is a damned fine Ruby based build system for Java applications. Again, the trade-off for simplicity in the Busy Java Devleoper life is, if you keep to the Three Gees, you’re covered. Otherwise, you have another build system to learn and require all your developers to know Ruby.
Scala: This is a newbie on the language scene that has been bubbling away since 2001. However, like Groovy it integrates with Java beautifully and provides a nice mix of object-oriented and functional to bring yet more options for solving a differ class of problems for Java developers. For the Microsoft people out here, Scala implementations also integrate with the .NET platform. In this era of distributed computing, scalability and component based development Scala arms the Java Platform with some great tools for addressing these problems. And again, for the Busy Java Developer whose bread and butter is the Java Platform, you cannot afford not to be aware of how Scala may fit into your world. Word of warning, Scala is not for the lazy or faint hearted. You need to put some time into this language before you start reaping the benefits!
Spring Source Application Platform: EJB 3.0 is alive and kicking. EJB 3.0 is a great platform. EJB 3.0 is not future. EJB 3.0 will never be mainstream. After the non-sense of EJB 1.0. The constant public pounding by Roger Sessions @ ObjectWatch (Poor Ed Roman). The rather feeble attempt of EJB 2.0 to rectify the shortcomings of EJB 1.0. The industry couldn’t and didn’t wait for EJB 3.0. Now if we could wind back the clock say 24 months and re-branded EJB 3.0 as HellFire 1.0, there would be no such thing as Spring Source Application Platform. EJB 2.0 created the market and effectively stepped out the race by giving us such long lead times. The guys at Spring have capitalised on this massive window of opportunity and have produced something pretty cool. However, not all is great. They have rather naughtily upset the OSGi people, in particular Peter Kriens. Hopefully, they’ll change fall into line for the good of the community.
I like your Bundle!: This leads us nicely onto OSGi. If you haven’t heard about this as a Java developer, where have been? Please, please, please, add it to your list of things for this year to pick up. It a must. Have you never wondered how Eclipse manages the lifecycle of its components? How you can upgrade stuff easily and without a restart. No messy classloaders. Define, package, deploy, stop/start and manage your components. Side-by-side deployments of versioned components. Essential for 24/7 Java applications. This is OSGi. The guys at Spring have created a Bundle Repository that makes the use of OSGi simple.
Domain This, Domain That: Not essential but an important thing to know about. Domain Models, Domain Driven Design (DDD) and Domain Specific Languages (DSLs). When you start thinking about the Three Gees, Scala, OSGi and so on, how can you do that without a domain model. The DDD is an approach to domain modeling, where DSLs are way to facilitate human to machine communication that invariably operate within the context of a domain.
Right, I’m exhausted. Everyone gets busy. It’s easy to be left in the trenches and not have time to step back and take a long look at what is going on around you. I’ve suggested a couple of things that I think are useful. You probably have more. If so, please leave a comment…
The Beauty of Ruby
I’m more of a fan of Ruby than Rails. Sure Rails is good, but Ruby is way better. I’m trying to put some time aside to learn a little bit of Polish. As a result, I was a frequent visitor to www.dict.pl. After a couple of days of using this, I’d had enough. Too slow. Too restrictive. Too crap! Time to turn this around.
I wrote a simple English->Polish translator application in Ruby. It does all the usual stuff such as add new words, search for words in either language, and maintain the words in named bundles. The challenge I set myself as a novice Ruby programmer was to implement the core set of features knowing that the code would be fat and not very pretty. I then aggressively sort to refactor the code to reduce its size, whilst increasing the feature set.
The core translation engine started out as 120 lines of code with just the add new word feature. Since then I’ve learnt a lot about how to structure Ruby programs and the effective use of closures, iterators, containers and yaml. In the process, I’ve added search, display and bi-directional features to the translation engine and reduced the lines of code to 114.
I have a new found respect for Ruby the Language. It is the most expressive language I played within in a long time. Also, contrary to what many non-Ruby programmers tell me, Ruby is readable when written well. Unfortunately, on my travels through the web, I have seen some really awful Ruby code and this stuff is truly poisonous. Bad Ruby is completely unfathomable. A ticking time bomb. However, well-written is Ruby is sublime. I truly believe that there are no shades of grey here
What’s on your Stack?
Yesterday I attended a talk on DSLs and towards the end of it we started looking at external DSLs. I’m going to skip over that topic for now, but as a result tutorial headed by Rebecca Parsons moved into the area of lexers, grammars, parsers, language design and a little bit of compiler theory. Good stuff.
What became abundantly clear to me is that although the room was jammed packed full of smart people, only about half of us knew what lexers and grammars were. This got me thinking about assumed knowledge. I’d also assumed that the majority of application developers knew at least Java or .NET. Not so. There were a lot of attendees that were pure Ruby, Perl or another.
Looking back, my language stack consists of 5 years of assembler/C, 10 years of C++, and 10 years of Java, where there was gradual hand-over from one language to the next. On the way, I dabbled in Smalltalk, Eiffel, ML, Prolog, and more seriously in .NET and Ruby. The very nature of the language meant that I needed to know about compilers and language design. Also, as part of my thesis I had to swallow context free grammars and chomsky, to write a header file parser that performed the static design analysis of large C++ systems. But the only reason I did this is because I had to, and the tools available to me then were yacc(grammar)/lex(lexical analysis).
Now, if you don’t use these types of languages and parse very simple grammars, there is no need to get your hands dirty. However, Rebecca was spot on when she pointed out that tools such as yacc/lex and to a lesser degree antlr, have received bad press as being archaic, blunt tools with magical powers that are wielded by the chosen few. In reality, there hasn’t been much cause for the masses to use them. Will the drive for external DSLs where you want to create your own language make them more popular? I doubt it. I think people will still opt for internal DSLs that are written essentially in the host language (e.g. rSpec, JMock, and so on).
But I have to realise now that those guys/gals born in the eighties and heaven forbid the nineties, are operating off a completely different programming stack. Their minds are in different places and their toolset is somewhat orthogonal to mine.
Strange. I suddenly got older very fast…
Technorati Tags: dsl
QCon 2008 : Domain Specific Languages
Today I spent my first day at QCon 2008 in a room with Martin Fowler, Neal Ford and Rebecca Parsons presenting their position on Domain Specific Languages, the results I’m sure will end up in a book.
For me, having sat through the tutorial, the headline moments for me were:
- Understanding what the differences are between an internal and external DSL
- Knowing when to select one over the other
- There is a lot of unknowns surrounding the whole area of DSLs, and what Fowler and Co are doing are exploring the problem space and proposing options.
- Some languages, Ruby, Groovy, Scala lend themselves more easily to writing readable internal DSLs
- Other languages, such as C# and Java, tend to pollute their DSLs with syntactical noise in the form of {}, “” and ()
- When the language is getting in your way, it’s time to more from internal to external
- DSLs are a layer on top of a framework that is used to setup and configure framework objects
- External DSLs free you from the constraints of a specific programming language but introduce an extra step in the form a parser generation code to your build
- There were a LOT of Ruby guys in the room, including the leads on rSpec, an internal DSL for Ruby testing
- The definition for DSLs is wide open for interpretation and a lot more will happen in the space over the coming months
- I need to do some more reading around the concept of a language workbenches. Very interesting stuff.
When do you code review?
I stumbled across this article in my google reader on code reviews that I found quite interesting. All too often code reviews just don’t happen software projects. Whether they are forgotten about, or there is no company procedure for doing them, or no time is set aside to perform them, if no-one makes them happen, code reviews will not happen. To me that is a great shame, because code reviews are an wonderful place to learn about others in your team and to explore your problem space through the eyes of others. When done right, those teams that hold code reviews, would never dream of letting them accidentally fall of the project plan. Code reviews are an essential part of the development (yours, the teams and of course the product’s) process.
So when is a good time to hold a code review? Weekly, after every sprint/iteration, monthly? The regimented, thou shalt have a code review every X, has never worked for me. You cannot predict what will be going on in a project and shoe-horning a code review is just counter-productive in the extreme. Typically, you should always hold your first code review when you get to a place when you have something to take about. In the article, the author says this is 20% through the build. Maybe. But I think this depends on the project, so its a team gut feel. It’s got to be early enough for changes to made, glaring errors and/or omissions to be highlighted but far enough through to warrant the time and effort that needs to be invested to make it worthwhile.
After the first review, its a judgement call, as to whether another code review is needed. This is where certain design quality and product metrics can be used to help make that call. Are the number of broken builds increasing? Is the test coverage going down? Are the number of dependencies between packages increasing? Is the team producing more complex and/or large methods? Is the source not conforming with pre-defined standards. If so, maybe its time for a code review.
Oh, and before the pure agilists start jumping all over this and say code reviews, isn’t that covered by pair programming throughout. Well yes and no. I think a code review, at a team, rather than just at pair level, is a very important exercise that should not be replaced by pair programming.
Heroku!
I’ve found Heroku!
Heroku allows me to build and deploy Rails applications. It couldn’t have happened at a better time for me because my current provider doesn’t give me what I need re. Ruby and Rails. So I took the following steps:
1) Registered with Heroku
2) When I got my sign-up email, I zipped up my Rails app (removing the .svn directories, tmp and log folders)
3) Uploaded to Heroku
4) Then run it
The application is a re-write of http://www.clevegibbon.com and can be found here http://clevegibbon.heroku.com. I’ll evolve it there.
Heroku is novel. Stunningly simple. Very expressive.
Sweet!