On June 27th, Gonzalo ‘Chalo’ Fernández and Mario ‘Documario’ Zaizar moved from Colima to San Francisco to work onsite with our client, ModCloth. ModCloth has recently opened a new office in the west coast, and Crowd is an integral part of launching that new office.

Crowd arrived in San Francisco to help our client identify potential offices. ModCloth’s new office is an incredible space that we are sure will enable serious productivity and growth.

The Crowd Interactive guys will be working with top-class developers from the US and other countries. So far it has been a great experience for all of them, since they share knowledge and ideas, with the goal of making the end products more efficient and stable.

Chalo and Mario are also excited about knowing more local developers, so they will be attending many meet ups and conferences that are held really close to where they work at. So if you see them around, don´t be shy and talk to them. They are two awesome guys who can chat about technology, culture, gastronomy and many more things. Or you can organize a Napa Valley trip with them. We know that they will gladly join you.

This is our last week working from the fabulous Crowd Mansion, as we are almost ready to move to a new office. We have to admit that it will be difficult to leave this space because it is a very comfortable and spacious spot, but we need to take things up a notch.

Our primary reason to move is that this house is no longer working for us. We are involved in many projects and we need to be working closer together. Technology helps, but we still need real physical interaction with our co-workers.

The new office is a more adequate space because we will all be working under the same roof, with no physical barriers to keep us apart. We can coordinate faster, and in person, rather than using Instant Messaging services (that sometimes get lost or buried under many other things). At the new office we will have a general development and designing area, conference rooms, 2 areas specifically designed for English classes, private call spaces, and last but not least: a fun room.

The goal is not to change our methodology, but to enhance our Agile processes. By providing this environment we will be able to detect and communicate any impediments earlier than when the teams are separated by long halls and closed doors.

At the new office, Crowd will endorse a productive lifestyle that includes smart eating, napping, exercising, and having enough space to think through problems. Integral to that is the Fun Room, where we have the facilities for napping, meeting, and playing ping pong.

We will be updating this blog with entries that relate to how we cope in our new office, how we manage to interact respectfully and peacefully and how we feel about working elbow-to-elbow.

Development teams often fight to find the most accurate code quality measurement system which is very tricky. Recently we’ve found it. And it really works! Check it and take advantage of true metrics )

The textbook for online social marketing has yet to be written, so many of us struggle to figure it out. Meanwhile companies like ModCloth.com and Bonobos.com have grown tremendously with smart social marketing strategies. Social marketing is here to stay, so until the textbook comes out, here are some easy-to-remember tips to guide your strategy:

Blogs are for Baring it All.

While many companies use a blog to establish credibility as experts in their field, the most effective companies use blogs to just write about themselves. Surprisingly, pictures of employees at their desks, the messiest office closet, and what the founder had for breakfast are all interesting and even endearing online. People come to your blog to get to know you and your company, not to get a lecture on best practices.

Facebook is for Listening.

A Facebook Fan Page is best for companies. Consider the Fan Page an extension of your customer service. Impress visitors by responding to complaints on your wall, proving that you are listening and you care. Videos, discussion boards, and new pictures are great ways to keep the content fresh and interesting. Be warned that Facebook wall comments are really hard to track, categorize, and quantify, so don’t expect meaningful metrics. Instead, scan comments for a general sense of what the crowd is saying.

Twitter is for Announcing.

Make it worthwhile for people to follow you with flash Twitter promotions, discount codes, and super-relevant information for your audience. Do announce what your competitors are doing. Don’t be afraid to have an opinion. Don’t link your Twitter feed to your Facebook status; that’s just annoying for everyone who follows both.

Finally, the key to online success is great content and a consistent message. For great content, make sure to put good writers, photographers and videographers on the job. For a consistent message, adhere to one theme and tone throughout all posts.

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.

Make it beautiful.

The Ruby Language

Ruby is an interpreted dynamically typed object-oriented programming language. In the 1990s, Ruby remained a more or less academic project. Since many of its language constructs were adopted from Smalltalk, many of Ruby’s initial followers were Smalltalkers and language aficionados. These early adopters had a strong cultural influence on Ruby, largely in the promotion of agile development practices for Ruby projects.

Ruby On Rails

In a very few years Ruby on Rails has gained popularity in the enterprise development community. As an open source platform.Ruby was introduced as an open source programming language, publicly announced to the world in 1995. Ruby’s primary author is Yukihiro “Matz” Matzumoto.

Ruby started to see a rapid rise in visibility and popularity shortly after July of 2004 when David Heinemeier Hansson released his first version of Ruby on Rails. Rails was created as a framework to create database-backed Web applications. The first application built with the new framework was a Web-based project management tool called Basecamp.

How It Works?

The Ruby on Rails stack is similar to Struts, WebWork, or CakePHP in using a Model/View/Controller (MVC) abstraction. Ruby on Rails is a complete solution and avoids many of the hang-ups in other development platforms by applying a default set of standard practices to a new project and seamlessly integrating all of the sub components behind the scenes to provide a uniform interface to the developer.

Reasons Why ROR is worth choosing?

1:Traditionally starting a new web application is a fairly heavy weight process, you typically need to survey and choose your various software components to solve the common architectural problems of persistence, logging, build scripts, application configuration, web tier components and work flow. With the Rails framework these decisions are already made , so you can get on to understanding the business problem and quickly build a working system. You become productive in minutes not weeks or months.

2: In a Rails application, a pragmatic philosophy of convention over configuration is taken, this is apparent in all layers of the architecture with the highest productivity gains noticeable in the relationship between the model and the database. Once the developer understands the rules and constraints, Rails magically connects your view to your controller and model, and your model to the database. You don’t need generators or specialized tools to manage this, it all just works.

3: Unlike other productive web scripting languages, Ruby is a fully featured object-oriented language. Ruby also adds additional power with mix-ins modules which contain independent code to inject into your classes, blocks and closures simplifying client code behaviour. Its dynamic nature gives it power beyond static languages such as .NET and JAVA, and the benefits are apparent by how the Rails framework has been put together itself.

4: Unlike other web templating technologies, the templating technology built into Rails can be used to generate web pages, emails, xml documents or any text document that requires dynamic content.

5: Rails includes a well thought out object relationship mapping tool, ActiveRecord, which provides your answer to database persistence. Your model is seamlessly persisted to the database. Transactions, inheritance models, validation, and caching have all been thought out and are production ready. With Rails you become a lot closer to the structure of the database than traditional object-oriented development methodologies. This is a good thing as over time as the database will no doubt end up being your project’s most valuable asset.

6: Rails includes support for a variety of web technologies. Every web application needs email integration at some point and Rails provides an out of the box smart solution, and as with other Rails technologies it gives you the complete package down to configuration in development, test and production environments. Ruby on Rails also supports web services, the integration with Rails due to the dynamic nature of Ruby is simply, clean and seamless. If you are moving into the Web 2.0 space, Rails provides a rich abstracted interface to implementing AJAX operations.

7: Generally software projects do not mature if at all to the point of having a solid foundation to perform database migrations and rollbacks between environments and across development systems. However with the Rails framework you will be delighted with the implementation of database migrations for applying and rolling back database changes. You enter your update and rollback scripts in Ruby, Rails understands the current version and can move forwards or backwards to any database version.

8: For development productivity, the shorter the gap between the change and test cycle the better. In Rails, changes are reflexed immediately within the runtime environment so developers can quickly iterate between fix and test cycles without any expensive redeploys. Ruby code is also easily testable. Methods and objects can be replaced at runtime so software components can easily be tested without resorting to external tools or generators.

9: Getting started with Rails is easy as generators will propel you along. An experienced Rails developer will also become aware of numerous idioms available within the Rails framework that shared the amount of code a developer need write. Overall less code to write means lower complexity, higher productivity and less bugs.

10: Ruby has been around for a long time, the Rails framework which has deservedly propelled Ruby into the spotlight has hit version 1.1 and is production ready. Ruby and the Rails framework is open source and well supported by a clever team of contributors.

The authentication system has always been a headache for almost all developers until libraries and frameworks came to the rescue! Tons of ways to authenticate a user were developed for the frameworks of many languages, and for most of us, worrying about a hack-attempt through a login form is a thing of the past. However, since most of us now use authentication systems that were written by another programmer, it is important that we evaluate all the options, and be sure we choose one that fits our needs.

I was surfing the web recently, and found a great authentication system for Rails, one of the most used web frameworks around the world. It’s called Devise, and it is a very flexible rack-based authentication system that works on top of Warden, a general rack authentication framework for Rails. That makes Devise a great option to use.

Almost all rails authentication systems work by setting up a table with one specific model and one specific way to authenticate, either by a site-specific username/password, OpenID, email notification, or 3rd-party site account which you have already access to. Devise, since it has been developed on top of Warden, and since it has learned from the experiences of Authlogic and Clearance (two of the authentication systems most widely used with Rails), has the ability to change of strategy whenever the project needs it.

Devise relies on the 7 strategies (or modules):

Authenticatable: responsible for encrypting passwords and validating of a user while signing in
Confirmable: responsible for verifying whether an account is already confirmed to sign in
Recoverable: in case a user forgot his information, it is responsible for the process of recovering it
Rememberable: manages the remembering of a user from a cookie
Timeoutable: expires sessions in a certain period of time
Trackable: tracks sign in count, timestamps and ip
Validatable: creates all needed validations for email and password

Due to the fact that Devise was developed for being flexible, if you need to handle invitations, you just have to set up a new strategy.

One of the reason that I like Devise is because it allows Rails developers to take an agile approach. It’s flexible enough to allow us to change the authentication process whenever the client (invariably) changes their mind down the road. And it does so in a way that is simple and hassle-free.

I remember when I used to develop for the web with Python. At that time, I was involved with CMS/Portal development, and hence, we were using Plone 3/Zope 3 as a CMS platform.

Plone 3/Python deployment essentially depends on one tool, called buildout. The Python community pioneered in this sense, creating a tool to totally automate the deployment, from fetching and installing eggs and dependencies to compiling software, setting ENV vars, and even starting the server. Buildout is also not limited to the web, it was and is used for any flavor of application built with Python and its eco-system.

Basically, Buildout solves the dependency and deployment issues for Python.

So, any developer who is switching from Python to Ruby may be wondering what equivalent tools exist. Ruby has had Capistrano for some time already, but Capistrano is a different beast. It won’t solve the initial issues of deployment. The most significant difference is that it won’t install the gems. You have to setup the environment all by yourself, which is not fun.

The missing piece, as said, is the gem download and dependency resolution, which buildout does very well, but Capistrano does not have any clue about.

For Ruby, we have rake gems:install, but it can bring up some issues, like installing a gem that has been already installed globally. Or maybe you just want to install the gems globally, instead of locally for the application in question.

To make our lives easier and have more time to play with the cool stuff, now we can automate the “set up the environment and installing gems” part of the deployment process.

Gem Bundle makes things very simple. If you don’t have a complex server infrastructure, you don’t even need Capistrano and can just deploy an application with gem bundle like this:
[rails app]$ gem bundle
[rails app]$ git clone

Then, import the schema and start the server, of course. The most boring part, which is installing and resolving gem dependencies is solved though.

And if you are currently using Capistrano, it is possible also tointegrate Gem Bundle into the Workflow.

So, from now on, whenever you think about Ruby/Rails application deployment, remember Gem Bundle. Give it a try and simplify yourlife!