Tag Archives: code coding comparision conventions File Management File transfer between servers File Upload FTP File Upload FTP Transfer j2ee Java PHP Ruby Ruby Hosting Issues Ruby on Rails software standards

10 Reasons why – Ruby on Rails

Your development team has been frustrating you, projects start and four weeks later the development team is still developing the framework, your budget is running out. You want productivity but just don’t know how to get it. Is there an answer? One of your developers keeps mentioning this great framework called ‘Ruby on Rails’. Is this the answer? This article discusses the positives and the negatives in moving to this new technology.

1. Ruby on Rails provides a consistent approach to building web applications with an out of the box architecture. Traditionally starting a new web application is a fairly heavy weight process, you typically need to survey and choose your various software components to solve the common architectural problems of persistence, logging, build scripts, application configuration, web tier components and workflow. With the Rails framework these decisions are already made for you, so you can get on to understanding the business problem and quickly build a working system. You become productive in minutes not weeks or months.

2. In a Rails application, a pragmatic philosophy of convention over configuration is taken, this is apparent in all layers of the architecture with the highest productivity gains noticeable in the relationship between the model and the database. Once the developer understands the rules and constraints, Rails magically connects your view to your controller and model, and your model to the database. You don’t need generators or specialised tools to manage this, it all just works.

3. Unlike other productive web scripting languages, Ruby is a fully featured object-oriented language. Ruby also adds additional power with mix-ins modules which contain independent code to inject into your classes, blocks and closures simplifying client code behaviour. Its dynamic nature gives it power beyond static languages such as .NET and java, and the benefits are apparent by how the Rails framework has been put together itself.

4. Unlike other web templating technologies, the templating technology built into Rails can be used to generate web pages, emails, xml documents or any text document that requires dynamic content.

5. Rails includes a well thought out object relationship mapping tool, ActiveRecord, which provides your answer to database persistence. Your model is seamlessly persisted to the database. Transactions, inheritance models, validation, and caching have all been thought out and are production ready. With Rails you become a lot closer to the structure of the database than traditional object-oriented development methodologies. This is a good thing as over time as the database will no doubt end up being your project’s most valuable asset.

6. Rails includes support for a variety of web technologies. Every web application needs email integration at some point and Rails provides an out of the box smart solution, and as with other Rails technologies it gives you the complete package down to configuration in development, test and production environments. Ruby on Rails also supports web services, the integration with Rails due to the dynamic nature of Ruby is simply, clean and seamless. If you are moving into the Web 2.0 space, Rails provides a rich abstracted interface to implementing AJAX operations.

7. Generally software projects do not mature if at all to the point of having a solid foundation to perform database migrations and rollbacks between environments and across development systems. However with the Rails framework you will be delighted with the implementation of database migrations for applying and rolling back database changes. You enter your update and rollback scripts in Ruby, Rails understands the current version and can move forwards or backwards to any database version.

8. For development productivity, the shorter the gap between the change and test cycle the better. In Rails, changes are reflexed immediately within the runtime environment so developers can quickly iterate between fix and test cycles without any expensive redeploys. Ruby code is also easily testable. Methods and objects can be replaced at runtime so software components can easily be tested without resorting to external tools or generators.

9. Getting started with Rails is easy as generators will propel you along. An experienced Rails developer will also become aware of numerous idioms available within the Rails framework that shared the amount of code a developer need write. Overall less code to write means lower complexity, higher productivity and less bugs.

10. Ruby has been around for a long time, the Rails framework which has deservedly propelled Ruby into the spotlight has hit version 1.1 and is production ready. Ruby and the Rails framework is open source and well supported by a clever team of contributors.

*So what are some of the cons?*

1. If you take time to follow the Ruby examples and tutorials it may give you a false sense of productivity. They typically follow the formula of creating a database model, configuring a connection to the database and joining it up to the model controller and view by use of the generators. This is all very simple involving a dozen or so lines of code. In the real world however you will be working at higher level of complexity and will need to understand multiple facets of Ruby and the Rails framework to be productive in churning out business functionality. You will need to invest in getting up to speed with the language and framework. As Ruby is a dynamic language, more automated testing is required. Your developers will need to become more disciplined and rigorous in creating unit tests as part of their development process.

2. As the Rails framework is not in widespread use compared to technologies such as Tomcat and ASP.NET, you may not have access to the same level of community support from various website forums and open source libraries.

3. If the type of development you are doing is glueing together existing systems or building back end systems, be aware that Rails is optimized for building web applications, your host system or enterprise database may not have the integration module you require for Ruby.

4. If your system is likely to grow to that ‘10 person, 3 year project’, there are several factors you need to consider, you may find the level of tool support lacking. Features such as find references, refactoring techniques and code-complete are still not available on the current set of IDE’s. This however is hopefully only a problem of time, RadRails a version of Eclipse built for Ruby development and is now a viable and great Ruby IDE. New features are continuously appearing from the core version of Eclipse.

After considering the pros and cons, my advice would be that if your business has tight timelines and limited IT budgets (and who doesn’t?), and a requirement for web driven database applications then I seriously suggest considering investment into the Ruby on Rails framework.


Why You Need Coding Standards

The best applications are coded properly. This sounds like an obvious statement, but by ‘properly’, I mean that the code not only does its job well, but is also easy to add to, maintain and debug.

This “maintainable code” is a popular talking point among those involved with PHP and probably with other languages as well. There’s nothing worse than inheriting an application or needing to make changes to code that requires a lot of energy to decipher – you end up trawling through lines and lines of code that doesn’t make its purpose or intentions clear. Looking through unfamiliar code is much easier if it is laid out well and everything is neatly commented with details that explain any complicated constructs and the reasoning behind them.

In this article, I’ll explain why coding standards are important not only to the individual developer or development team, but to the script users as well.

The Problem

When we learn a new language, we usually begin to code in a specific style. In most cases, we’ll write in a style that we want, not one that has been suggested to us. But once we start to code using a particular style, like a spoken language dialect, it will become second nature — we’ll use that style in everything we create. Such a style might include the conventions we use to name variables and functions ($userName, $username or $user_name for example), and how we comment our work. Any style should ensure that we can read our code easily.

However, what happens when we start to code bigger projects and introduce additional people to help create a large application? Conflicts in the way you write your code will most definitely appear.

The Solution: a Coding Standards Document

A coding standards document tells developers how they must write their code. Instead of each developer coding in their own preferred style, they will write all code to the standards outlined in the document. This makes sure that a large project is coded in a consistent style — parts are not written differently by different programmers. Not only does this solution make the code easier to understand, it also ensures that any developer who looks at the code will know what to expect throughout the entire application.

Coding standards are great — but how do you decide which standards you want to apply, and how they will be defined? When you formulate your ideal coding style, you should think about these points:

  1. Can you actually read the code? Is it spaced out clearly?
    • Do you separate blocks of code into ‘paragraphs’ so that different sections are easily defined?
    • Are you using indentation to show where control structures (if, else, while and other loops) begin and end, and where the code within them is?
    • Are your variable naming conventions consistent throughout the code and do they briefly describe that data that they’ll contain?
    • Are functions named in accordance with what they do?
  2. If you come back to the code in a few weeks or months, will you be able to work out what’s happening without needing to look at every line?
  3. How are you commenting the work?
  4. Have you used complex language functions/constructs that are quicker to write but affect readability?

Once you’ve considered those points, you can begin to draft your coding standards. Consult with your team members (if any) and compare how they code to your own style — you shouldn’t force total change upon everyone. Compromise and incorporate elements of everyone’s style. If someone has been coding in a specific way for a long time, it will take a while for that developer to change to the new method. Developers will likely adopt the style gradually, just as an accent develops over time.

Create Maintainable Code

As we said at the beginning of this discussion, you want to create maintainable code. If you stop developing a project, return to it several months later, or hand development over to someone else, you (and other developers) want to be able to understand what’s going on in the code. We keep mentioning ‘readability’, but what actually constitutes “readable code”? The answer to this question will obviously differ for each programmer, but I believe there are some common fundamentals, which we’ll discuss now. I’ve used PHP to outline various styles here, but similar ideas will apply to other languages:

// Method 1
if (condition)
function1($a, $b, $c);
for ($i < 7 && $j > 8 || $k == 4)

// Method 2
if (condition)
get_user($id, $username, $key);

for (($i < 7) && (($j < 8) || ($k == 4)))

Here are two ways we might write the same code — you can see the difference between easily readable code and complex, but more quickly written code. Even if you don’t know much PHP, you probably noted that the second snippet is much tidier and easier to understand. I’ve named functions using a verb (get, display), used variable names that describe the data they contain, and used brackets to help show what the for condition is. Not only that, but I’ve also included the braces for the control structures and used indentation to show which code appears under each structure.

Your own idea of readable code might differ slightly from this, but I’d bet that every PHP coder could easily understand what’s going on in the second example. The first example, however, takes extra time to comprehend. Sacrificing extra lines and whitespace will make a noticeable difference to the layout of the code. As you develop coding standards, try to ensure that they allow anyone to work out the code in future!

Different Standards

PHP example code and Pear modules (etc.) generally use the Pear Coding Standards, which are slightly different from the method I used above.

I have my own personal coding standards, which I adopted from the phpBB Coding Standards because I liked the way they were written. For example, in my own standards, I put the braces for control structures on a new line:

if (condition)
get_user($id, $username, $key);

But in the Pear standards, the first brace is on the same line as the if (condition):

if (condition) {
get_user($id, $username, $key);

The standards you choose are all down to personal preference and what you find easiest to code and read.  Happy coding!