Category: Ruby Tuesday

Ruby Tuesday: Scaling Rails

I’ve heard a lot of horror stories regarding Rails development and how it has trouble scaling, my verdict is still out.  I also think code can be written inefficiently in any language (I’m certainly guilty of writing SQL queries that pull in too many records).

I really enjoy developing in Rails.  I think Ruby is a very terse language and Rails is framework that helps developers achieve peak productivity.  So I’m trying an experiment with BizeeBee.  The team has been through 3 iterations.  At the end of each iteration we’ve been focused on cleaning up our code base.

For this iteration our goals are:

  1. Convert obtrusive AJAX queries (RJS) into straight JS, because we’ve experienced how slow RJS can be.
  2. Make the DB agnostic by removing straight SQL calls and instead relying on the ActiveRecord framework, because we don’t want to deal with mySQL vs. Postgres incompatibilities.

I’ve also talked to a couple people in DevOps to get their thoughts on Rails as a framework here are their suggestions:

  1. Think about  scale from the beginning because you’ll need to scale before you know it.  They seem to almost value premature optimization over no optimizations.
  2. Limit the number of joins you’re performing on your database.  This means restrict the foreign key relationships and try to de-normalize your tables early on.
  3. Think about archiving or aggregating historical data.  This will limit full table scans, and give users a richer experience when dealing with data that pertains to the present.  If you need to retrieve older datasets then you’ll need to design around it by messaging users that you’re retrieving older data.

As BizeeBee moves into the fourth iteration, I’ve started to think about how an open beta will result in more users.  David, my back-end developer, and I spend more time thinking about data modeling.  We know which tables we anticipate growing quickly, how we need to address the growth rat, and have started thinking about partitioning schemes to address the growth of data.  Currently our app is hosted on Heroku, which means we don’t have control over our partitioning scheme.  So if we do want to partition we’ll need to host the app ourselves.  But we like the ease of deployment that Heroku offers and how we can closely mirror the staging and production environments without having to configure them ourselves.

While I don’t anticipate us growing overnight, I think its good to start thinking about these problems early on.  I’ve also anticipated the need for caching in the short-term and will implement it depending on usage patterns.  As far as using a solution like NoSQL or MongoDB, my main reluctance to embrace it is the need for an ACID database, one that maintains data integrity.  I know a lot of startups have openly welcomed both, but my skepticism originates from the need to have a highly accurate system that cannot tolerate data glitches.  I’m dealing with transactional data that belongs to small business owners, and can’t afford for the service to be unreliable.

I’m curious to hear about everyone else’s experience and architecture regarding scaling in Rails and how their stack has morphed overtime…

Enhanced by Zemanta

Post to Twitter Tweet This Post

Ruby Tuesday: Pitfalls of Prototyping in Rails

My last Ruby Tuesday post was pretty laudatory regarding prototyping in Rails.  In this post I’m switching gears and exposing the pains and limitations with Rails.

The development team at my current startup is composed of engineers and designers, basically I make everyone on the team write code :D  I understand that Rails’ benefit is in thinking from an MVC mindset.  But because it integrates all components its requires that all developers have some knowledge of a high level language (Java, Ruby), front-end technologies (HTML, CSS), and an understanding of databases.  While it doesn’t require them to have depth of knowledge I think the tight coupling makes it hard to separate the layers.

The following are the three limitations I’ve been experiencing with Rails:

  1. Integration – when it comes time to integrate HTML or design changes, designers and front-end engineers need to work in the same space i.e. the same .erb.html file.  Yes I know it doesn’t require a painful and time-consuming compilation process like XMLC or Velocity.  But its easier for the designer to change the look and feel using XMLC or Velocity because they have defined a set of DOM objects.  With Rails designers have to understand views and partials.
  2. Convention over configuration – the speed of development with convention over configuration Rails seems to come at the price of normalization, meaning there  is not foreign key construct in Rails.  You as a developer are required to configure this yourself along with other database constructs like unique constraints and indexes.
  3. Deprecation – perhaps its just me, and I’m used to Java versions being released every year or two, but it seems like there are a lot of constructs that are deprecated between Rails versions.  The book publishers can barely keep up with the changes.  The other is that some of the constructs that are deprecated which I think are quite large i.e. scaffolding.

Despite these pitfalls I do advocate Rails as a prototyping platform.  The learning curve isn’t steep, and convention over configuration improves the progress developers can make in a day.  I’d also like to learn more about how people have addressed these pitfalls as their prototype matures.  What have been some of your experiences and approaches to dealing with Rails as you transition and build out the product?

Enhanced by Zemanta

Post to Twitter Tweet This Post

Ruby Tuesday: Push Button Prototyping in Rails

I realize I’ve been neglectful in posting articles on Ruby development.  So back by popular demand I’m going to make an effort to resume the Ruby Tuesday series.

For the past couples months I’ve been playing with Rails and have been building my product’s prototype with it. The last time I created a prototype for a product I wrote it in Java.  The choice to write it in Java was simply because the founder and I knew how to write Java, and were more productive in it than C++.

After that experience, I spent sometime thinking about all the pains and positives I had experienced with Java and decided it was time to explore another technology.  Initially, I just wanted to know what all the buzz around Rails was about.  Ultimately, my choice to use Rails was based on the following:

  1. Simplicity of Configuration: I started off as the only engineer on the project and didn’t want to spend a lot of time writing migration scripts, files to handle ORM, and having to setup all the mappings in a MVC framework.
  2. Support and Documentation: the Ruby and Rails community has a great number of forums where people are constantly communicating and helping one another out when it comes to resolving issues.  As someone starting without a development team I think thats key, unless you have the luxury of constantly stepping out of your office to talk to another developer or attend meet ups.
  3. Speed of Development: I don’t spend 10 minutes sitting around waiting to compile!  One of the biggest problems I had with developing in Java and all other high level languages was not being able to being able to make a small change and see its impact instantly.  I’d have to sit through compilation or figure out ways to optimize the compilation process.
  4. Flat learning Curve: Now I do know the full stack of development technologies, so it took me less than a day to get an app up and running.  But I still found it pretty intuitive to setup and I wasn’t sitting around reading documentation for hours figuring out why I couldn’t connect to the database.
  5. Emulation: I was thrilled when I discovered that Rails has a lot of AJAX and JavaScript functionality built into it because it has been years since I wrote a substantial amount of JS.  The other of course is you don’t want to have to constantly switch from technology to technology in the course of writing code.

I will say that as a developer who understand and can code a full stack development, and has worked in a MVC mindset, I’m able to debug issues faster in Rails than others who are purely front-end or back-end developers.  So for anyone evaluating Rails I’d recommend getting accustomed to MVC and thinking about development from that perspective.  My other suggestion is to understand how Rails tries to emulate other technologies like JavaScript and AJAX (using .rjc) and Hibernate/ORM (using ActiveRecord).

Finally, realize that there are limitations to Rails, and its important to be aware of them and be prepared to deal with them or find another technology to compliment Rails.

Enhanced by Zemanta

Post to Twitter Tweet This Post

Ruby Tuesday: Debugging

When I was a freshman at Duke, coding away in Teer basement, I would often hear disgruntled engineers shout: “Damn, I’ve got 300 syntax errors, I left off the semicolon!  Why does everything have to be so exact?”  Those were the days of coding in C++, a language in which you had to actually compile, but hey it was faster than punchcards!

Nowadays we have dynamic typed languages like Ruby that don’t even require semicolons!  But that doesn’t mean we’re in the clear.  We still have to debug.  RoR has done a good job of building in a lot of debugging tools.

Here is my philosophy and methodology for debugging:

  1. Errors and Exceptions are the easiest: Load the web app, if there is an error or exception thrown in the webpage tackle that first.  If I don’t know what the exception means e.g. InvalidAuthenticityToken, I will look it up.  And read about it and usually that will lead me to a solution.
  2. I love logs! If the web app seems to load properly, but some functionality is broken I go look at the logs.  You can add log statements based on the level of logging you want to controllers in RoR with the following code: logger.debug “BUGGY” or logger.info “YO”
  3. Data Corruption: to the Database! If the data appears to be displayed incorrectly then I go straight to the database.
  4. Look & Feel: if something is off with the way the page is rendered then it is most likely something I did wrong in HTML or CSS.  I like using Firebug for CSS issues.
  5. Vijayashanker Code If something is off about the functionality, and I have a sense of where it is happening I will go through and read my code.
  6. Debugger Last: I’m not really a lazy person, but setting breakpoints and stepping through code can be tedious.  So I save this as a last resort if I can’t use any of the above techniques to find my bug.
  7. I hate “debug” statements! I’m a neat freak, I don’t like polluting my code with debug statement, and creating more work for myself in having to go and remove them later.  If I can’t get the debugger to do what I want then I will resort to using debug statements.

As I was debugging today I discovered a few good resources here are a few of them:

  • Debugging Rails Applications (walks you through common debugging techniques and also explains logging levels and configurations)
  • Logging Tips (Everything you ever wanted to know relating to logging in RoR)
  • RoR Google Group (I found solutions and insights into most of the problems I was experiencing today)
Enhanced by Zemanta

Post to Twitter Tweet This Post

Ruby Tuesday: Podcast

I find it hard to learn with just one medium like a classroom or a book.  I need multiple sources of information to drill home a subject (I could of course just be dense).  I started learning Ruby on Rails with tutorials, which are great if you want to learn a few things and do it quickly (and also to kill time while you are waiting on Amazon to deliver your Ruby book).  But tutorials aren’t enough to understand the depth of the subject they aren’t enough.   The next phase of my learning is focused on working through the chapters of Agile Web Development with Rails.  It does a good job of presenting the use cases for Ruby on Rails, giving you a project to work on throughout the course of the book, and also explaining what tools to use in development.

I also like learning and being outside.  So I’ve started a tradition of podcasts and power walks.    I really like listening to: Learning Rails.  The podcast is free and you can subscribe to it on iTunes.  If you visit the site you can also download the screen casts.  If you haven’t yet gone through book exercises I’d recommend looking at the screen casts while listening to the podcasts, it makes it easier to follow and understand what Michael and Christopher are talking about.

I’ll cover video tutorials in the next Ruby Tuesday.

Enhanced by Zemanta

Post to Twitter Tweet This Post

Ruby Tuesday: Test Driving Ruby on Rails

I’ve been getting feedback from my fellow femgineers that they enjoyed Ruby Bootcamp Basics, and they want more info on Ruby and Rails.  So I’m starting a series on my blog called Ruby Tuesday, I’ll spend anywhere from a couple hours to the entire day reading, writing, and researching Ruby and Rails and then blog about my findings.

I’ve also gotten some feedback from my girlfriends who are in tech, who aren’t formal femgineers (i.e. the don’t have an engineering degree or work in engineering deparments), but want to know how to program so that they can independently execute database queries, program emails, or setup simple web pages.  I’m looking out for you gals and I’ll think about doing a series of posts on that :)

I was hunting for a good book on Rails and a few people suggested: Agile Web Development with Rails by Sam Ruby, Dave Thomas, and David Heinemeier Hansson.  If you have done web development and don’t know Ruby I’d recommend reading the introduction and then turning to Appendix on page 667 and go through the Ruby language constructs.  Then continue on with the rest of the book, or if you’re an antsy developer like me go through the Appendix, and then skip to Ruby Bootcamp Basics.  In any event I would learn the language constructs first before reading or writing any code.

But lets back track to the topic at hand: Test Driving Ruby on Rails.  One question I ask all my interview candidates is: have you been responsible for evaluating technology?  This is a required skill in startups because you want to be up and running, and understand the trade-offs to using various forms of technology.  It’s not enough to say well all the cool kids are using it.  Its important to match the tool or language to the task at hand.  I learned Java in college, but when I really started seriously coding in it three years ago people were already onto Ruby on Rails.  It seemed to have a cult following at the time, and all the other startup kids mocked me for using Java (I’m used to being mocked by mengineers), but I stuck it out.  I discovered the Spring Framework, which I thought was really cool, but now I realize that it just adds additional configuration time (apparently Spring 3.0 has gotten rid of a lot of XML, but I haven’t evaluated it yet).  Regardless, I’ve been coding in Java because its reliable and scalable, which meet the requirements for a financial services application, and outweighed the costs of configuration.

But I was always curious about Ruby on Rails, and having finally gotten a web app up and running here are the immediate advantages I see:

  1. Ease of installation
  2. Quick database setup: no need for complex ORM mapping XML files like you need with Hibernate and Java.  Active Record is the ORM layer that comes with Ruby and handles mapping Ruby objects to MySQL tables.
  3. Quick MVC: in Java it would have take me at least an hour to configure in XML the model, view, and controller, write the code for each, and then of course add XMLC classes to support view layout.  In Ruby, I can generate each of the classes using a script or scaffolding, and use Embedded Ruby (ERb) to create a view.
  4. No compilation!  Just start the web app.

The  main reason I am going through the exercise of learning Ruby on Rails is because I want to create a prototype and rapidly iterate on it.  Ruby on Rails is good for getting a web app and running and showing it to customers within a short period of time.  Eventually, my product will have more complicated backend logic that I will probably use Java or another language for.

Enhanced by Zemanta

Post to Twitter Tweet This Post

Ruby Bootcamp Basics

I’ve been putting myself through a Ruby bootcamp.  Here’s are the steps of my training:

  1. Install Ruby and Rails on Mac OS X Snow Leopard
  2. Ruby Primer introduction to Ruby basics
  3. Quick Reference
  4. Ruby on Rails Tutorial comprehensive tutorial that goes through the complete setup from db to web application

While going through the tutorial I found a few issues that I wanted to highlight:

  1. The use of the start_form_tag has been deprecated, the correct tag to use is form_tag followed by do e.g. <%=start_form_tag :action=> ‘create’ %> becomes <% form_tag :action=> ‘create’ do %>
  2. The use of the end_form_tag has been deprecated, the correct tag to use is end.
  3. The error message: syntax error, unexpected kENSURE, expecting $end means that Ruby is trying to ensure that a keyword in this case ‘end’ is being used.
  4. redirects_to versus redirect_to the former is a class method and the later is an instance method.
Enhanced by Zemanta

Post to Twitter Tweet This Post