Ruby on Rails, an open source web development framework, has revolutionized the way we create web applications. By giving developers the necessarily tools and components needed to build powerful apps in an intuitive development environment, RoR makes development more efficient and less troublesome...
ARTICLE: Four Ways Ruby on Rails Can Help You
So, I needed to work this out the other day and a lot of the Rails plugins didn't seem to do the job. However, it turned out to be quite simple anyway. The Helper
Presuming you have a "Comment" model you need to put the following code in you "comments_helper" file:-
As you can see, you need to 'require' the md5 library. This is used to create the md5 hash of the email address, which is then used in the construction of the gravatar URL. The View
Then you can simply use this help in your view using:-
Obviously you will need to substitute "comment.email" for whatever your email field is called.
There are many ways in which the helper could be improved upon, but this example just has the minimum to keep things simple.
I was looking around for a solid issue tracking system, written using Ruby on Rails. There are some good comparisons on wikipedia. Redmine seems like a good choice; all the standard functionality, that you would expect from a issue tracking system, is available. For instance:-
The code repository can use the source control apps, Git and Subversion.
All in all, a pretty solid choice.
One of the object-oriented concepts, which frequently gets ignored (in my experience) is the process of using abstractions to premote loose coupling.
The "Stable Abstractions Principle" indicates that abstractness increases with stabilty and thus the more abstractions which are used, the more stable you application will be. So, with this in mind, it is a good idea to use abstractions whenever possible.
For instance, say you have an abstract class "Report". "Report" has one abstract method called "create_report".
Furthermore, "Report" has several sub-classes called "XmlReport", "TextReport", "HtmlReport" and "PdfReport". Obviously these sub-classes inherit from the super class "Report" and then override "create_report" with their version of how the report should be rendered.
Now, the code, which will be responsible for using the relevate reporting class, can be very general/abstract.
The advantage of this is the "report_type" parameter is abstract, so we can pass any of the sub classes of Report to the "print_report" method. To prove this, lets create an array of reports and pass them, one in turn, to the "print_report" method.
Will output:-
I am an Xml Report I am a Text Report I am a Html Report I am a Pdf Report
I'm sure it is clear that changing "create_report" in any of the sub-classes i.e. XmlReport, TextReport... will have no effect on the "ReportGenerator" class. In addition to this, more types of reports can be created without making changes to "ReportGenerator". Simply inherit from "Report" and create a new class, say "YamlReport".
So, I just signed up for BarCamp Belfast there. Taking place on the 25th April 2009, it should be an enjoyable event with lots (hopefully) to learn. Fingers crossed, there will be some Ruby on Rails speakers. For more information you can go to BarCamp.