Wednesday, August 29, 2007

The Rapid Development Revolution

The way in which we design web sites is changing. We are constantly be faced with tighter deadlines, more functionality, quicker turn around on changes. The ones who can turn the sites around quickly are the ones who will dominate the market. There is no reason why this cannot be done. There are many products that currently exist that allow engineers to bring sites to market quicker then ever before. Turn around of weeks instead of months is more typical. Repeating the development process for ideas that have already been fleshed out insane. Why reconstruct every project that is within your company over and over continuing to eat resource when you can leverage the time it takes to build a site?

Many times software is considered to be a reoccurring cost in the process of staying competitive. This does not have to be the case. Software can be a fixed cost if it is done well up front. There will always be some modifications that need to be made along the way, but why do these modification need to take so long? We should be able to make software a one time cost then the only maintenance required will be the investment into new ideas.

However, in order to accomplish this process it requires an initial investment to restructure something in a way that will be maintainable. The applications that lead to this easily being done will be the ones that survive. This is the software development revolution where everything will be light weight, modifiable and maintainable. These new application will save time and money in the software engineering process. Rails needs this application process to enable rapid development of dynamic content. In walks the rapid development Ruby on Rails environment from ACE computing.

Tuesday, August 28, 2007

Ruby Cannot Compete

Let me start by saying that I am a Rails advocate. I would like nothing more then to see Ruby on Rails succeed in the market place. There are some issues that Rails is currently having in bridging the gap into mainstream technology. Mainly the trouble Rails is having is with the competition.
Ruby on Rails is in direct competition with Java, .NET, PHP, PYTHON etc... That means that Rails must have some characteristic that sets itself apart from all of these technologies. Let us take inventory of what Ruby on Rails has:

1. A fun way of programming
2. A language designed for web programming
3. A full scale deployable web based framework
4. Platform independence
5. Some fairly cool tools
6. Obvious academic support
7. Community support

These seem to be the building blocks to an enterprise framework, without the enterprise. If you go onto any job board and look for jobs in Ruby on Rails, then most likely you will only find a few. Most of the companies that are hiring Rails developers are the true early adopters of the Rails framework. Some are catching on, but there needs to be something that Rails offers that no other enterprise level application design framework can offer.

What Rails lacks is a true enterprise mentality. Yes, it has the community support from all us high techies, but it does not have the simplicity that will allow everyone else to use our new tools. I believe we are so scared now that our jobs will be sent to India that no one wants to make Rails to easy to use. We like Rails and want to make sure we will have fun for some time to come.

The web design community needs a new process. The old process is time consuming and reuse is extremely costly. Even working in Rails reuse has been extremely difficult due to the following problems.

1. Lack of packaging support
2. No point and click module installation.
3. Lack of a great link mechanism
4. Lack of generator support. (Yes there are generators, but we could do so much with them)
5. No point and click gem installer? (speaking out of umm here, but I have not heard of any)

Let’s bridge the gap between early adopters and enterprise acceptance of Ruby on Rails. Who is down?

Monday, August 27, 2007

Chaos on Rails

I fear that Rails may succumb to certain pressures that will make bring the framework to mass market very difficult. These are the same pressures that effect PHP, Lisp, and Python. PHP, Lisp and Python are early adopter dreams. The technical intellectuals will say that there are qualities about each of these languages that make them technically superior and they are in some ways. However, techies do not worry about whether their favorite platform will ever bridge the gap between early adopters and mainstream industry. The main focus is simply to make the platform as easy to use for the their own purposes That is why the core of these frameworks, the syntax, simplicity of the difficult tasks are the key to why these systems are used by the truly technical superiority.
However, the technical superiority is not very good at understanding that there are other people in the world who may need to use these systems in the future. Once a system is designed and built it must be then deployed and maintained. Many times the systems that are built that require so much logic and complexity are also very expensive. So why can we not harness the power of these technically superior system and allow the little guy to play nicely too? With a good framework in place that will allow people to harness the power of the framework while allowing everything to be easy to use, we can shape the future of internet design.

Saturday, August 25, 2007

Excellent Rails Applications

Ruby on Rails is not quite ready for the enterprise. What Ruby on Rails lacks is the ability for beginning or average users to modify the system without affecting the underlying applications. In all other enterprise development frameworks there are ways for designers to interact with the environment without knowing anything about the underlying structures. Ruby on Rails needs this approach of development before it can be widely adopted.

Most enterprise web applications contain both static and dynamic content. The static content in a Ruby on Rails application is difficult to maintain separately from the core application. The dynamic portions can be modified in almost any manner. However, when static content changes the core application has to be modified. Ruby on Rails makes extensive use of partials and layouts. Currently there is no standard interface to separate the designer from the developer. There are modified formats to HTML but many great designers do not even know HTML well.

Introducing the Enterprise Rails Design Framework and my series on configuring Rails for the Enterprise. This framework is designed to allow a separation between design and development efforts while providing the first well rounded component design process. This framework introduces a new way of handling custom plug-ins and managing content that drives the static portions of a web site. This application is mandatory to build enterprise web application for Ruby on Rails.

It is commonly accepted that the best design and development are two independent skills. Most designers concentrate on the look and feel while developers work on the architecture. Ruby on Rails will be ready for the enterprise when both of these skills can be used seamlessly. This means that designers must be able to use the components created by the developers in a point and click manner.

In the Enterprise Rails Design Framework we will realize Ruby for the Enterprise.