Antonio Cangiano’s book, Ruby on Rails for Microsoft Developers, is just such a book. I haven’t had a chance to grab a copy yet but I’ve had a browse on Amazon and it looks just the ticket for Ruby On Rails developers on the MS platform. I must confess that I am also pleased to note that it contains a few nice mentions of Ruby In Steel... ;-)

The bizarre thing is that an unauthorized copy will set you back about $66 (£40), and yet, as an eBook, The Little Book Of Ruby is Free! You can get a copy for $0 and, if you really want to print it out you can do so on your own printer. What you cannot do - what I do not permit you to do - is to bind your printouts and sell them. Anyone is welcome to make their own personal copy of The Little Book of Ruby for no cost whatsoever. But you are not allowed to sell it.

Incidentally, The Little book of Ruby only has 87 pages but if you want an even better bargain, you can get its big brother The Book Of Ruby, with well over 400 pages, at the same price - i.e. free. Once again, you may give away copies of the unmodified eBook but you are not allowed to charge for it. You may also print out copies for your personal use but you are not allowed to charge for those either.

Do not, in any circumstances, be tempted to buy a copy of one of these eBooks. We do not print them ourselves and we do not authorize anyone else to print them. Moreover, we specifically do not allow anyone to sell them. I did the work in writing them and I chose not to make a profit from selling them. Perhaps you can understand why I object when someone else makes a profit instead...!

Download pages:
 The Little Book Of Ruby
 The Book Of Ruby

Things we talk about include a brief history of Amethyst, how it differs from other Flex IDEs and editors and the major challenges we’ve faced in its development.

Read the interview on InfoQ.

Beta 5 of Amethyst also includes ’encapsulate field’ refactorings (to place variables into getter and setter methods and update all references). And the latest ‘edge’ release adds the ability to refactor classes into new packages. But that’s not the end of it. The next beta will have even more refactoring capabilities. To give you some idea of things to come here is a shot of the refactoring menu as it appears in our current development build of Amethyst...

We’ll blog about the new features in more detail shortly.

We’ve already explained how to automate the renaming of functions and variables throughout a project. But Amethyst’s refactoring goes much further than this. One of its most powerful features is the ability to rename classes and update all references to those classes.

Let’s take a look at an example. Here I have a simple Flex-based adventure game. The visual design is defined in the file, Wombat.mxml, which, as you can see, also contains some ActionScript code...

Note that the code in Wombat.mxml creates objects from the Room class which is defined in a separate file, Room.as. You can see this file in the Solution Explorer, under the \Classes folder. Now I decide that I want to rename the ‘Room’ class to ‘Location’. To do this, I just go into the editor and change the class name...

When I start typing the new name a tiny red rectangle (a ‘Smart tag’) appears beneath the renamed class. When I click this tag, a menu pops down giving me the chance to rename the class immediately or preview the changes prior to renaming. I’ll just rename without previewing...

...and immediately, the Room class is transformed into the Location class. Note that the Amethyst refactoring has made a great many changes ‘behind the scenes’. For example, the constructor (public function Location()) has been changed to match the new class name. Since ActionScript requires that the file name should also match the class name, the file itself (as you can see in the Solution Explorer) has also been renamed (to Location.as). References to the Room class in other files in the project (here, for instance, in Wombat.mxml) have been modified to use the new class and constructor name. And finally, the IntelliSense system has been updated so that features such as code completion and ‘move to class’ via the navigation bar (see the item in the top-left drop-down list) have also been updated.

Refactoring is one of the major features of Amethyst Professional; beta 5 introduces just a few of the refactorings that will be in the final product. In fact, we have already added some new refactorings to the ‘edge’ (interim) release of Amethyst such as the ability to rename packages and move classes from one package to another as explained in another blog post.

We plan to add more refactoring capabilities soon so be sure to keep reading the blog for the latest developments.

The problem with ActionScript (and Java) is that the location of a file and a package name must match. So if you have a package with a name like ‘x.y.x’ it must reside in a directory with the path (relative to the root of the project) ‘x\y\z’. In effect, the name of the package is connected to the physical storage location of the file. Now, I happen to think that this is a seriously dumb idea, though it does have the advantage of telling you where to look for a file from the source code. But then that’s what the Solution Explorer and Go to Definition do, rather more effectively in my view. Still, there are far worse things in ActionScript ... ‘hoisting’of variables anyone?

Anyway, the connection between the package name and the location of the package’s file makes changing the name or moving the file troublesome to say the least: if you change the name of a package, then you may have to move the file and vice-versa. So, we’ve implemented a Move Package refactoring tool.

This can be invoked in one of three ways:
  a context menu on the file node in the Solution Explorer
  drag and drop of one or more files from one directory in the Solution Explorer to another directory
  a Smart Tag generated by editing the package name in the text editor.

I have to say that the last – the Smart Tag - is my favourite; I always try to build Smart Tags into the editor wherever I can!

So, starting off with a package name...

...and editing the package name will generate a Smart Tag marker:

Hovering over the marker and clicking displays the Smart Tag menu:

And here you can see the Preview dialog:

As usual, you can see what the refactoring will be doing (and turn off the changes if needed).

If you don’t want to edit the code, you can initiate the refactoring from the file node via a context menu:

This displays the same refactoring options as the Smart Tag.

Finally, you can drag-and-drop files (and directories) from the Solution Explorer. Again, this displays the Preview dialog for each file.

Over the next few weeks, we’ll be switching on more of the refactoring (such as Move Parameters) and doing a mini-release on a (roughly) weekly basis. The code base actually has most of the refactoring functionality in it, but we wanted to be able to manage the testing of these in a controlled fashion, since the refactoring is pretty complicated (and I write with feeling here).

Obviously, the mini-releases wont be as well tested as a full beta, but hopefully these ’edge’ releases will be quite usable.

For information on the latest ’edge’ betas, refer to the Amethyst section of the SapphireSteel forum.

The plain fact of the matter is that, in order to put the finishing touches on the Amethyst Designer, we needed to arrive at the stage where the Amethyst IDE itself was sufficiently powerful to use for the development of the Amethyst Designer. We are now at that stage and (as we’ve mentioned before) all development of the Amethyst Designer is now being done in Amethyst.

This leads to a rather interesting development process. This is how it works. First we load up the Visual Studio project (mainly C#) in which the Amethyst IDE is written. When this is run, it pops up a new instance of Visual Studio running Amethyst. I now load a Flex (ActionScript) project into this second copy of Visual Studio/Amethyst. Here I can develop the Amethyst Designer. But the version of Amethyst in which I am writing the code of the Amethyst Designer already has its own integrated working version of the Amethyst Designer. Now, when I make changes to the Amethyst Designer code, I compile these changes using Amethyst and then when I next view the Amethyst Designer (the one that’s right inside the same version of Amethyst in which I just compiled it) all my changes are there before my eyes!

Developing an IDE in itself is a strange experience that takes a bit of getting used to. But it has the great benefit of giving us real-world experience of using Amethyst to create a truly complex Amethyst (Flex/Flash/ActionScript) application - one that is not just a ‘test’ application but is, on the contrary, vital to Amethyst itself.

The first public beta of the Amethyst Designer will be released later this summer.

The latest beta of Amethyst provides SmartTags for refactoring. If you change the name of a variable, class or method, a tag appears to let rename all references to that identifier throughout your entire project. In fact, Amethyst also supports another sort of SmartTag for organizing imports (Dermot Hogan’s blog entry gives a few examples) and future betas will add a few others too.

Here is a short example of how to use Amethyst SmartTags for refactoring by renaming:

This is a method that I want to rename...

I rename it by editing the text. When I do so, a little red ‘tag’ appears at the end of the method name (just under the ‘s’ of ‘exploreThings’):

I hover over the tag and a small box appears. I click the drop-down arrow-head in this box and a menu appears, showing me the renaming options available. Here I decide to preview the changes before going ahead and renaming all the references to this method:

Now the ‘rename preview’ dialog pops up. This shows me all the references to this method in my project. I can deselect specific references by unchecking them if I wish. When I click ‘Apply’ any code which previously called ‘exploreWidgets’ method will automatically be rewritten so that it calls the method by its new name, ‘exploreThings’:

As I said, SmartTags can also be used to rename other identifiers such as variables and classes. I’ll have more to say about some new SmartTag refactoring features after the release of our next major beta of Amethyst.

Amethyst gives you a very simple way of controlling conditional compilation. This is done by setting options in the Project Properties pages (available from the Project menu).

You just define configuration symbols with names such as CONFIG::debug and CONFIG::release where the first part (here ‘CONFIG’) is a namespace and the next part (here ‘debug’ or ‘release’) is the defined symbol. Finally, you need to append a comma followed by a Boolean value ‘true’ or ‘false’. You can do this on the Configuration page of Project Properties. Add the symbol in the ‘Symbol to add:’ field and click the button to add it to the list of defined symbols.

You can switch between different sets of defined symbols (say for a debug or release compilation) just by selecting the Configuration name at the top of the Properties page.

Now, in your code, bracket out those lines you wish to include or exclude when specific symbols are defined to be true or false:

Here is a simple example.

In the first window (above) you can see I have defined a Room class (in the file ‘Room.as’). This has a public variable called _name (you could call it anything you want, incidentally). In the bottom window is a separate file which accesses this variable directly (here._name). In principle, this variable might be accessed innumerable times throughout many files in my project. I want to change the name of the variable, make it private rather than public, create getter and setter methods to access it and update all references throughout my project to use the getters and setters rather than the variable itself. In a big project, without refactoring, that could involve a lot of work. But with Amethyst’s refactoring, it can be done in moments. Let’s see how.

First I right-click the declaration of the variable _name and select ‘Encapsulate Field’ from the ‘Refactor’ menu...

A dialog pops up and suggests that the variable be encapsulated as a property (a pair of getters and setters) called ‘Name’. I can either accept this suggestion or I can edit the property name - here I have edited it to ‘RoomName’...

Optionally, I can preview the changes that will be made, navigating down a tree of references to the _name variable in files throughout my project. If I want any of these to be left unchanged when the refactoring occurs, I can uncheck some branches. Here I want to update all references so I leave all branches checked...

This is the result of refactoring...

The original variable has been changed from public to private and a pair of getter and setter methods have been auto-generated to assign and return the value of the variable. These methods have been given the name which I selected, RoomName. All references throughout my project to the original _name variable have been changed to use the new getters and setters - for example, the code in the bottom window now refers to this property: here.RoomName.

And all this was done in a matter of seconds!