Today, social networking, and user-generated content web sites are among the most popular sites on the Internet getting millions of hits every day. Sites like MySpace, Facebook, Flickr, and Google Apps allow users to share user-generated content and collaborate with each other like never before. Smart organizations, enterprises, and product vendors are now realizing the potential for Web 2.0 technologies inside the enterprise.

There are some fantastic web applications on the Internet that would provide tremendous value inside of an organization. I’ve spent the last several years working for large professional services organizations. These large service organizations have perhaps the most to gain from harnessing the concepts of Web 2.0 internally. Consider for example an internal Intranet version of an application like LinkedIn, allowing employees to keep current resume and profile information online that can be easily updated by each employee. This would provide a huge value to professional service organizations whom are always looking to staff the next project or fill a clients staffing requirements.

For the developers of a large organization, think how useful an internal Code Snippets site would be. Public snippets sites such as DZone Snippets, allow contributors to share small snippets of code that solve commonly occurring problems. The value of such a repository is even greater inside of an organization where different teams often encounter similar problems. Essentially, a snippets site provides another outlet for code reuse.

In a development group, every project should be maintaining a wiki site. A wiki can be updated by every member of the team to include links to the latest documentation, schedules, and technical data related to the project.

Social bookmarking sites such as del.icio.us also provide examples of a technology that could be very useful internally. If you are in a large development organization, every developer will usually have his or her favorites sites for researching and looking up technical information. A social bookmarking site would allow your organization to harness collectively those favorites and categorize them with a content tagging system. Content tagging has become the preferred way or organizing large amounts of information in the Web 2.0 world.

Even some of the fringe social sharing sites such as Shelfari and LibraryThing implement concepts that would fit well inside an organization. These sites allow users to share information about their personal library of books. Users can contribute book reviews, book ratings, and comments about the books. Software developers are some of the largest purchasers and readers of technical books. Some organizations will even reimburse employees for technical book purchases. A social site allowing employees to share reviews and comments about technical books could be a very useful addition to an Intranet. These types of value-added applications that allow employees to actively contribute content to Intranets will encourage employees to view your Intranet and participate in sharing knowledge and information. This is much better than the centralized content controlled sites that most Intranets are today.

One of IBM’s newest products targeted at the enterprise is Lotus Connections. This is a product that aims to bring Web 2.0 and social networking into the enterprise. The product includes blogging, social bookmarking, wikis, communities, user profiles, and social networking features. IBM is not alone in thinking about the value that these products have. Smaller vendors in this space include HiveLive, SocialText, and Thought Farmer.

There are new and different types of Web 2.0 and social networking sites coming online nearly everyday. Every time I come across a new site, I always imagine how much that site could contribute to the collaboration and knowledge sharing environment and ultimately to the productivity of teams inside of a company. I believe that we are on the brink of seeing more and more Web 2.0 technologies entering the Enterprise. These applications can allow an enterprise to capture more of the ad-hoc and tacit knowledge that typically is not well managed in a large organization. If you are in a position of influence, you should start thinking now about how these technologies can make your own organization more productive. If you are interested in learning more about Web 2.0 in the enterprise, an excellent blog to follow is the Enterprise 2.0 blog from Dion Hinchliffe.

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.

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:

• RailsSpace
• The Rails Way
• Practical Rails Projects

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.

• The Basics
• Interacting with the Environment
• Manipulating Strings
• Working with Data Structures
• Dates and Times
• Pattern Matching with Regular Expressions
• Numbers
• Input and Output
• Working with Directories and Files
• Network Clients
• Network Servers
• Sending and Receiving Email
• Database Access
• Using XML
• Using Threads
• Dynamic Programming Through Reflection
• Packaging and Documenting Classes

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.

This article is cross-posted from blog.timothyfisher.com . 

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 one of RESTful developments greatest proponents. With the release of version 2 of the Rails framework, RESTful development has become the standard way of creating a Rails application. So, let's explore the question of what is RESTful development and why are developers excited about it?

The term REST was coined by Roy Fielding in his Ph.D. dissertation. It stands for Representational State Transfer. REST describes a method of architecting web applications built around the concept of resources. 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
delete	http://www.myapp.com/book/5	DELETE
update	http://www.myapp.com/book/5	POST
create	http://www.myapp.com/book	PUT

Notice that the URL for performing show, delete, 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, delete, 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, read or show, update, and delete.

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.

My next book will be coming in early spring, most likely May, 2008 from Wiley.  The book is the Ruby on Rails Bible.  The book covers the Rails framework in detail providing an overview of the Ruby programming language, an overview of Rails, detailed chapters on each of the major components of Rails and a walk-through of a complete Rails application.

The book will cover Rails 2.0.  Major chapters or sections will cover topics such as models, views, controllers, plug-ins, deploying with Capistrano, testing a Rails application, and using Prototype and Scriptaculous.  The application developed in the walk-through chapters is a Web 2.0 application that can be used by a group of users to share information about a collection of books.  It will include implementation of features such as content tagging, reviews, and ratings.

 You can pre-order the book today from Amazon or direct from Wiley.com.

My new book, the Java Phrasebook from Sams Publishing provides a great concise guide to more than 100 customizable code snippets–so you can readily code functional Java in just about any situation. The Java Phrasebook gives you the code phrases you need to quickly and effectively complete your programming projects in Java.

This book is not your massive and heavy typical Java reference book, but instead a small very focused book with short phrases for accomplishing tasks that you will probably need to perform in most Java applications. Because of its compact size, the book is great to keep on hand whereever you go.

Be sure to check out my new blog at blog.timothyfisher.com.

My new blog features expanded subject content beyond Java content.  Some of the areas of interest I have that I'll probably end up discussing at some point are eLearning, Web 2.0, online communities and collaboration, Web Development, Java, PHP, Ruby, Rails, and more.  I think that many of you who have been interested in my postings here at Java Developer's Journal will also be interested in my new blog.

This blog is not dying or going away.  I will continue to post Java related content to this blog.

Thanks,
Tim

It's been awhile since my last blog post. Where I have I been? What have I been up to? Well there are a few answers to those questions. Answer one, I've been very busy implementing an enterprise-wide web single-sign-on solution in J2EE for Ford Motor Company. Answer two, in my spare time, I've been bitten by the Ruby/Rails bug that seems to be spreading throughout many developers in the Java community and the larger web application development community as a whole.

Ruby is a highly dynamic, fully object-oriented programming language that has been getting a great deal of attention recently. The language itself is not all that new, it's been around for about 10 years. So why is it suddenly gaining tremendously in mindshare and popularity? The short answer is Ruby on Rails. Rails is an open-source MVC web application framework that has quickly captured the attention of many well known Java developers and even more PHP and Python developers. The suite spot of Rails is the set of problems that require a web front-end to be tacked onto a relational database. This is a problem that is very easy to solve using Ruby and Rails. Solving the equivalent problem in Java requires much more effort and knowledge of frameworks and the J2EE stack. There have been some widely publicized performance metrics that state how much faster it is to develop this type of application in Ruby and Rails. I don't even want to quote those though, because I don't want to spark the performance/productivity debate here. In the end, I don't think that anyone should rely on someone else's performance/productivity metrics. I believe that the developer or team of developers should try both technologies themselves and see which technology makes them more productive.

While Rails has been the catalyst recently drawing people to Ruby, I do not think that Rails is the only thing making those developers content. Once they get to know Ruby as a language, I think that many developers are finding quite a bit to like about it. Its support for closures, code-blocks, and powerful metaprogramming capabilities are just a few of the nice things about Ruby.

A new book by best-selling Java author Bruce Tate, titled Beyond Java, suggests that Java may have approached the peak of its popularity and is ripe for replacement by a more dynamic, and more productive language. Ruby is suggested as one of the possible successors to the mantle of most popular programming language that Java has held for the past many years. Rails is also discussed in Bruce's book and suggested as a possible disruptive technology that could propel Ruby to bigger and greater things.

So how do I feel about the future of Java? Well, if you are a Java developer today, I don't think you need to be shaking in your shoes or running out and finding a new job. Java has so much powerful commercial backing and gained acceptance in the enterprise market, that it will be very hard to displace anytime in the near future. Additionally, Java will certainly have a role as the language of choice for tough enterprise problems that may require interfacing with legacy databases, legacy applications, asynchronous messaging, and robust security. In order for Ruby to compete against Java more effectively in the enterprise space, I believe that Ruby needs some commercial backing, which is just not there yet today.

In a previous posting I did some months ago, I suggested that every Java developer should take the time to expand their horizons and learn other languages and see how problems are solved with technologies other than Java. Ruby and the Rails framework provide a perfect opportunity to take that advice and spend some time learning something new. It may be a valuable addition to your resume in the not so distant future.

Until next time,
Timothy

Here are some good articles to get you started with Ruby and Rails:

Four Days on Rails

Rolling with Ruby on Rails : part 1

Rolling with Ruby on Rails : part 2