Posted by Timothy Fisher
Mon, 17 Mar 2008 01:11:00 GMT
Heroku is a web application that provides a complete environment for writing Ruby on Rails powered web applications. With Heroku you get both a development environment and a hosting platform. Each application that you create with Heroku is also assigned a unique URL that you can use to access it.
Heroku has plenty of gems and Rails plugins pre-installed and available to any Rails application. However, if you want to use a gem or plugin that is not already installed, you can do that also. It is simple to install any gem or plugin into your Heroku Rails application. You can also upload a complete Rails application that you developed locally, into the Heroku environment. The opposite is also possible. You can export an application that you developed inside of Heroku and download its source to your local computer. As you write migrations, they are automatically detected and run without any manual intervention. You also get a built-in console for running any rake tasks that your application has. A built-in Rails console is also provided in a browser window.
Heroku also recently added an API that allows you to develop your Rails application locally on your computer and deploy to Heroku remotely through the Heroku API. The source code version control system that Heroku uses to store your source code is also exposed. The version control system used is GIT. If you have GIT installed locally you can directly access your application’s source code and make commits against it. When you want to deploy back to the Heroku servers, you do that through the Heroku API.
Heroku is probably not the host you’d select for deploying a production Rails application, but it can be a satisfactory development environment, and an excellent platform for learning. In a training environment, students would be able to develop a complete Rails application using only the Heroku web application without having to install any software on their computers. It is also easy to collaborate on an application using Heroku. Once you create an application, it is easy to add other users as collaboratorsruby who also have access to the application’s source code. Overall, I think this is a great tool that can help more people get exposure to the Rails platform.
Tags rails, ruby | no comments
Posted by Timothy Fisher
Sun, 09 Mar 2008 03:54:00 GMT
I tend to read a lot of technical books. My current passion is with the Ruby programming language and the Rails web application framework which is built on top of the Ruby language. I’m also a published technical author myself. The book that I am currently writing is the Ruby on Rails Bible which will be published by Wiley this spring. However, since that is a few months away still, I thought I’d share some reviews of some current Rails books that I find to be excellent learning and reference resources. The three books that are reviewed here are:
Two of the books RailsSpaces, and The Rails Way, are in the Professional Ruby series. Obie Fernandez, author of The Rails Way is the lead editor for that series.
Rails Space
This is a book that walks through the complete implementation of a social networking web application developed with the Rails framework. A hosted version of the application developed throughout this book is available online at www.railsspace.com. The authors of this book are Michael Hartl and Aurelius Prochazka.
This book is essentially an extended tutorial that
is developed throughout the book. Some of the topics touched on while developing the Rails Space application are user
authentication, image uploading, geo data, email integration, Ajax, and Restful development. As the application is written,
tests are also written as each component of the application is finished. This provides excellent practical material on writing
tests for your own Rails applications. You’ll find many of the techniques that the authors show you for creating tests and
testing various pieces of the code to be very useful in your own projects.
Overall, I found this to be probably the best book available of its type, that is a book which serves as a tutorial focusing
on the development of a large sample application. I highly recommend this book to any developer getting started with Rails.
Even experienced Rails developers will enjoy this book.
The Rails Way
This book provides probably the most complete coverage of the Rails framework of any book currently out. This book is also the first book that I am aware to provide coverage of Rails 2.0. The author of this book is Obie Fernandez whom is one of the most respected Rails developers in the industry. Obie recently started his own Rails consulting firm, Hash Rocket.
The book provides excellent in-depth coverage of a wide range of technologies related to Rails development
including Rails core technologies like Controllers, ActiveRecord, ActionView, the Rails routing system, Helpers, REST,
Ajax, Session Management, Authentication, ActionMailer, ActiveResource, Rails Plugins and Testing. Technologies that are
complementary to Rails are also covered in-depth including: testing with RSpec, Capistrano, background processing,
plugins, and production configurations. The chapter on production configurations provides an excellent overview of what is
necessary to get a Rails application running in a production environment. It includes example configurations for Mongrel and Nginx
for serving your application and Monit for monitoring your application.
Unlike some other Rails books, this book assumes a knowledge of Ruby and does not waste pages with a long Ruby introduction.
In my opinion, that is a good thing. If you are interested in learning Ruby, this book is not the best choice for you.
The book’s afterword is titled What is the Rails Way (To You)? Be sure not to skip that if you read the book. This
chapter provides a collection of thoughts from a bunch of Ruby and Rails developers, quite a few of whom you will have
probably heard of if you keep up with the Rails community. I found it to be a very interesting and insightful chapter.
The Rails Way is also a nominee as Best Technical Book in the Jolt Awards competition.
Overall, if I could buy only one book about Rails, this would be the book.
Practical Rails Projects
This book takes the reader through several practical examples of web applications that showcase the features of Rails.
The book provides a very practical way of extending
your Rails development knowledge once you’ve mastered the basics of Rails development.
The author of this book is Eldon Alameda. The applications that you will build over the course of the book are:
- To-Do list manager
- Exercise/Fitness tracking application
- Blog
- Gaming community site
Like the other books I’ve included in this review, no pages are wasted on a Ruby introduction chapter. Instead this
book assumes a knowledge of Ruby and jumps right into building each of the sample projects.
Throughout the course of implementing these applications, you’ll use several popular Rails plugins as well as some
features from popular JavaScript frameworks, YUI, and ExtJS. These JavaScript frameworks are excellent compliments
to the Rails framework. The book is best read from start to finish, as in some cases each of the projects builds on functionality
or features developed for an earlier project.
This book does include unit testing as well, though it does not emphasize it as much as the Rails Space book does. Some
of the technologies that you’ll see in this book are: developing web services, Restful development, graphing, caching,
and file upload. Some of the plugins that you’ll use throughout the course of the book include: acts_as_authenticated,
calendar_helper, restful_authentication, css_graphs, ziya graphs, will_paginate, and attachment_fu.
Overall, I found this to be another excellent book that can be read from cover to cover. Both new and experienced developers
will learn something from this book.
Tags books, rails, ruby | no comments
Posted by Timothy Fisher
Wed, 06 Feb 2008 03:10:00 GMT
One of the things that any good developer strives for in the development of a web application, or any application for that matter, is a well organized code-base with consistent use of patterns and naming conventions. This contributes a great deal to the overall maintainability of an application. However, maintaining a well defined organization and consistency to a code-base especially one that is being worked on by multiple developers is not an easy task. In web development, there have never been any widely accepted patterns for how to name models, controllers, and their action methods. Developers are often not sure when looking at a code-base where they should put a new action method and how that method should be named. If this is a problem that you’ve faced, RESTful development is definitely something that you should be interested in.
Recently, there has been a surge in popularity for a development pattern or technique known as RESTful development. Popular frameworks such as Ruby on Rails are fueling popularity of RESTful development. The creator of the Rails framework, David Heinemeier Hansson, is a great proponent of RESTful development. David introduced RESTful development to the Rails community in his RailsConf keynote address of 2006, titled A World of Resources. In that keynote, he challenged developers to embrace the constraints of RESTful development. With the release of version 2 of the Rails framework, RESTful development has become the standard way of creating a Rails application. So what is RESTful development and why are developers excited about it?
The term REST was coined by Roy Fielding in his Ph.D. dissertation. Roy Fielding was also one of the creators of the HTTP protocol. REST stands for Representational State Transfer. REST describes a method of architecting software built around the concept of resources. REST happens to be a very good fit for web application development. Although REST itself is not explicitly tied to the web or web application development, it is within the context of the web and web applications that we will discuss it. Within the REST architecture, requests from the browser use standard HTTP methods to manipulate the application’s resources. Most web developers are familiar with just two of the available HTTP methods, the GET and POST methods. However, the HTTP protocol defines eight methods, GET, POST, PUT, DELETE, HEAD, TRACE, OPTIONS, and CONNECT. REST is concerned with the first four of these methods, GET, POST, PUT, and DELETE. These are the methods that a RESTful web application will use to manipulate resources. REST happens to be a very good fit for database-backed web applications. In a database-backed web application, resources map well to models, which in turn map well to database tables.
In a traditional web application developed in a framework such as Rails, a request would specify an action and a resource to perform the action on. For example, the following is a common URL found in a Rails application:
http://www.myapp.com/book/show/5
This URL tells the Rails backend to use the show method of the book controller to display the book resource that has an id of 5. An application developed using REST would not specify the action in the URL. Instead the URL would specify only the resource. The action is determined by the HTTP method with which the request is submitted. For example, a RESTful equivalent of the above URL would be:
http://www.myapp.com/book/5
This request would be submitted using the HTTP GET method and routed to the correct method, show, based on having come from a GET request. Let’s expand on the example of manipulating a book resource and look at how you would perform other actions on a book resource using RESTful development. The table below shows how various actions performed on a resource are mapped to URLs and HTTP methods.
| Action |
URL |
HTTP Method |
| show |
http://www.myapp.com/book/5 |
GET |
| destroy |
http://www.myapp.com/book/5 |
DELETE |
| update |
http://www.myapp.com/book/5 |
PUT |
| create |
http://www.myapp.com/book |
POST |
Notice that the URL for performing show, destroy, and update on a resource is identical. These requests are routed to the correct controller action based on the HTTP method that is used to submit them.
So the idea is that you would apply this pattern throughout your web application’s architecture. Every controller would consist of the same standard set of methods show, destroy, update, and create. The application framework will route to the correct method based on looking at both the URL and the HTTP method used for incoming requests. Suddenly, you have great consistency in your web applications. All of your controllers are implemented in the same style and contain the same set of methods. You may be thinking about now that it is not very likely that you can actually implement an entire web application using just resources with matched controllers and that small set of controller actions. You may find that you need a few additional controller methods, but you will be surprised at how far you can get by consistenly following this pattern. You will find that this architecture will also clean up your controller and model designs. It will become clearer based on what you need the web application to manipulate what the correct models/resources are for your application. Keep in mind as you develop that not every resource will necessarily be backed by a database table. You may have resources that are not persisted in the database, yet you still follow this same resource/model matched with a controller implementation pattern.
Some advantages of RESTful architecture
So what are some of the advantages that you get from using this RESTful development approach?
Well Defined Application Design - RESTful architectured defineds a standard way of implementing controllers and access to models in a web application. Applications that consistently follow this architecture will end up with a very clean, very maintainable, and easy to read and understand code base. Traditionally when you have a web development project that is worked on by several people maybe not all concurrently, each may bring his own style of how they use controllers, what names they give to controller methods, what they determine are models, etc. The RESTful approach will make it much easier for every developer that comes onto a project to maintain a very consistent implementation style and thus preserve a solid architecture across the application.
CRUD-based Controllers - controllers map 1-to-1 to each of your models. Each controller contains the code necessary to manipulate a specific model through standard CRUD methods, create, show, update, and destroy.
Clean URLs - Because URLs used in a RESTful appplication represent resources and not actions they are less verbose and always follow a consistent format of a controller followed by the id of a resource to manipulate.
One of the advantages listed above, Well Defined Application Design, brings to mind an excellent quote made by Jonas Nicklas on the Rails mailing list and repeated in The Rails Way which is this: ”Before REST came I (and pretty much everyone else) never really knew where to put stuff.” With a RESTful architecture, you know where to put your code. Every application that implements a RESTful architecture will have a consistent design and developers will know exactly where to put code.
REST as a Web Service architecture
While REST is an excellent fit for database-backed web applications, some would say it is even a stronger fit for web services. The REST architecture provides an excellent platform for providing services. Afterall, web services are essentially APIs that let you manipulate some form of resource. Rather than create another layer on top of HTTP, such as the SOAP web service protocol does, REST based web services rely on the existing functionality of HTTP to provide web services. Because REST uses what is already built-in to HTTP rather than layering another semantic layer on top of it as SOAP does, REST is a much simpler architecture for implementing web services. The most popular consumer facing web services such as those provided by Amazon, Google, Yahoo, and others all offer a REST based interface. REST is more popular than SOAP today for implementing commercial web services. For example, considering the book example again, you could easily imagine a web service API that used URLs identical to that which a browser uses to get HTML content. This gets into the next topic of interest related to REST, that of Representation.
REST and Representations
When you request a page using a RESTful architecture, the page that is returned can be considered a representation of the resource that you are requesting. However, think of an HTML page as just one possible representation of any given resource. Other representations might include an XML document, a text document, or a block of JSON encoded JavaScript. Using the RESTful architecture, you would request a different representation of a resource using the same method, but by passing a different piece of metadata to the server indicating the representation that you would like to have returned. For example the following two requests would both be routed to the same controller and action method:
http://www.myapp.com/book/5
http://www.myapp.com/book/5.xml
The first request would return an HTML representation of the book resource. The second request would return an XML representation of the book resource. This is another advantage of a RESTful architecture. The same controllers and actions can be used to deliver a variety of response representations, think HTML, RSS, XML, etc. This makes implementing web services in a RESTful architecture extremely easy, and again maintains a consistent design style.
So, that about wraps up my overview of RESTful development. Hopefully you’ve been able to learn from it.
Tags architecture, programming, rails, rest, restful, web | 3 comments
Posted by Timothy Fisher
Mon, 21 Jan 2008 16:58:00 GMT
Over the weekend I finished reading the book The Rails Way. I actually enjoyed this book so much that I took the time to read it cover to cover. As good as this book was, it is not specifically the topic of this post. The last chapter of the book contains a series of statements by a bunch
of developers who have grown to love Rails. They explain what it is they like about Rails. Each of the statements is interesting, some more so than others. One of the very last statements, written by Nola Stowe, talks about the lack of community across languages and using the right tool for the job. This is what I want to talk about with this post.
Developers who speak extremely highly of a single language while criticizing other languages are being very closed-minded and are shutting themselves off to some great learning opportunities. Once you’ve mastered any given language, and even before you’ve mastered a language, one of the best ways to continue to grow your expertise of that language is to learn and study a new language. You may look at how something is done in a different language and that may inspire you to rethink how you are doing things in the language that you love. The Ruby on Rails framework is a great example of how implementation ideas in one language can influence many other languages. The Rails framework is one of the most innovative web applications to come along in any language. Rails introduced a simple way of building web applications using DSLs, convention over configuration, code generators, and a robust object relational mapping layer. Much of the core architecture of Rails has since been implemented in almost every other language that is used to build web applications. Frameworks in other languages such as Grails, Cake, Django and others all have borrowed ideas from Rails. Also, this borrowing of ideas is not a one way street. Rails was not designed in a vacuum either. While it is true that Rails did alot of new things, it too borrowed ideas from other frameworks and languages.
Consider PHP, this is a language that is routinely criticized as a language that creates some really awful applications that are full of spaghetti code. Is this the fault of the language? Of course not. PHP brought web application development to the masses and I’d venture to say that those developers that create spaghetti code applications with PHP would do no better in a different language. PHP5 actually introduced a pretty good object implemenation to the language and a good developer can write very good applications in PHP, just as a good developer can write good application ins Ruby, Java, or C#. Are there things that a Java developer can learn from PHP? I think so. I believe that each and every new language learned can teach you something.
Too often when you look for language comparisons you come across alot of articles, posts, and other content that praises one language and attacks other languages. If your a Ruby or Railis developer, you’ve probablyl seen the photo of the stack of books that someone put online a couple years ago. The photo shows a large stack of Java books sitting next to a stack of two Ruby and Rails books. The idea behind the photo being that Java is so complicated it requires tens of books to fully understand, while with Ruby and Rails you can get all you need with 2 books. Such a picture wouldn’t fare so well today. I’d venture to say that today Ruby and Rails related books are coming out at an equal or faster pace than Java books. Having alot of books out about a language and its various frameworks and libraries is in my opinion a positive thing. Java has a huge open source following and there are libraries available for Java that do almost everything you want. Having books available about these frameworks and libraries is not a bad thing and does not in and of itself make developing with the language more complex. With the surge in popularity that Rails brought to Ruby, the libraries are gettin better for Ruby but they still can not compare with what Java offers. In a similar vein, more recently there have been a series of videos that promote Ruby while mocking another language. These types of language hype may be entertaining but they are detrimental to the software development community at large in that they usually only breed more distrust and negative feelings across specific language communities. I believe that anything that discourages a young developer from learning a new language is a bad thing.
In the enterprise consulting world, you often hear that comment that such and such company is a Java shop, or a .Net shop, meaning that everything they do is in that language. I think that being characterized as a Java shop or a .Net shop, or a Ruby shop is not something a company should be proud of. For example, Rails has shown tremendous productivity improvements over other languages when developing database-backed web applications. A company that traditionally builds all of their applications in Java or .Net would be foolish to simply ignore this fact because they are a Java shop or a .Net shop. Similarly, Ruby is one of the coolest languages to be using right now. It has a dynamic and rapidly growing community, and the hottest framework on the planet in Rails. However, a project may come along for which there is an existing library implemented in Java which would allow you to complete the project quickly using Java, whereas in Ruby you would have to write this same library. Don’t choose to use Ruby because it is cool or the funnest language to use right now. Use a language because it makes sense for the projects your team is working on. JRuby brings even more interesting twists and scenarios. With JRuby it becomes easy to combine Java and Ruby on the same platform and within the same application. You could use the wonderful Java libraries while writing your new code in Ruby.
Neal Ford speaks of something he calls Polyglot programming. Polyglot programming is the concept of using many different language together even on a single project. The idea is that you should always be focused on using the best tool for the job. Today it is actually rare to write a web application using a single langauge. Your business logic may be written in Java, but consider other languages that you probably use without a second thought, JavaScript, SQL, perhaps a Perl script or too for maintenance tasks. The two primary platforms of today, the Java platform and the .Net platform, are both able to support a growing number of languages. For example the Java platform today supports Java, Ruby, Groovy, Scala and probably a bunch of lesser known languages. Each language may have strengths in a given area. Don’t be afraid to mix and match your languages even on a single project. Use the best tool for the job at hand. We should all be Polyglot programmers. Every good developer should expand their knowledge of languages beyond the one or two that they feel comfortable using. Even if you continue to use a single language, you may find a whole new way of thinking about that language when you’ve studied other languages.
Don’t let positive or negative hype turn you off from learning a programming language that may be outside of your comfort zone. I know that at first glance Ruby can seem very different to Java programmers. It is a dynamic, scripted language and that is a different world to many Java developers. I had been doing Java development for nearly 10 years before I learned Ruby. Now I advocate for Ruby every chance I get. I have not met too many developers who have given Ruby a real trial and have not come away with a positive experience, even if they choose not to use Ruby going forward. So in summary, don’t choose a language simply because thats what your company has always done or because thats the only language you know. I agree that those may in fact be important factors in what is the best choice for your team, but evaluate your optioins and use the right tool for the job.
Last week I attended a conference in Ohio called CodeMash. The theme of this conference is to bring together developers with different programming language backgrounds and have them learn from each other. I think the concept of the conference is wonderful. This is the second year that I’ve attended it and I will continue to do so in the future. We need more community across languages as opposed to just single language user groups and conferences. It would be great to see more user groups of different languages hold combined meetings with topics that are common to multiple languages. I think both groups can learn alot from each other.
Tags java, languages, php, programming, rails, ruby, .net | 2 comments
