One of the main advantages of Ruby’s growing community, is the speed at which exciting news pops up. This post briefly covers must-read highlights for new developments in the Ruby and Rails communities throughout the past week. I’ll attempt to repeat a “This Week in Ruby” post approximately every week, so feel free to follow along by subscribing to my feed.
Rails 2
Craig Webster published the first part of an easy to follow tutorial entitled Getting Started with Rails 2.0. The nice thing is that it also covers version control through Git, which is becoming extremely common in the Ruby/Rails community. Speaking of trends, a study by Gartner predicts that the Ruby language will reach 4 million programmers within the next 5 years. Numbers that would definitely position Ruby as a mainstream programming language. Incidentally, Obie Fernandez published an interesting survey of major corporations and large companies which are embracing Ruby on Rails. A very impressive list that is destined to grow quickly as Ruby’s implementation and ecosystem improve.
The official Rails blog has a post about a few changes in the core Rails team which brings the number of hackers down to 6, and establishes a Core alumni group of “retired” Rails core programmers. The small team seems to be busy, as Rails 2.1 is about to be released with some new exciting features, such as migrations based on UTC timestamp, named_scope, gems as plugins and much more as outlined by this caboo.se post.
On the deployment side, there are a few exciting happenings. Apple has published the third part of their tutorial, titled Deploying Rails Applications on Mac OS X Leopard. HighScalability.com has an article about an incredible service offered by Heroku that offers one-click, hassle free, cloud computing based Rails deployment. Their service is still in beta, and takes advantage of Amazon web services, but from what I’ve seen so far their secure and scalable deployment is as easy as it gets and it’s going to be a welcomed addition to the deployment options available to Rails programmers. Even more interestingly, a Dutch company called Phusion put up a demo about their Passenger project. Phusion Passenger, aka mod_rails, is a module for Apache that will bring ease of deployment, stability and performance to Rails. The company claims that according to their tests, mod_rails should be slightly faster than using Apache+Mongrel, it handles Rails processes automatically by spawning them depending on the effective traffic, and they are working with the largest hosts in order to ensure real world performance and stability when under heavy loads.
James Golick continues his series of “Plugins I’ve Known and Loved”, this time covering Ultrasphinx, a plugin for the uber-fast search daemon Sphinx.
Nicolas Sanguinetti wrote a script, that attempts to speed up the process of setting up an empty Rails project. I don’t find the procedure particularly boring so I don’t plan to use it, but it might be useful to some people.
Ruby
Peter Cooper, of Ruby Inside, has an article about two re-implemenations of the Ruby language. They are both named Sapphire, adding further to the confusion. The first one is a real fork, which was apparently born from the author’s dissatisfaction with the current management of the MRI, and the desire to have better support for Windows along, of course, with extra features like Aspect Oriented Programming, Unicode, etc, etc… The second one appears to be a new language, a stripped down and “stricter” version of Ruby that is supposed to be more Smalltalk-like and would be running, at least in the beginning, on the .NET platform. They are both worth mentioning, but currently I honestly fail to get excited about them. Ruby has an implementation problem, not a design one, in my opinion. However, we’ll see what they are able to deliver. In my book, a good implementation of a Ruby like language would be far from being frowned upon.
Remaining in the field of new implementations, InfoQ has an article about a neat new addition called HotRuby which is able to execute opcodes generated by the Ruby 1.9 VM (aka YARV). HotRuby is an incomplete and tiny (40 KB) implementation, faster than Ruby 1.9, that runs on JavaScript and Flash.
For those interested in Ruby and compilers, Vidar Hokstad has published the first two parts of a tutorial called “Writing a compiler in Ruby bottom up” (part 1 and part 2). Even if you are not into compilers, it’s a rather interesting read.
Sun reaffirmed their commitment to Ruby this week, by announcing the Ruby Development Center on the Sun Developer Network. I like Sun’s serious efforts and fast paced development of both JRuby and NetBeans (whose 6.1 beta is now out).
A new project hit the frontpage of programming.reddit.com: StrokeDB. Odd name, I know, but if you are interested in CouchDB, you may also take an in-depth look at StrokeDB. It’s a project that sounds rather promising if properly implemented. In their own words: “StrokeDB is an embeddable distributed document database written in Ruby. It is schema-free, it scales infinitely, it even tracks revisions and perfectly integrates with Ruby applications.”. The developers had a talk at EURUKO 2008, the European Ruby conference that took place this past weekend. Videos from the conference are not up yet, but meanwhile you can equally enjoy the videos and slides from MountainWest RubyConf 2008 on ConFreaks, which has published a talk by Evan Phoenix and Ezra Zygmuntowicz, respectively about Rubinius and Merb.
Finally, last week I spotted a bug that made Ruby 1.9 (built from trunk) significantly slower than Ruby 1.8. After a bit of investigation I was able to single out that the problem concerned Mac OS X only. With some testing by Chris Shea, the exact culprit revision was isolated and the core team has already worked on a fix. It was a very prompt and impressive response by Matz and his team.
RubyGems
Eric Hodel has announced the release of RubyGems 1.1.0. Aside from bugfixes and a couple of minor features, the most welcomed improvement is a significant speed boost that makes the tool faster. If you’d like to hear Eric talk about Rubygems and his involvement with the Ruby community, this week InfoQ published an interview with him (the interview itself is from RubyConf 2007 though).
This is my first episode of “This Week in Ruby” so feel free to provide feedback if you found it useful or if you have suggestions for improving it. Thank you for reading!
Get more stuff like this
Subscribe to my mailing list to receive similar updates about programming.
Thank you for subscribing. Please check your email to confirm your subscription.
Something went wrong.
Thanks for the mention of Sapphire. It’s hard to get across the features of a new language before we have a working implementation. What I’d like to make clear, though, is that Sapphire’s is not really a ‘stripped down’ Ruby – though its syntax might be described that way. We like the Ruby syntax and decided to model Sapphire’s syntax pretty closely on that of Ruby. However, the whole impetus of the language is quite different.
The main focus of Sapphire is to provide the ability to write verifiably correct code whose meaning and runtime behaviour can be checked incrementally during the development process. While it is a fully dynamic language, it is intended less to compete with Ruby than to provide a real alternative to languages such as C#, VB or Delphi. Unlike those languages it will be 100% OOP with features such as strict encapsulation/data-hiding and a number of ‘safe programming’ capabilities such as ‘class extension by consent’, blocks as first-class objects and ‘type assertions’ (but not enforced type declarations) to trap type and range violations at designtime.
In our view, Ruby excels at fluid and expressive dynamic programming for applications such as Rails and we have no interest in competing in that area. But Ruby is probably not the first choice of language for developing rock-solid, mission-critical applications (one of the developers of Sapphire has a background in developing real-time banking systems – suffice to say, Ruby is not much used for those!) – and that’s where Sapphire come in…
We’ve written a bit more about the design and grammar of Sapphire on the blog. These articles will give you a bit more background…
http://www.sapphiresteel.com/The-Sapphire-Programming-Language
http://www.sapphiresteel.com/The-Sapphire-Programming-Language,251
best wishes
Huw
SapphireSteel Software
Ruby and Rails In Visual Studio
http://www.sapphiresteel.com
Well done. Very readable yet thorough reporting. Looking forward to the next in the series.
@Huw
Thanks for stopping by and adding more details about the language you’re designing. Positioned as an alternative to C# that happens to be somewhat inspired by Ruby, as opposed to a reimplementation of Ruby, it makes a lot of sense. Things like Windows GUI development, Silverlight, and the integration with existing .NET codebases make the project very appealing. If you need an early beta tester, please get in touch with me.
@Roderick
Thanks a lot. That’s encouraging to hear. 🙂
I guess I can sort of understand Huw’s project, though why not back IronRuby and do optional typing (like Charles Nutter is doing for Duby/JRuby)?
Daniel Berger’s project makes no sense to me…why expend the effort? Why not back and contribute to the rubinius project (which I believe will become the defacto Ruby implementation).
@Mnmer: “why not back IronRuby and do optional typing”
The two projects are not mutually exclusive 😉
We are already backing IronRuby and have a free IronRuby IDE (available in alpha now) with editing, project management, visual form designer etc.
http://www.sapphiresteel.com/Ruby-In-Steel-For-IronRuby
And we are also working on an extended ‘type assertion’ feature for Ruby. In fact our current (Matz) Ruby IDE lets you assert types in comment blocks. At the moment, this is used principally to provide additional IntelliSense in those cases where actual types cannot be inferred from the code. However, we plan to build in more features for type assertions to allow programmers to check actual against expected types in Ruby code so that type assertions will be used for testing, debugging and code verification without altering the meaning of the Ruby code itself.
In short, we are not deserting standard Ruby. And we are actively supporting IronRuby (in fact, we also support JRuby – we have a JRuby visual debugger). But Sapphire is being designed as a significantly different language from Ruby and it has different priorities. In order to achieve the goals we’ve set ourselves, we felt it correct to take full control over the design of Sapphire ‘from the ground up’ rather than trying to force Ruby to be something that it is not ‘by nature’.
best wishes
Huw
Already looking forward to next weeks installment 🙂
Nice! Looking forward to another edition next week.
I enjoyed it, which surprised me. I enjoy your articles, but I hadn’t expected to enjoy a ‘week in review’ type article. However, I had evidently missed a few things, and, of course, it was well done. Thanks.
Great writeup. Please keep it up. This is such a great time saver.
Thanks,
Mark
As an amateur Ruby programmer – always in major learning mode – I found this to be a very interesting read. I much appreciate being able to benefit from your survey of a broad range of sources – something I cannot hope to do. I’ll be a regular reader.