Crowd Interactive is an American web design and development company that happens to work in Colima, Mexico. We develop awesome applications for commerce and social sites using Ruby on Rails. In the future (and the future is now), all important apps will be social apps. It’s not that there will be a million Facebooks, but that the features found on Facebook – tagging, comments, newsfeeds – will appear on millions of sites. If you want the power of the crowd, work with the experts at Crowd Interactive.
Customer Quotes
We make existing sites and applications ‘People Powered.’ Add these features to your site:
For those of you that may be new to ruby and rails, it's important to get a handle on RoR best practices, so you can start really experiencing the value of stack without all of the pain and embarrassment that comes from messy code. I'm going to highlight a few such best practices here, and I hope you find them useful!
Don't Repeat Yourself
Most of us have heard of the DRY principle. It is something Rails has taken to heart. By not repeating yourself you can freely change something in one area of the program without worrying if you need to make the same change in another area. Not only that, but keeping the code DRY usually leads to better design.
Sometimes it is difficult to find duplication in your code. If you find yourself making a similar change in multiple places, you should first remove this duplication so you only need to make the change in one place.
This principle should not only be followed in code, but in your database and other areas as well. If you are repeating logic or data in the database, consider changing the design so it is not repeated. The core value of this principle is a better software architecture that is more maintanable in the long-run.
That said, there are times when repeated data is good. For example, if you are building an ecommerce system, the price for the items in the cart should be stored in a separate field than the price for the product. This allows you to change the price of the product without effecting all previous orders.
Stick to the Conventions
Another extremely important practice taken up by the Rails community: stick to the conventions. From naming variables to structuring files, there are conventions on how to do these things in Rails. If you are unsure of the conventions, check out a Rails book or tutorial - most of them stick to the conventions.
The advantages of sticking to conventions are almost too numerous to count. In fact, it deserves its own article.
Optimize Later
Performance is a major concern for many people switching to Rails, and rightly so. It is true that Rails is generally slower than other web frameworks. However, it is very scalable, so do not worry about it at the beginning. If you are a large corporation that needs to handle thousands of requests per second, then you may have something to be concerned about, but for the majority of us performance does not need to be considered until near the completion of the application.
Any optimization done early requires guessing. Instead you should wait until you know where the real bottlenecks are. That comes through having real users on the site, and understanding what their usage patterns are. Optimizing usually requires extra/complex code, and you should keep the code as clean and simple as possible. Therefore, only optimize where necessary. Also, any performance testing should be done in the production environment, as this adds some optimizations which are usually turned off in the development environment.
Above all else, don't let fear of poor performance inhibit you from making good design decisions! There are usually good ways to optimize while still keeping the good design, but these ways are hard to see unless you have a good design already in place. In short, don't worry about performance while designing.
Humans First
Code for humans first, computers second. In other words, make the code as readable as you can. No, I'm not talking about cluttering it with comments. Most code should be understandable without comments.
How do you make the code more readable without comments? Rename variables, move code into classes/methods, etc. Try to give variables and methods concise, yet descriptive names. Do not abbreviate the names unless the abbreviation is very common.
Test Driven Development
You've heard it said: "Rails makes testing easy, so you don't have any excuses not to do it.". Well, in my opinion, testing is never easy - it is just easier in Rails.
Seriously, if you have not tried test driven development, give it a go. Automated tests are a godsend! I find myself rarely going to the web browser anymore to test things out. I just know it works because all of the tests pass. I wouldn't dare code a mildly complex application without testing anymore. It will take some time to get used to testing, but the benefits are far worth it.
Refactoring
Refactoring ties all of the things in this list together. Simply put, if you want to become a better programming, learn Refactoring. Normally the first time you write a piece of code, it is messy. Whatever you do, don't leave the messy code as is. Even if it works correctly, it will be a headache to maintain. You should take some time to clean up the code, make it readable, and improve the design.
