Programming While Stupid

Over engineering is a major problem within the software industry. This problem has led to the adoption of ‘lean software development’ - at least amongst the agile folk. Lean software development is writing code to support the current set of requirements and nothing more. This is not as easy to do as one might think.

As developers we naturally tend to make assumptions as to what the user, or system, will need. In truth, it is very difficult to accurately predict the future requirements of a system. Coding to meet our assumptions will inevitably lead to over engineering.

We should not let our intuition guide us into false requirements. As strange as it may sound, it takes a concious effort to stop ourselves from doing extra work. We need to adopt a ‘lean coding culture’. We need to constantly remind our selves to stick to lean software development. In agile teams it is common to hear developers reminding each other with certain acronyms and expressions e.g. ‘do the simplest thing that works’.

‘Do the simplest thing that works’ is in-line with lean software development, although it can be misleading. Some people interpret this as ‘do the first thing that comes to mind’ e.g. slap on another if statement - that is a simplistic solution and not a simple solution. If you take a quick and dirty simplistic approach you will end up with a big ball of mud. You need to do the simplest thing that works. The thing that works is something that can be tested, it is something that does not add unnecessary complexity. Therefore the simplest thing that works is not necessarily the quickest and easiest thing to do.

Beginners Tutorial: Routing in Rails 2.0 (with REST) - Part 5 of n

In part 4 we explored named routes. In this session we move onto Rails’ REST.

Part 5

The Critics

Before we begin you should know that there are many critics of the Rails implementation of REST. There are many reasons for arguments against Rails’ REST e.g. Rails uses server side session state and client side cookies. Some people say that this is not REST compliant. Rails’ REST might not be 100% REST compliant, but you can still benefit from using REST in your Rails applications. In The Rails Way, Obie Fernandez explains that the benefits from using Rails’ REST fall into two categories:

• Convenience and automatic best practices for you
• A REST interface to your application for the rest of the world

Therefore it is worth learning and using Rails’ REST.

The Standard Introduction

Representational State Transfer (REST) is an architectural style. It was first introduced by Roy Fielding in his PhD thesis. Roy Fielding is one of the principal authors of HTTP.

The Mindset

When developing a Rails application in the RESTful way it helps to change your mindset. You should not think that you are developing a web site for users accessing the site via a browser. It is better to think of the application as being a service. The service performs actions for clients. These clients may be humans or other machines on the network.

This service will typically be placed on the internet. Therefore we could call it a web service. When I hear the term web service I immediately start thinking about SOAP and all the WS-* specifications. Let’s be clear, we are not talking about ‘those’ web services. We are talking about RESTful web services. These two technologies provide similar functionality, but RESTful web services are simple and sensible.

The Terminology

As previously stated, programming in REST requires a change in the way we think about the system. This naturally leads to a change in the way we talk about the system. The following provides a brief description of some of the key terms used in discussions about REST and HTTP.

A resource is one of the key concepts in REST. Many discussions on REST claim that a resource is anything and everything. This is neither true nor helpful. Let’s examine this concept with the aid of an example.

Let’s assume that the music store has started selling albums. The database may have the following schema:

The data in the database is the raw data. There is data which, given in isolation, is of no real value to a client. For instance it is unlikely that a client will want only one row from the LineItems table. This means that a LineItem (on its own) is not a resource within the context of the music store service.

A client would want all the information pertaining to an order. This would include data from one or more tables. Some data would not be included e.g. database keys. Some information may be added e.g. the total cost of the order might be calculated and included in the ‘order information’. This ‘order information’ is an example of a resource. Order resource is the type, there will be one order resource instance for each order made.

Each resource must be given a globally unique identifier. This is done using a URI. This could look like this:

http://www.example.com/orders/65

A client, in an admin role, may want a list of all the orders. This collection of orders would be another resource. Following the REST architecture, the orders resource would be assigned the following URL:

http://www.example.com/orders

It is important to note that these resources are not HTML documents. Roy Fielding describes a resource as a conceptual mapping. As a resource is a conceptual entity it can not be used by a client. The service provides the client with a representation of the resource.

When the client is a browser, the service typically provides an HTML representation of the resource. If the client is another machine then the service may provide an XML representation of the resource. Other representations could include a PDF file, an image, csv etc. A representation is only supported by the service if it is applicable and required.

Resources are often referred to as nouns. This is often done when talking about HTTP to assist learning. The term ‘noun’ is more abstract. For our purposes, resources and ‘nouns’ are synonymous.

HTTP also has the notion of verbs. These are the HTTP operations. We are all familiar with the POST and GET operations. In addition to these two operations, HTTP also supports: DELETE and PUT.

There are a few more terms to cover, but we can do that later. The core terms have been explained.

Beginners Tutorial: Routing in Rails 2.0 (with REST) - Part 4 of n

Part 5

The routes we have discussed so far are known as simple routes. I have been referring to them as custom routes, but ‘simple routes’ is the correct term. The default route we discussed in part 3 is also a simple route. The aim is to move onto RESTful routes, sometimes called resource routes. RESTful routes are built on top of named routes. Therefore we must first cover named routes, and that is what part 4 is all about.

Part 4

Introduction

Referring back to part 1, the routing system has two main functions:
Interpreting a request URL
Generating a request URL

We had a detailed look at route generation and interpretation in part 2, but let’s have another quick look at it. Let’s assume, for some insane reason, that we defined the following route in the music_store routes.rb file:

map.connect ‘apples/bananas/:id’, :controller => “albums”, :action => “show”

link_to would use this rule to generate a URL, this can be seen in the following line extracted from index.html.erb:

link_to ‘Show’, :controller => “albums”, :action => “show”, :id => album.id

This could generate a URL of: http://localhost:3000/apples/bananas/7
And when given this request, Rails would handle it correctly e.g. the show action will be called on the albums controller and the show view will be sent as the response to the browser.

Coming back to the real world, we are more likely to define the routing rule like this:
map.connect ‘albums/show/:id’, :controller => “albums”, :action => “show”

link_to (and friends) would then generate a URL like this:
http://localhost:3000/albums/show/7.

To show the index (the listing of the albums) we could define a rule like this:
map.connect ‘albums/index’, :controller => “albums”, :action => “index”

The matching link_to in edit.html.erb is:
link_to ‘Back’, :controller => “albums”, :action => “index”

Looking at the last example, there is some repetition. Both lines contain:
:controller => “albums”, :action => “index”

The link_to method needs this (controller, action) information to obtain the URL. If we had the URL stored as some global variable, or method, then we could simply pass that into link_to. link_to could use this ‘literal’ URL without needing to generate one.
This could look something like: link_to ‘Back’, albums_index_url
This is one of the main ideas behind named routes.

Beginners Tutorial: Routing in Rails 2.0 (with REST) - Part 3 of n

Part 4

Part 3

At the end of part 2, routes.rb looked like this:

<pre>ActionController::Routing::Routes.draw do |map|
  map.connect 'music', :controller => "albums", :action => "index"
  map.connect '', :controller => "albums", :action => "index"
  map.connect 'music/show/:id', :controller => "albums", :action => "show"
  map.connect 'music/delete/:id', :controller => "albums", :action => "destroy"
  map.connect 'music/edit/:id', :controller => "albums", :action => "edit"
  map.connect 'music/update/:id', :controller => "albums", :action => "update"
  map.connect 'music/new', :controller => "albums", :action => "new"
  map.connect 'music/create', :controller => "albums", :action => "create"
end

To simplify things, let’s remove the routing rule for the empty URL. Remove line 3.

We can no longer browse to http://localhost:3000/, but we can still browse to http://localhost:3000/music. Besides that, the site should continue to work as before.
Looking at the routes.rb file we see 7 rules defined.

ActionController::Routing::Routes.draw do |map|
  map.connect 'music', :controller => "albums", :action => "index"
  map.connect 'music/show/:id', :controller => "albums", :action => "show"
  map.connect 'music/delete/:id', :controller => "albums", :action => "destroy"
  map.connect 'music/edit/:id', :controller => "albums", :action => "edit"
  map.connect 'music/update/:id', :controller => "albums", :action => "update"
  map.connect 'music/new', :controller => "albums", :action => "new"
  map.connect 'music/create', :controller => "albums", :action => "create"
end

We have 7 rules and only one database table. Does this mean we need to add 7 more rules for every table we add? No, there are ways to reduce the amount of explicitly defined rules.

When Rails receives a URL it tries to find a matching routing rule. It does this by comparing the URL to the pattern string in the rule.
The pattern string for map.connect ‘music/create’, :controller => “albums”, :action => “create” Is: music/create

The pattern string for map.connect ‘music/edit/:id’, :controller => “albums”, :action => “edit”
Is: music/edit/:id

The :id is a Ruby symbol and is referred to as a receptor. If you are new to Ruby you may not be too familiar with symbols. I once came across a short and sweet description of a symbol “A symbol is the name badge, not the person”. I may have read that in here.

A receptor is used as a wildcard. It matches anything that it is compared against. The wildcard receptor gets passed into the controller action within the params hash e.g.

def edit
    @album = Album.find(params[:id])
end

You can change :id to almost anything as long as you remember to change it in the controller and in the views where the URL is generated e.g. when using link_to. I recommend you use :id as that is the convention.

Very High Level Language – So what?

When I first heard about Python I thought this is just great. I have had to listen to countless conversations about Java vs. C# and now we have to go through it all again with Python thrown in. I know Python is older than Java, but I only came across it after C++, Java etc. Python and Ruby are described as being Very High Level Languages (VHLL). When I heard that term for the first time I thought here comes another meaningless, yet ubiquitously used acronym. At first I did not pay much attention to these languages. I was very familiar with Java, C# and PHP. I figured Ruby and Python could not be too different from these languages. And sure, I may have been caught up in some Microsoft sales propaganda…

As with many developers, it was Rails that pushed me into learning Ruby. From the start, I really enjoyed Ruby - and still do. Dynamic scripting is a real eye-opener! Although I was enjoying this new dynamic paradigm, I still did not see much value in calling it a Very High Level Language.

This all changed at SPA. I attended “Agile Development for the Web and Elsewhere: A Tutorial in Python” presented by Nick Efford. In my opinion, this was the best session at SPA. Well organised and the content was spot on. It was a 6 hour session and Nick made many valuable points. He also explained the VHLL concept in great way. This was done with the use of this simple and effective slide.

This is when I had my first real VHLL a-ha! moment. Nick had placed Python and Ruby in a different class to Java and C#! I had realised that these languages were dynamically typed while Java and C# are (mostly) statically typed. I knew I was not comparing apples with apples, but I thought I was comparing apples with oranges. It turns out that I was comparing apples with apple pie.

When coding in C# you do not need to worry about the low level details that a C programmer needs to be concerned about. Similarly, when programming in Ruby you should not be concerned about the low level details that a C# programmer needs to worry about. Most of us are aware of the low level details a C programmer is faced with e.g. garbage collection. Now what low level details are there at the C#\java level? We can explore this with a simple example.

Ajax Fundamentals - Part 2

Index | Part 1 | Part 2 | Part 3 | Part 4 | Part 5

2. Ajax Communication

2.1. Handling the Server Response

The XMLHttpRequest object is used to receive the sever response. Two methods are used, namely responseText and responseXML. The responseText method returns text and the responseXML returns an object that can be parsed as a DOM object.

The responseText is limited however its functionality can be enriched when combining it with the innerHTML property. This is a simple method of including dynamic content within the page. The following code is a selected code extract from an example supplied by Foundations of Ajax.

function startRequest()
{
    createXMLHttpRequest();
    xmlHttp.onreadystatechange = handleStateChange;
    xmlHttp.open("GET", "innerHTML.xml", true);
    xmlHttp.send(null);
}
function handleStateChange()
{
    if(xmlHttp.readyState == 4)
    {
        if(xmlHttp.status == 200)
        {
            document.getElementById("results").innerHTML =                 xmlHttp.responseText;
        }
    }
}
</script>
</head>
  <body>
    <form action="#">
      <input type="button" value="Search for Today's Activities" onclick="startRequest();"/>
    </form>
   <div id="results"></div>
  </body>
</html>

The above example refers to “innerHTML.xml”. This is a document that contains HTML tags that define an HTML table. When handleStateChange executes, an HTML table is embedded between within ‘results’ div tags and a table will be displayed.The innerHTML property is not a standard therefore not all browsers offer the same support. Microsoft Internet Explorer restricts innerHTML property to read only on certain elements. Using the W3C DOM is the preferred method for manipulating the web page. In order to use the W3C DOM the script needs to extract specific data from the server’s response. Selecting data from XML is far simpler than finding the data in plain text. The script can use responseXML to receive a response in XML format.The responseXML method returns an XML object that meets the W3C DOM specification. This standard is supported by most modern browsers. Using the API provided by DOM, the script can traverse the XML document. The following code shows an example of this.

function showArtistAlbums(artist)
{
    var artistname = artist;
    var xmlDoc = req.responseXML;// req is an XMLHttpRequest object
    var node = xmlDoc.getElementsByTagName(artistname)[0];
    var albums = node.getElementsByTagName("album");
    var result = artistname;

    for(var i = 0; i < albums.length; i++)
    {
        result = result + "\n * " + albums[i].                         childNodes[0].nodeValue;// Retrieves the text value
    }
}

The objective of Ajax is to modify only relevant parts of a web page without refreshing the entire page. This eases the load on the web server and provides a better user experience. Performing these ‘precision updates’ is possible by making use of the W3C DOM. Foundations of Ajax gives a good example of dynamically appending rows to an HTML table. A Sample of the code is shown below. Note that the tbody tag is used, in this case the tbody element has an ID equal to “resultsBody”.

function addTableRow(address, price, comments)
{
    var row = document.createElement("tr");
       var cell = createCellWithText(address);
       row.appendChild(cell);
       cell = createCellWithText(price);
       row.appendChild(cell);
       cell = createCellWithText(comments);
       row.appendChild(cell);
       document.getElementById("resultsBody").appendChild(row);
}
function createCellWithText(text)
{
       var cell = document.createElement("td");
       var textNode = document.createTextNode(text);
       cell.appendChild(textNode);
       return cell;
}

Ajax Fundamentals - Part 1

Index | Part 1 | Part 2 | Part 3 | Part 4 | Part 5

1. Introduction to Ajax

On the 18′th of February 2005 Jesse James Garret introduced the term Ajax in an article called “Ajax: A New Approach to Web Applications“. That article explained that Ajax is an acronym for Asynchronous JavaScript and XML. It is a way of using existing web-based technologies to provide a rich user interface to websites. It is a design pattern and not a new language and it is not a W3C standard.

In his article, Jesse Garrett lists the properties of Ajax:

• standards-based presentation using XHTML and CSS
• dynamic display and interaction using the Document Object Model
• data interchange and manipulation using XML and XSLT
• asynchronous data retrieval using XMLHttpRequest
• and JavaScript binding everything together

In order for a classic web page to respond to a users input, an HTTP request needs to be sent to the server. The server processes the input and replies with an HTML page. Thus the entire page needs to be reloaded in order to provide a response to the user. This request/reply model can be tedious for a user. Ajax proposes a different model.Using the Ajax method a script can send asynchronous HTTP requests from the browser to the server. The script is notified when the response arrives at the browser, and can process the response. Units of data can be requested and processed without the user being disrupted by a complete page refresh. Garrett provides a graphical depiction of the Ajax model in the following image.

Ajax Fundamentals - About & Index

Index | Part 1 | Part 2 | Part 3 | Part 4 | Part 5

About This Series

Silverlight, Apollo, JavaFX have spurred another wave of Rich Internet Application discussions. I came across an interesting interview with David Heinemeier Hansson, the creator of Rails.

In this interview Hansson states: “We went through this with Java applets, they were going to rule the Web. Everything was going to be in a Java applet. HTML and CSS is history. And Flash came around, and Flash started focusing on applications. Now Flash is going to rule the Web and HTML and so on is yesterday. Now, Silverlight, Apollo, JavaFX, they’re all bidding to take over the JavaScript, HTML and CSS [spaces], and I just don’t buy it.”

Hanson also made this comment: “I think that there are misconceptions going on from people who are pushing these alternative delivery platforms that somehow Web developers are hungry for richer and richer experiences, that they’re really unhappy working with HTML and CSS. And that’s just not true. We’re not clamoring to re-create the desktop on the Web.”

Hansson makes a good point, developers will not be throwing away HTML and CSS any time soon. Therefore I have decided to create this series to explore the different facets of developing with Ajax.

Index

Part 1
1. Introduction to Ajax
2. The XMLHttpRequest Object
2.1. The Document Object Model
2.1.3. DOM Levels

Part 2
2. Ajax Communication
2.1. Handling the Server Response
2.2. Parsing Parameters in the Request
2.3. JavaScript Object Notation

Part 3
3. Security Issues
4. Disadvantages
4.1. Usability Problems
4.2. JavaScript Disabled
4.3. Search Engine Indexing

Part 4
5. Development and Debugging Tools
5.1. Documenting JavaScript
5.2. Firefox Tools & Extensions
5.3. JavaScript Syntax Checking
5.4. Compression and Obfuscation

Part 5
6. Summary

 

Index | Part 1 | Part 2 | Part 3 | Part 4 | Part 5

Beginners Tutorial: Routing in Rails 2.0 (with REST) - Part 2 of n

Part 3

Thank you to all of you who took the time to give me feedback on part 1. Most of the feedback was positive. A friend of mine suggested that I drop the sound effects and stick to the subject matter, I graciously accepted his advice. Therefore this post should have a better fact to fluff ratio than the previous one. On that note, let’s begin…

Part 2

In part 1 we learnt that the routing system has two main functions:
• Interpreting a request URL
• Generating a request URL
Rails uses the same routing rule to interpret a URL and to generate a URL.
Note that routing rules are often called routes, I will use the terms interchangeably.

Now we will start fixing our music_store application from part 1.

Beginners Tutorial: Routing in Rails 2.0 (with REST) - Part 1 of n

Part 2

About this series

This is a series for beginners wanting to learn about routing in Rails 2.0. This first post is aimed at exploring the behaviour of routing in Rails. It examines what happens when the routing system is given a certain URL. Future posts will examine the ‘hows’ and ‘whys’ of this behaviour. The plan is to start with the basics and move towards the advanced topics. There is only a brief mention of RESTful routing in this post. I plan to delve deeper into that topic at a later stage.

I will continue with this series only if there is a demand for further posts, and if time permits. If nobody is interested, then I will come up with a new topic and start pestering the world all over again!

Introduction

The routing subsystem is at the heart of a Rails application. By looking at the following image, we can see the role of the routing system.

The diagram is a modified version of a diagram found in Flexible Rails.

As the picture depicts, in a Rails application the process begins with a request from the browser. This request is passed into the Rails routing system. The routing system examines the request and is able to determine the following information:

• Which controller to instantiate
• Which action (method) to invoke on that controller
• The parameters, if any, to pass into the action

When receiving a correctly formatted request URL the routing system will instantiate the specified controller, call the appropriate action and pass in the supplied method parameters, if required. The controller will then perform the necessary action and Rails will render the relevant view. This will result in the browser receiving a response and the round trip is complete. This is oversimplified, but it does show the importance of the routing system.

If the request is not in the correct format the routing system may not be able to infer the correct action to take. Therefore it is important that the format is correct. We are in luck as the Rails routing system also helps us to generate requests in the correct format.

In short, the routing system has two main functions:

• Interpreting a request URL
• Generating a request URL

The routing system performs these functions by using routing rules, defined in Ruby code as opposed to XML. The rules can be found in the config/routes.rb Ruby file. Each rule is used to both interpret and to generate a related request URL.

I could go into more theory here but, as with many things, the best way to get to grips with routing is to do it!