In one of our current projects we have been experimenting with additional layers to the model-view-controller (MVC) pattern. Namely the presenter and conductor; the presenter sitting between the controller and view, and the conductor sitting between the model and controller. Whilst, granted, they are overkill for most projects when used correctly in the right situations they can make your code much easier to read and comprehend.

Read the rest of this entry

Caching and performance is something that always lingers at the back of my mind, and the Holy Grail is yet to be found as far as I am concerned. While looking around on various blogs recently, I came across some fantastic articles on caching that I found really exciting. In a nutshell the article introduces the concept of using ESI, or Edge side includes to create huge performance boosts in Rails applications. ESI is a standard that I had never heard of before, though it has been around since 2001. The specification for ESI was written by some interesting people who have great pedigree in the field of advanced scalabilty, Akamai for example.

ESI is very similar to SSI but has a more sophisticated method for including content that can use things like a try-catch type DSL to ask for content and fall back to alternatives if something goes wrong. To put this in context and to highlight why it is really cool, consider Rails’ whole page caching. An app can write an entire action to a static file in the public directory. Your server can pass this file to its clients without touching Rails and its routing system. This has always seemed like a fantastic concept, but one that can hardly ever be used in the wild. Necessary elements in the page such as shopping cart contents, links to your account, user’s status etc., always spoil the fun when you are trying to avoid hitting the app. This forces you to use fragment caching and model caching when caching 99% of the page at the level of Mongrel would be far more ideal.

Enter ESI (SSI will also do, but ESI has some additional nice features). Whole actions can be cached as static content above the level of your app, but embedded in them is markup that the server executes to fetch more content where necessary. A high traffic shopping site could have something along these lines, in place of some content in the page that displays a cart:

...
  <esi:include src="/cart" max-age="0"/>
...

The users’ session is passed through, and you can retrieve the items in their cart and render it as on a mini action in your Rails app. The server is responsible for inserting it into the markup and returning it to the client. The max-age of 0 means that it will ask for a fresh version from your app everytime it is run. However, setting it to a higher TTL value means that subsequent request will use a cached copy that the server stores and is responsible for. The really cool thing about this is that it puts responsibility of dealing out cached content onto your web server, rather than the actual Rails app. At the moment you need a custom version of mongrel that supports ESI to use it. Also, it is worth noting that the current version of mongrel-esi stores these cached fragments in memory, though the guys are working on a memcached version. Have a look here to get the install details and also a plugin that helps you integrate it into your Rails apps.

This is obviously cool stuff, but there are some other neat things you can add into the mix. The Rails default method of storing the cached pages is on the file system in your public directory, which gets a bit messy. However, in this article it describes putting them into memcache and then telling nginx to look in memcache before hitting your app to retrieve them. This is pretty fantastic as it makes managing the cache much easier.

Another option to consider for delivering the fragments would be a lovely lightweight merb application, since the src attribute of an esi:include can be another url, it doesn’t just have to be a path on the same server. I haven’t actually tried this, so it should be taken with a pinch of salt, but I think you should be able to do this:

  <esi:include src="http://super_merb.my_app.com/cart" max-age="0"/>

So things are looking pretty nifty in this area, and I am definitely going to be keeping an eye on it.

I took some time out this week to finally tie up the loose ends such as hotels, flights etc and now can confirm that we’ll be deploying a five person strong New Bamboo entourage. Max, Michelle, Pablo, Gwyn and I will be arriving in Berlin on the 17th of September.

I haven’t been to Berlin in nearly 7 years when I worked at Pixel Park so I’ll be looking forward to seeing the sites and meeting fellow Railers! If you’re going to be at Railsconf Europe or just in the vicinity it would be great to meet up and hang out.

Not long now! The application deadline was last Sunday and by the end of this week the 20 finalists will be announced. This is certainly the start of something which will change the startup landscape throughout Europe indefinitely. The beauty of Seedcamp is it’s giving the passionate and committed engineers (but not forgetting entrepreneurs and designers) the chance to really get their idea produced and out there to the world. London is a wonderful place, and everyday I am amazed by the new people I meet here. If you’re already in London, don’t miss out on OpenCoffee, this week it will be a great time to meet other Seedcamp applicants.

We have had the pleasure of working with the Seedcamp team throughout from the site to development of the application, application. Knowing several teams in London taking part, there’s going to be some stiff competition, that’s for sure.

A few weeks ago we start experimenting with Git for Rails development.

I am not going to highlight the all of the advantages of using git here, but let me mention that Git is one of the few SCM out there that really understands merges.

As Linus, the creator of git, says in this thread

“The important part of a merge is not how it handles conflicts (which need to be verified by a human anyway if they are at all interesting), but that it should meld the history together right so that you have a new solid base for future merges. In other words, the important part is the trivial part: the naming of the parents, and keeping track of their relationship. Not the clashes. And it looks like 99% of SCM people seem to think that the solution to that is to be more clever about content merges. Which misses the point entirely.”

Git tracks content, not files. Git is really a filesystem, represented by tree structures. So you are really comparing trees between commits, and tracking the changes of the nodes in the tree.

There are enough tutorials out there for you to start grasping git. I can recommend these ones:

• Beginners tutorial
• Git user manual
• Git for SVN users

You may want to consider Git if you have ever run into a merge marathon on a big project with SVN. If you have ever tried it, it is just painful and it does not work, not the SVN way.

Enter Git

Git makes branches easy to create and merge. Git branches are only a 40-digit hex hash, with the origin of the branch. Branches are cheap, and easy. You start using git, and before you realise it, you are merging and branching all the time.

So a regular working pattern would be:

------------------------------------
git branch mywork
git checkout mywork
...hack some files (file1 file2 file3)...
git add file1 file2 file3
git commit
git checkout master
git merge mywork
------------------------------------

Yes that’s good, but what happens when all your development repositories are under SVN control? Well here comes a little script that will help us integrate with our existing repositories.

Enter git-svn

git-svn is a little perl script (that comes bundled with the Git distribution) that lets you track SVN repositories. You can also commit back between Git and SVN. This is very good, you can start using git without converting your working repositories yet… well until you are ready to migrate them.

GIT RAILS RECIPE

mkdir beast
cd beast
git-svn init http://svn.techno-weenie.net/projects/beast/trunk  (for example) 
git-svn fetch -r2940                                            (get a particular repository revision)
git-svn fetch                                                   ( get the whole repository history)

then REPEAT{ 

git checkout -b mywork        (start my own branch)
   ....START HACKING          (fix some bugs)
git commit -a                 (commit the changes to git)
git checkout master           (switch to master branch) 
git-svn rebase                (update master with the upstream svn repository)
git checkout -b mymerge       (create a branch mymerge and checkout from master)
git merge --squash mywork     (merge into current branch, mywork branch) 
git commit                    (commit the changes to git)
git-svn dcommit               (commit the changes to svn repository....if you have enough permissions)
git checkout master           (switch to master branch) 
git-svn rebase                (update master with the upstream svn repository again)
git branch -D mywork mymerge  (get rid of branch mywork and mymerge)

}

See http://cheat.errtheblog.com/s/gitsvn/ for a cheat sheet on this.

Here James Bowes tells us why rebase is important: http://jbowes.dangerouslyinc.com/2007/01/26/git-rebase-keeping-your-branches-current/

There is one problem with git-svn. It can not handle svn:externals yet.

But there is a workaround to it. Once you fetch your RAILS svn project, you may want Rails edge in your vendor directory, or some handy plugins as well.

Get RAILS EDGE into a separate git clone as well as your handy plugins. Then do a symlink into the vendor directory.

mkdir rails_edge
cd rails_edge
git-svn init http://svn.rubyonrails.org/rails/trunk  (for example)
git-svn fetch -r7300  (get just the latest revision you know about) 

git-svn fetch   (perform a fetch once in a while to keep it up to date)

then cd myproj/vendor
ln -s ../../rails_edge rails

Perform the same task for every plugin you use. You may also track a stable version of rails like http://svn.rubyonrails.org/rails/branches/1-2-stable

There are pros and cons of this approach. You can decide if this is enough for your current needs or wait until git supports subprojects. Keeping Rails stable and edge in different repositories, and tracking their changes independently seems to be a very clean way to work.

I hope that gives you a warm welcome to the world of git, and that you start enjoying Rails development along with Git.

*source Mike Riley

From the start, I have to warn you that this melodramatic title may not have been terribly well considered. When Shelley asked me what my talk at 2 was going to be, I responded in rather a flustered manner without thinking through the ramifications. I think a sense of rather foolhardy bravado may have seeped into the name of the talk, and I am not ashamed to admit that.

Not wanting to disappoint, I wracked my brain for Actionscript 3 scenarios which could relate to the theme of Dragons. No luck. Cursing the English Literature degree that had seemingly created this intractable situation, I got to work on the talk.

The thing I wanted to convey most is that making things with AS3 is not really hard or indeed Evil. Many people have misconceptions of Flash, and most Rails developers I know don't really like the idea of playing around with it at all. In my experience, Flash is a really great medium for doing loads of different things, though definitely not a replacement for HTML/CSS/JS in most cases. I really enjoy creating stuff in Flash, and intended to get some people to listen to me.

Also worth noting, this talk was not about Flex. I have experimented with Flex, and kind of like the idea behind it for RIAs. Sometimes though you just want to work with the actual language behind the interface, rather rely on a whole bunch of classes that get mysteriously instantiated from your MXML.

I wanted to educate people about the fundamentals of how these interfaces are build from the primary elements. We cover creating sprites on the stage, importing other classes, attaching behaviour and some of the basics of drawing. Sticking with the mythological theme (though not of a dragonesque nature), the examples are set in the depths of time in Ancient Greece. Gods chill out on Mount Olympus, and everything is hunky dory. With that in mind, here is the content of the talk. You can get the files here:

http://blog.nbwd.co.uk/assets/2007/8/7/gods.zip

Zeus

The first example we look at is as simple as you can get. We put this in the file 'Main.as' in the example called 01_zeus. When this is compiled, we include the Sprite class and make a class called Main that is inherited from it. The constructor function is named the same as the class, so when this is compiled and run, the Main function is called when an object of class Main is initialised and added to the stage.

In this Main function is where all the magic happens, we create a new Sprite (not a pun) called zeus, and start drawing his likeness. Now whatever people may claim, no-one has ever seen a greek god, and I don't believe the likenesses of them on pots are right. In my opinion, Greek gods are all square in shape, and covered in colourful hair. This has nothing to do with it being easier to draw sprites like that, so don't even suggest it. We specify that zeus will be black, and 50x50 pixels. We do this by calling methods on the Sprite's built in graphics object. once we have draw him, we add him to the stage for all to admire. For fun, we nudge him into the middle a bit more to demonstrate how Sprites have x and y coords for positioning them.

package {
    import flash.display.Sprite;

    public class Main extends Sprite {

        public function Main():void {
            var zeus:Sprite = new Sprite();
            zeus.graphics.beginFill(0x000000);
            zeus.graphics.drawRect(0, 0, 50, 50);
            this.addChild(zeus)
            zeus.x = 30
            zeus.y = 30
        }
    }
  }

"Wow", I hear thee cry, "surely the talk was over at this point and roses were being cast at your feet?". This was not the case Gentle Reader, greater marvels were to appear shortly.

Athena

Now Zeus is a bit old and cannot move very well. To demonstrate a bit more action we pan to Athena. In this project (02_athena) we have a new directory called "gods". This will contain all our other classes we are going to use. In our Main.as we import "gods.Athena;" which is the class in gods/Athena.as, and add it to the stage like we did with Zeus. Athena has all her internals nicely encapsulated inside her, unlike slovenly Zeus. She can do this because she is created from a class that extends Sprite and can add to it as we want. We have to import all the classses we are interested in inside the package that contains Athena. In this case we want the sprite class, and all the events "flash.events.*;" which we use a wildcard for.

When Athena is instantiated, we draw her as a square (totally correct), but her class has a public variable called hair color:

public var hairColor:Number = 0xe4a406;

this is used to make a nice golden square instead of the black we used on Zeus. She also has event handlers added to her. When someone clicks on her, the method startDrag() is called on her which is inherited from Sprite. She can now move around on the stage with the user's mouse (though the ironic notion of humans being in control of the motor functions of the Gods is a whole debate I am not entering into atm). Interestingly, we attach the mouseup event to the stage object of the Sprite rather than the sprit itself. This prevents the situation where you drag something and inadvertantly move out of the window. The stage can tell if you release outside the window, but if it is on the object, it won't get the hint.

Olympus

Again, a miraculous thing, but the fun doesn't stop there. We now decide to make a home for all these gods, and feel that Olympus is a fiting name. In 03_olympus, we make an olympus object and add it to the stage. Like we did with the gods, we represent Olympus as a square, it is big and grey. Olympus has an event handler on it which takes mouse clicks and creates new instances of RandomGod on the x and y of the event. Clicking on the stage creates a multitude of gods. Unfortunately there is a bit of a bug here which was noticed afterwards and that I haven't fixed, if you click on a random god, the x and y are taken from it rather than Olympus. Not the end of the world, but there ya go.

Naughty Gods

In the final example a bit more goes on. We create olympus as before, and also create zeus with his own special class. The random gods are populated automatically this time, and Olympus takes care of creating them when it is instantiated. Unfortunately these gods have been drinking some rather bad wine. This has the unintended consequence of turning their hair green, and making them rather unruly. Intolerable.

Zeus, not gifted with ample amounts of patience for his immortal responsibilities responds to this chaos by delivering a thunderbolt into the rabble, killing them dead.

Let's analyse what is involved in this catastrophe.

When Zeus was created, he was not created equal. The Zeus class has the following:

public function Zeus(posX:Number, posY:Number):void {
            ...
            this.addEventListener(MouseEvent.MOUSE_DOWN, mouseIsDown);
        }

        public function mouseIsDown(event:MouseEvent):void {
            strikeDownNaughtyGods();
        }

        public function strikeDownNaughtyGods():void{
            var lightning:LightningBolt = new gods.LightningBolt(this, olympus.naughtyGods);
            olympus.addChild(lightning)
        }

When clicked, Zeus calls the function strikeDownNaughtyGods(). This makes a new ferocious lightningbolt taking Zeus (this), as the thrower, and olympus.naughtyGods as the targets. The variable olympus is just a reference to olympus we set on zeus at the beginning. When our lightnning bolt is made, the fun starts. The graphics object is called, and we say we are going to start drawing with the thickness of boltWidth and a nice blueish colour. the drawing pointer is moved to the center of the srcGod, and we send the bolt off.

package gods{
  import flash.display.Sprite;
  import flash.events.*;
  import flash.utils.Timer;
  import flash.events.TimerEvent;
  import flash.display.Sprite;

  public class LightningBolt extends Sprite {

    ...

    public function sendBolt():void{
      killCount = 0;
      timer = new Timer(500);
      timer.addEventListener("timer", timerHandler);
      timer.start();
    }

     public function timerHandler(event:TimerEvent):void {
        if (killCount == targetGods.length){
          timer.stop();
          this.graphics.clear();
        }else{
          this.graphics.lineStyle(boltWidth*=0.8, 0xb2ebf4);
          this.graphics.lineTo(targetGods[killCount].heartX(), targetGods[killCount].heartY());
          targetGods[killCount].kill();
          killCount++;
        }
     }
  }
 }

A Timer object is created, and every 500 miliseconds it will call timerHandler. When we haven't killed all the gods yet, the bolt width diminishes to reflect the principle of Conservation of Energy, and then we draw a line to the next god in the array. This new god has the method kill() called on him, which in itself is scary. This method makes him change colour, shake from side to side and finally expire, turning red in the process. When the naughty gods are dealt with, the timer stops, and Zeus can read a book in peace.

So there you have it, some basic principles explained. I am by no means an expert, I just play around every now and again for fun. Hopefully a few brave souls will have a go and come up with some other neat stuff. I have found that graphing in particular is an area where Flash shines, especially where it is being fed xml from a beautiful Rails app. Maybe I will blog about my recreation of a zoomable graphing for showing tons of data at some point if anyone is interested (a bit like Google Finance, but made by me).

Things are alway rather busy here, everyone working away on our various projects. It can sometimes be hard to spend a bit of time getting back to our roots and hacking away on stuff which is not related to our work. It is even harder to share this knowledge with everyone when it has no bearing on the task at hand.

With this in mind, we have been trying out a new scheme in New Bamboo Towers to encourage sharing of all those crazy gems of knowledge we discover in our own time. Thus the "Talk at 2" came into being (Damien has suggested "talk@2" but this seems a little 2002 to me). On Friday afternoon, one member of the team presents something that they find particularly interesting, and that other people might not be familiar with. It can be related to anything really, but usually has an element of programming in it.

So far Jonathan has done a talk on rSpec, and on Friday I presented an unbelievably useful and emotional piece about ActionScript 3 that moved many of the guys to tears. We will try to get these written up after the event so everyone can share the fun.

At this point I have to give a disclaimer that this might not happen every week, sometimes there just isn't enough time, but we will certainly try to be diligent with it for as long as we can.

I also feel it needs a theme tune and maybe a logo, but don't feel capable of creating either. In my head, the theme tune should be a mixture of the Countdown theme tune, and the Darth Vader music from Star Wars. If anyone can come up with something that encapsulates this, I'd be very interested in hearing from you.