Component Workshop Ltd

This is profound in two ways, firstly and most obviously it costs the client less, and enables us to create better relationships. But this productivity gain also allows us to get functionality in front of the user quicker and as such we can identify requirement changes and fix bugs sooner, meaning we deliver better quality code first time.

Agile

We work in an Agile manor and while we can do this regardless of the technology we use, Rails lends itself to an Agile process perfectly.

Solid Design Patterns

Rails encourages the developer to employ consistant design patterns, the rails guys call this Convention over Configuration which promotes maintainable well tested code.

Separation of Concerns

Rails goes beyond Separation of Concerns by removing Concerns, Object Relational Mappers take out 1000's of lines of code that would take up 50% to 80% of the developers time, simple Routing patterns eliminate tones of boiler plate code.

The baked in support for Model View Controller means makes its easy to keep things in the right place.

Open

Over a 10 year contacting career I hit so many hurdles using web frameworks from commercial vendors, from the ASP.NET framework to JSF I found that whenever I wanted to bend these frameworks, they snapped! And the closed source meant that I was back to the drawing board having to invent an ingenues hack, Rails however is open source and the code (especially the rails 3 code) is well written and easy to extend (partly due to the Ruby language), I can easily bend it in any way I choose.

Database Agnostic

As I mentioned the Object Relation Mapper reduces a tone of code and save you even more time, but the abstraction from the database goes even further than that, A rails application written against MYSQL will work against any Database in production, in fact we have an app that is running on SQL Server for one client and Oracle for another, while we host it for other clients on MYSQL.

Just a few reasons why we use Rails, I hope you will too.

So we chose Ruby for two reasons on the server side -- we like it, and we needed a restful service that the iPhone could interact with (and I can't think of any way of creating a restful service faster than Rails). We added a stompserver, because messaging solves a few problems that we knew we'd come up against (notifiying any listener of changes to an account's configuration, for example). We then wrote the listener, which was effectively an infinite loop that created a new Thread for each mailbox that needed to be monitored.

As you can imagine, this service has many edge cases that need to be handled in an elegant manner, and Ruby let us sketch out the code paths really well. We were using net/imap to monitor the mailbox (monkey patching it to add support for the IDLE command), and while it worked fine in development, it didn't hold up so well in the real world.

We still can't say exactly why our Ruby implementation wasn't reliable, but before we'd even gone live we knew it needed to be re-written. If we left the service running for 24 hours or so, it would silently die. We'd added exception handling, and were trying in vain to capture socket errors and the such like, but everything appeared fine, it just didn't work -- we weren't getting notifications of new messages.

Luckily, Apple's app approval process takes a couple of weeks, so we wrote a proof-of-concept replacement in Java using JavaMail. When we saw that it was good, and that exceptions were consistently thrown (so we knew we'd be able to handle sockets being closed and other unexpected errors), we simple re-wrote the service in Java, using our Ruby implementation as the spec. This worked really well -- we had a complete re-write in two days. The improved exception handling in Java meant that we could better understand the things that were going wrong, and we made many small, incremental improvements to the service that mean it should now be pretty solid.

So do we regret writing it in Ruby? Was that two wasted days? Absolutely not. If nothing else, Ruby allowed us to create a prototype without having to actually worry about the framework. The Java implementation was drastically quicker thanks to the Ruby template that we'd developed -- refactoring and restructuring a Ruby application is much easier than doing the same thing in Java.

The stomp server is still in there, and is working great. We usually use ActiveMQ for messaging, but the stomp clients are incredibly lightweight and appear to be more than good enough for this particular application.

We have written our latest business package, BrightSpark, in Ruby. This isn't much of a departure for us because we have quite a few Ruby on Rails projects in our portfolio, including CodeSpaces which is by far and away our largest Rails projects. However, it is the first time we have written a complete business package designed for deployment on our customers' servers in Rails.

One of the influencing factors in our decision to go this way was the ever-maturing JRuby. JRuby provides a wonderful bridge between Ruby and Java, and this opens up certain enterprise opportunities.

In our experience, Ruby gets a lot of of attention from forward thinking developers in enterprise environments, but it rarely gets any real traction. This is often down to lack of familiarity, or the perception that it is not a seriously supported language. Java, of course, is at the complete opposite end of the spectrum. Merging the two makes a lot of sense.

You would be amazed at how fast we can prototype new web applications in Rails. What would take several weeks of effort by a small team can often be accomplished in a few days with Rails. Not because it is magic, but because it is pefectly designed to enable rapid development of data driven web applications. This alone makes it a worthwhile tool for enterprise development teams -- even if it is only ever used as a prototype tool, being able to get ideas in to software form rapidly would positively affect the outcome of many projects.

So what's planned for JRuby.com? Well, as part of our work preparing BrightSpark for easy installtion, we're packaging a complete JRuby server stack. This will include an application/web server (Tomcat, Glassfish or TorqueBox), a database (MySQL, Postgresql) or adapters for commercial databases (SQLServer, Oracle, DB2) and an app store style deployment system for distributing applications (we've currently prepared two free applications; WikiWikiNoteBook and WikiWikiTaskList -- these are available as stand-alone Rails apps in our Labs section of the website).

We're also recording training videos and writing guides that help .NET and Java developers get up to speed on Rails fast. Any competent developer could learn Rails in little over a week, and with the right kind of help it could be even quicker.

This is all planned to arrive some time around the end of September. We're a small ISV, and we have a couple of other projects on the go so this date might slip a little, but we're really keen to get this started and make it a genuinely useful resource.

SHA-1 and MD5 are hashing algorithms. They read some content and produce a string that is relatively unique to that content.

The purpose of a hash is to identify a file as being consistent with your expectations. The two reasons I use a hash are: to ensure that a file I transmit (usually over a web service) is exactly the same as the file on the server, and also to create a ‘base-line’ hash of a downloaded file to compare against the same file at a later date (if the user has made changes the hash will change).

Note that a these hashes, while fairly robust, are not bullet proof. Two files can have the same hash despite being completely different content. These are called collisions, and are extremely rare (at least when considering collisions that happen by chance). Be aware that malicious users can purposefully create matching hashes on different files with relative ease, and this is not intended as a security mechanism (if you need to prove that a document has not changed, consider digital signatures of at least 1024 bytes in length).

The primary purpose for this article is to give programmers a quick reference implementation for the SHA-1 hash that will read a binary file on the local disk and return a hexadecimal string. I have provided implementations for Ruby, Java and .NET that all return identical values for a given file.

If you have written your own functions and are having problems matching your hashes, ensure that you are opening your files in binary mode (applies to Ruby).

Here’s the code:

.NET (C#):

public static string GenerateHash(string filePathAndName)
{
  string hashText = "";
  string hexValue = "";

  byte[] fileData = File.ReadAllBytes(filePathAndName);
  byte[] hashData = SHA1.Create().ComputeHash(fileData); // SHA1 or MD5

  foreach (byte b in hashData)
  {
    hexValue = b.ToString("X").ToLower(); // Lowercase for compatibility on case-sensitive systems
    hashText += (hexValue.Length == 1 ? "0" : "") + hexValue;
  }

  return hashText;
}

Ruby/Rails:

def generate_hash(file_path_and_name)

  hash_func = Digest::SHA1.new # SHA1 or MD5

  open(file_path_and_name, "rb") do |io|
    while (!io.eof)
            readBuf = io.readpartia<script type="text/javascript" src="http://www.componentworkshop.com/javascripts/extensions/tiny_mce/themes/advanced/langs/en.js"></script>l(1024)
            hash_func.update(readBuf)
    end
  end

  hash_func.hexdigest

end

Java:

public static String generateHash(File file) throws NoSuchAlgorithmException, FileNotFoundException, IOException
{
  MessageDigest md = MessageDigest.getInstance("SHA"); // SHA or MD5
  String hash = "";

  byte[] data = new byte[(int)file.length()];
  FileInputStream fis = new FileInputStream(file);
  fis.read(data);
  fis.close();

  md.update(data); // Reads it all at one go. Might be better to chunk it.

  byte[] digest = md.digest();

  for (int i = 0; i < digest.length; i++)
  {
    String hex = Integer.toHexString(digest[i]);
    if (hex.length() == 1) hex = "0" + hex;
    hex = hex.substring(hex.length() - 2);
    hash += hex;
  }

  return hash;
}

Note that all examples use SHA-1 by default, but can easily be changed to use MD5 by changing one line in each case (see comments). Note also that these implementations take a file, but could very easily be adapted to take a byte array, if that's what you're working with.