I now have a software company to run and spend much of my time actually writing software instead of writing about it. Even so, I haven’t completely given up writing programming tutorials. A while ago, I released a free eBook called The Little Book Of Ruby, which covers the essential features of Ruby programming in ten chapters.

I am now going through the final revision of a much bigger book called, simple, The Book Of Ruby. In over 400 pages and 20 chapters this will take you from ‘Hello world’ right into some of the inner details of Ruby metaprogramming, threads, blocks and iterators, Rails, regular expressions and all manner of other things besides. I am releasing the book for free and it will go online one chapter at a time (the first draft of the entire book already exists but I want to revise and check each chapter before releasing it) along with all the source code for each example program.

Whether or not you’ve followed any of my tutorials before, I hope you may find something of interest in this latest one.

Links...
 Introduction To The Book Of Ruby
 The Book Of Ruby
 The Little Book Of Ruby

Borland first announced its intention to sell of the Developer Tools group in February 2006 but, in a surprising twist of events, decided to hang onto them in November of the same year. Ever since that date there has been widespread speculation about the future of the group. That speculation has today come to an end with Borland’s announcement of:

”...a definitive agreement to sell the assets of its individual developer tools unit, CodeGear, to Embarcadero Technologies. The purchase price for CodeGear is expected to be approximately $23 million. Borland will also retain CodeGear’s accounts receivables with an approximate value of an additional $7 million. The transaction is expected to close by June 30, 2008.”

Borland’s announcement

On its web site, Embarcadero states :

“Today, we are very pleased to announce that Embarcadero Technologies© has signed a definitive agreement to acquire CodeGear™ from Borland© Software Corporation. The combined company will operate as a private company with over $100MM in annual revenue and more than 500 employees worldwide. We expect this transaction to close by June 30, 2008. This is an important milestone in the history of software and database development.”

http://www.embarcadero.com/

...so, I was pleased to discover a new tool to help lost souls like me find our way around the new-style Office applications. Search Commands from Microsoft Office Labs is an add-in that “helps you find commands, options, wizards, and galleries in Microsoft Office 2007 Word, Excel and PowerPoint. Just type what you’re looking for in your own words and click the command you need.”

So, for example, if you can’t find the word counter, you can go to the Search Commands tab on the ribbon, enter the text ‘word count’ and - as you are typing - the ribbon itself changes before your very eyes, adding ‘Show Word Count’ and ‘Insert Word Count’ buttons. It’s all very clever and very impressive.

Even so, I’d really prefer just to have the option of displaying all the good old-fashioned menu system. I already knew where to find things on that even without a special searching tool...

 Download from: http://www.officelabs.com/projects/searchcommands/

Well, if you can’t find one, there really is no option but to write one yourself. That, fundamentally, was the impetus behind the creation of my company, SapphireSteel Software, and our Visual Studio-hosted IDE, Ruby In Steel.

Before going on, let me put all my cards on the table. I’ve designed and programmed a fair bit of Ruby In Steel myself and I admit to being totally and utterly biased. Today we launched a new visual design environment for Ruby On Rails but I’m not going to review it here - even I am not that shameless! What I will do is tell you a bit about what we have been doing and why we are so utterly determined to make the darn’ thing visual - a heck of a sight more visual than any other Ruby IDE on the planet.

Ruby programming has, up to now, tended to be a code-centric affair. You write code in an editor then you go to a command prompt and you run the code in an interpreter. I did that whole editor-and-command-prompt thing back in the ‘80s. It’s a style of coding which is now so ancient that, to a new generation of programmers, it seems modern again. But not to me. Having put the command line behind me twenty years ago, I feel not the slightest inclination to go back to it now.

Visual Ruby...?

But how do you give a language such as Ruby a really visual makeover? To date, we’ve approached this from several angles. First, we created a cross-language-linking component, The Ruby Connector, which lets .NET programmers write hybrid programs that combine elements of a .NET language such as C#, VB.NET or Chrome with regular Ruby. This also solves the visual interface problem by letting the programmer do all the front-end design in .NET while running Ruby at the back end.

Hybrid programs like this have their uses but they are still some way short of the complete drag-drop-and-code way of working that is second nature to an old Delphi programmer like me. This part of the equation will eventually be solved when Microsoft releases IronRuby - a .NET implementation of the Ruby language running on the Dynamic language Runtime.

We’ve already released a free IronRuby version of Ruby in Steel complete with a form designer. Unfortunately, this isn’t production-ready yet since IronRuby itself is still in the alpha stage of development. As IronRuby develops, we will continue to enhance our IronRuby IDE. In the long term, this really could turn into a Ruby alternative to Delphi or VB.

Visual Rails...

The problems of visual design for Ruby On Rails are rather different. Rails is not used to create desktop applications so the ‘form-design’ way of working is not relevant. Rails is used to create database-driven web applications. It links together the data (the ‘Model’) with the programming logic (the ‘Controller’) and the visual interface (the ‘View’).

By default, Rails Views are defined in sets of template files which contain a mixture of HTML mark-up with Ruby program code. A single web page may be defined by multiple templates - typically comprising at least a Layout (repeating elements such as headers and menus), a View (the elements of a specific page such as data-entry) and one or more ‘Partials’ (items such as submission forms).

The Ruby code in these templates is executed by Rails and multiple templates may be combined to form a single HTML page at runtime. However, at design time, the final layout of the page is not available for the simple reason that, while all those fragmented HTML/Embedded Ruby templates may mean something to Rails, they don’t mean much to a web design tool such as the Visual Studio Designer or Adobe Dreamweaver.

To get around this limitation we have created a visual design environment that lets you work with fully formed HTML pages at design time. In order to do this we have had not only to work out how to combine all the various Rails templates that define a single page but also how to translate embedded Ruby into HTML and back again.

This has been a far more complex task than we initially anticipated and the environment (the Visual Rails Workbench) has taken about a year to complete. I think it’s been worth the effort though. The end result is that you can now do real drag-and-drop design for Rails: you can drag a control from a toolbar, drop it onto a web page, resize or move it with the mouse and set its properties in the Property panel.

I know there are those people who will think this is the work of the devil and that all good Rails programmers should stick with plain text editors and command prompts. That’s fine. Each to his own. But as far as I am concerned, the more ‘visual’ the better...

Dermot and I have been planning Sapphire for several years. In fact, our intention to create this language determined the name of our development company, SapphireSteel Software. We created the Steel IDE for Visual Studio which, in its present incarnation, provides editing, debugging and design tools for the Ruby language (and its variants, JRuby and IronRuby). That product is called Ruby In Steel and, from the very earliest stages of its development, it was our plan to release, at a later stage, a different product called Sapphire In Steel. The development cycle that will culminate in that product is just beginning. As the Sapphire language does not currently exist (except in our minds), we have to create it!

Designing and implementing a programming language is a seductively appealing project. But there are already countless programming languages so, in order to justify a new one, there had better be a good reason!

In the case of Sapphire, our reason is Ruby. The Ruby language is great fun to use and has many powerful capabilities. It has a nice un-C-like syntax, a decent implementation of object orientation and, moreover, it has ‘dynamic’ capabilities which allow you to create and modify objects without all the rigmarole of typings and coercions which you may be familiar with from other languages. It also lets you modify programs at runtime - doing anything from creating new objects to defining new classes! All wonderful stuff and used to tremendous effect in web frameworks such as the well-known Rails (and some less well-known ones such as Merb, Waves and Ramaze).

But the consequence of this power is complexity and, potentially, problems of long-term maintainability. A common question posed by programmers coming to Ruby from some other language such as Java or C# is: but how can I check that the types my code is expecting are the types it actually gets? This is a serious question to which there is no real answer. Explaining that Ruby ‘duck types’ variables (it infers what they are at any given time) is not a satisfactory answer to the question. Running test suites to verify the program after it is written is useful but could be seen as ‘disaster recovery’ rather than ‘disaster avoidance’. This issue (Ruby’s free and easy approach to typing) is, I suspect, one reason why so many people dip into Ruby then move rapidly on to some other ‘safer’, more predictable, programming language.

It would, of course, be possible to create a version of Ruby with strictly enforced type declarations. But that would be so far from the spirit of Ruby - it would sacrifice so much of the power of the language - that you might just as well create yet another C or Pascal-like language and have done with it.

In Sapphire we decided to take a different approach. We felt we wanted to keep the essence of Ruby but pare down on its complexities. Where Ruby provides many alternative ways of doing the same thing, Sapphire provides one way. When Ruby introduces the possibility of confusion, say due to the differing precedence of nameless functions (‘blocks’) according to their delimiters, Sapphire removes the source of that confusion (in fact, it has just one set of block delimiters). And we are introducing ’type assertions’ which state the expected types and (optionally) warn if different types are found without enforcing those types.

I won’t go into all the other design decisions at this point. If you are interested, you will be able to read more on the SapphireSteel Software Developer’s Blog.

At any rate, whether or not you are interested in the Ruby and Sapphire languages, if you have ever wondered how you can create and implement your own language, Dermot’s series will show you how.

And to look on the pessimistic side, even if nobody (apart from you and us, that is) actually uses your (and our) language, well, by heck! it’ll be fun creating it anyhow... and that, frankly, is as good a reason as any for doing so.

The darn thing let me drag but it wouldn’t let me drop! I spent a happy hour trying to figure out what the heck I might be doing wrong. Was I expected to add controls in hand-crafted code, maybe? Nah, why would the Toolbox be there it that was the case? So maybe there was some obscure configuration property I had to set? Or could it be that Windows Vista was (once again) refusing to let me do some perfectly reasonable task because, for reasons of its own, it had decided I was an unfit person?

Anyway, just in case you’ve had this problem too, let me put your out of your misery. I eventually Googled down the answer in a Microsoft forum. These are the steps you have to take:

1. Exit Visual Studio
2. Navigate to your user profile directory for Visual Studio (this is found at %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\9.0)
3. Delete the TBD files found there (they are often hidden files)
4. Re-start Visual Studio and open your WPF application - the toolbox should be automatically rebuilt.

This fixed the problem for me. Not sure I would have worked this out without Google’s (and Microsoft’s) help, though. OK, so now I’ve started using the WPF designer, I have to say that my initial impressions are pretty positive. All it needs now is a snappier name. The web-specific subset of the WPF is called Silverlight. When this was in beta it was known as “Windows Presentation Foundation/Everywhere” but, fortunately, someone in Microsoft had a blinding flash of sanity and came up with the new name. Bizarrely, the WPF has a nice name while in beta (‘Avalon’) but was saddled with the hideous ‘Windows Presentation Foundation’ moniker upon release.

Microsoft is currently developing a version of the Ruby language called IronRuby to run on the Dynamic Language Runtime (DLR) for .NET. IronRuby is still in the pre-alpha stage so there are inescapable limitations on the kind of dedicated support we can offer in our IDE. Even so, I’m pleased to say that we today launched the first public alpha of Ruby In Steel for IronRuby. In addition to comprehensive editing support we also have the first and only drag and drop form designer for IronRuby.

If this is something that is of interest to you, grab yourself a free copy of Ruby In Steel For Iron Ruby here:

 http://www.sapphiresteel.com/Ruby-In-Steel-For-IronRuby

Metaprogramming is a powerful capability of Ruby. It describes the ability to treat data as code. So, for example, it is quite possible to evaluate a string at runtime such as “def x(y);puts(y.reverse);end” and end up with a completely new method called x bound into the program that is currently running!

Moreover, such methods can be bound into standard Ruby classes such as Array or even Object - the class from which all other classes descend - so that the entire behaviour of every single Ruby class can be changed on the fly as the program executes. You can, in a similar way, modify the behaviour of existing methods or even create entire new classes. This is great stuff and, when used with care, can be extremely powerful. Metaprogramming is, for example, used all over the place in the well-known Rails web framework for Ruby; it provides Rails with the ability to wire up data and evaluate Ruby code embedded into HTML during runtime.

However, this power comes at a price. One example quoted by Avdi Grimm is of a Rails plugin that dynamically modifies certain Rails classes such as ActiveRecord. He comments:

As a result of this implementation, it is tightly coupled to the inner workings of ActiveRecord. A small change to Rails and it could cease to work...

This rang a bell with me. I make no secret of the fact that I have always had considerable reservations about Ruby’s tolerance of encapsulation-breaking. In most respects, Ruby is as well-encapsulated as that most influential of Object Oriented programming languages, Smalltalk. Unlike many other OOP languages, Ruby and Smalltalk generally enforce data-hiding so that the variables inside an object cannot be accessed from outside unless you use specific methods to do so. But Ruby has exceptions to this rule. There are several ways in which you can bypass its data-hiding - and modifying the behaviour of existing classes ‘from the outside’ is perhaps the most egregious of these.

This, in fact, bypasses the most fundamental principle of object oriented programming: namely that the implementation details of an object are private to itself. The world of the program beyond the confines of that object should, therefore, never be reliant upon the implementation details of that object. The original author of the class defining the object should be confident that he can modify the code inside the class without his modifications having any effect on anyone else’s code. There should, in short, never be an occasion when a small change to a class in Rails, for example, should cause someone else’s code to cease to work - just so long as the Rails classes maintain the same interfaces (methods) through which other programmers can communicate with them.

By providing extreme self-modifying capabilities, Ruby necessarily gives people the ability to break encapsulation in the most profound way possible - by messing around with the internals of the fundamental classes. On the one hand, my instinct tells me this is bad and should not be allowed. On the other hand, I recognise that there are occasions when this is a very powerful capability and the Ruby language would be much diminished without it.

The only real way in which we can have the best of both worlds is, I suppose, by imposing some kind of self discipline. So-called monkeypatching should be regarded as a last resort - reserved only for very, very special circumstances. On the whole, the privacy of a class should be respected. If you need new behaviour you should define a new class as a descendant of an existing class.

But who is going to enforce this rule? In practice, nobody. If something can be done, it will be done - even though, in the long term, this may have a highly undesirable impact on program maintainability. In a commercial environment, where maintainability may be regarded as a primary goal, anything which has such as negative impact may be deliberately avoided as an enforced policy. But many of the programs written for Ruby have no commercial imperative. They are written as free contributions by people who are quite likely to have moved on to unrelated projects long before any maintainability problems come to the surface.

What the solution to this problem is I cannot say. That it is a problem, however, is, in my view, undeniable.

Huw Collingbourne is Technology Director at SapphireSteel Software, makers of the Ruby In Steel IDE for Ruby in Visual Studio.

Babbel is nice and friendly-looking and has a decent amount of ready-to-learn content to help you learn themed lists of vocabulary. It does this by showing pictures with words shown beneath while a native speaker pronounces them. You can use these to extend your German, French, Italian or Spanish. It doesn’t provide a full ‘course’ (like LiveMocha) however, so is best regarded as an addition to a traditional course rather than a replacement for it.

On Palabea you can learn a variety of languages - English, French, Italian, Hindi, Russian, Chinese and more. The learning content is not all ‘ready to run’, however. Instead, users can write or record material to help others studying their native language. The whole idea is very much ‘community based’ with learners and teachers encouraged to create self-help networks. I haven’t yet decided whether this will appeal to me in the long run. it’s worth trying out, though.

Others worth checking (but which I have not yet joined) include ITalki which is another self-help community and Mango Languages which provides lessons in Spanish, Russian, Greek, German, Mandarin Chinese, Japanese, Brazilian Portuguese, French, Italian and Polish. I’ll try these out soon. In the meantime, if any readers have recommendations of these or other language learning communities please let me know.