sorted by: recent | see : popular

Content Tagged with ON + Programming

If you’re in the market for a new hosting provider for your Ruby on Rails application, you might take a look at the new options for Rails Boxcar. We recently expanded our service offerings into three pricing tiers as well as custom packages for those who need a bit more.

A few things that we’ve recently added support for:

• Provide us your SSH key during sign up!
  • Allows us to keep your server even more secure by avoiding sending passwords over the net
  • Other fun features related to this coming soon
• Auto-configured Nginx w/Mongrel cluster
• Phusion Passenger (mod_rails) support! (for those with mixed-environments)
• Continued development of Boxcar Conductor)
• ...more in the works!

The best part is that we can get you up and running with a new Boxcar now for as low as $59/month USD.

For more information, visit: http://railsboxcar.com

If you have any questions, don’t hesitate to contact us.

I’m guilty of it. Many of you are likely guilty of it… and I know that several customers of our Rails Code Audit and Review service are guilty of it.

How many times have you realized (after a few months has passed) that your Copyright date/year on your web site was no longer current?

How many of you had the same problem last year? The year before?

Let me share some advice with you all… DRY (a)!

Don’t Repeat Yourself (again)!

This is really a simple problem to fix but when we’re busy tackling bigger problems… little things like this slip by. Don’t worry, you’re not the only one who was reminded by a colleague three months into the year that you forgot to update this.

On client projects, we have a handful of helpers that we drop into the application. We’re starting to extract more of these into plugins and will be releasing those as time permits. It just happened that I found myself looking at yet-another Rails code base this afternoon that was showing 2007 in the footer. An easily forgivable offense.. but if you’re going to go in there and change it (again), take a moment to do the right thing. ;-)

Our solution at Planet Argon on client projects is to create a basic view helper that renders the current year. This allows us to do the following.

  <div id="footer">
    &copy; Copyright <%= current_year -%>. All Rights Reserved.
  </div>

The helper code looks like:

  # add to application_helper.rb
  module ApplicationHelper
    def current_year
      Time.now.strftime('%Y')
    end
  end

Voila. Not rocket science.. is it?

Guess what? I’m getting really tired of adding this to every Rails project that I touch. So, I bottled this little gem into a new Rails plugin that we’ll just add to future projects.

Introducing Year after Year

This is really the smallest plugin that I could put together (and it includes specs!)

What does it provide you?

YearAfterYear will provide you a helper that will render the current year (dynamically)! That’s right… just add the plugin to your Rails application and you too can enjoy New Years 2009 without having to have a deployment ready with a one line change from 2008 to 2009!

To use.. add the following to any view from within Ruby on Rails.

  <%= current_year -%>

Installation

As I’m using git, you’ll need to grab this and put it into vendor/plugins. That’s it!

You can grab it on GitHub!

• http://github.com/robbyrussell/year_after_year/
• Bugs / Feature Requests here

Happy New Years (8+ months early)!

Just a friendly reminder to not forget the small stuff… because your visitors will notice! ;-)

Updates…

I got a few requests for this to also provide a range of years for people who like to do: 2005-2007. So this is now provided as well.

year_range(start_year)

  <%= year_range(2005) %> # => 2005-2008

We’re starting a new project and I’m finding myself adding things to the code base that we’ve done in the past… hence the last few posts. As we’re doing this, I’d like to highlight some of the little things that we do on each project to maintain some consistency and in that process reach out to the community for alternative approaches.

I’m intrigued by the vendor everything concept, but we haven’t yet adopted this on any of our projects (yet).

What we have been doing is to maintain a REQUIRED_GEMS file in the root directory of our Rails application.

For example:

$ cat REQUIRED_GEMS

actionmailer
actionpack
actionwebservice
activerecord
activesupport
cgi_multipart_eof_fix
daemons
fastercsv
fastthread
feedtools
gem_plugin
image_science
mongrel
mongrel_cluster
mysql
rails
rake
RedCloth
Ruby-MemCache
soap4r
uuidtools

Everybody on the team (designers/developers) knows to look here to make sure they have everything installed when beginning to work on the application.

This has worked fairly well from project to project but since we’re starting a new project, I’m curious if anybody has some better ways to approach this. Should we look more seriously at the vendor everything approach or are there any alternative approaches?

Last few days one of our customers (one of the largest Ruby on Rails sites on the Net) was struggling to solve some really strange problem - once upon a time they were getting an error from ActiveRecord on their site:

They have innodb_lock_wait_timeout set to 20 seconds. After a few hours of looking for strange transactions we were decided to create s script to dump SHOW INNODB STATUS and SHOW FULL PROCESSLIST commands output to a file every 10 seconds to catch one of those moments when this error occurred.

Today we’ve got next error and started digging in our logs…

(more…)

Tags: mysql, lock, ferret, rails

My blog has been fairly quiet lately because our team has been busy helping push a few big client projects out the door. We’ll be posting announcements about those launches on the PLANET ARGON Blog soon, so stay-tuned there!

We’ve been growing the design-side of our team lately, but we’re also still seeking some more Rails-talent in Portland, OR. If you’re in Portland or interested in moving here¹, you should introduce yourself to our team. We’re looking for people to work on-site in Portland, so any remote candidates will be turned away… we’re moving into a shiny and new office space in downtown and are looking for another developer to join our Design and Development team.

you’ll fit in really well if you’re into outdoor activities… ;-)

We’re seeking mid-level Ruby on Rails developers that can pick things up quickly. Having some experience with RSpec will go along way with us. Ideal candidates would have great communication skills and be able to work in a fast-paced environment that places a huge emphasis on collaboration between designers and developers (let’s not forget to mention our clients). Bring what you already know and learn the rest with us.

While everyone might have Wii’s in the office, we’ve taken it to the next level with Speed Stacking! :-p

To apply, send an email to af22+8509@c1.catchthebest.com,

Side note: We’re giving Catch the Best a whirl to review job candidates. If you’re hiring people, you might consider giving it a try.

¹ Everybody is moving to Portland… ;-)

When you’re running a Rails application in development mode, you might notice that it takes a little longer for requests to get processed and this is somewhat intentional as the framework is was designed to allow you to run the application and make live changes to it. This way you can do some basic functional tests from your web browser, work on HTML/CSS changes, or anything else that might need to be done in development mode.

Anyhow, this can be slow from time to time and if you’ve done much Ajax work, you might be familiar with how slow this can feel when performing some basic tasks. Well, thanks to Josh Goebel, we can speed up things with a new plugin he just released.

To install via piston:

cd vendor/plugins; piston import http://svn.techno-weenie.net/projects/plugins/dev_mode_performance_fixes/

To install via script/plugin:

./script/plugin install http://svn.techno-weenie.net/projects/plugins/dev_mode_performance_fixes/

Josh has posted some benchmarks and in my totally basic tests… shows about four times (4x) speed improvement for reqs/sec!

How does it work? From what I can tell, it works somewhat like autotest, in that keeps things cached and when it sees files modified, it re-caches the changes. He’s made it so that the stack doesn’t need to reload for each request, which is quite slow.

Since it’s development-mode only, I’d encourage you to install it and give it a whirl.

Have Fun!

It’s been about six weeks since the last Rails Business “Weekly” Review on here, so perhaps it’s worth changing the name to cut me some slack on not being consistent. ;-)

Since the last post, we’ve gone from around 400 members to 555 as of this morning. We’ve had 562 messages as well, so there hasn’t been a shortage of discussions taking place. I’d like to take a few moments to highlight some of the discussions that have taken place and encourage you all to consider participating, if you’re not already.

Licensing and Client Agreements

Tim Case writes,

“My client sent me this agreement drawn up from their lawyer that included the following:

(c) the Contractor shall not bundle with or incorporate into any Work Product any third-party products, ideas, processes, software, codes, data, techniques, names, images, or other items or properties without the express, written prior approval of the Company;”

Tim then goes on to ask how his applies to using Ruby on Rails, which as a MIT license and how other consultancies are handling these types of situations. Follow the discussion…

Escrow

Gustin writes, “Does anyone have any escrow experience, legal and cost? I am dealing with a client that got burned bad and we are reducing their fear with escrow on the first two iterations.”

Follow the discussion…

Project Planning tools

Mike Pence writes, “So, I used to use MS Project for the composition of those dreaded Gantt charts, but it has been a few years since I had to be so formal. Anything new and exciting – and more robust than Basecamp – happening in the world of project planning software?”

Follow the discussion…

Not long after, Jim Mulholland started a new thread on the same topic and brought up the open source application, redMine. Follow this discussion…

Ruby on Rails versus .NET

Michael Breen asked a big question on the list, which has sparked an going discussion about the benefits of using Rails versus .NET (and other platforms).

“A couple of months ago I decided to stop actively pursuing .NET gigs to focus on Rails. Several of my existing .NET clients have learned of this through the grapevine and have contacted me to discuss.”

Follow the discussion…

Three things Tim’s learned from Freelancing Rails

Tim Case shared his experience of freelancing with Ruby on Rails and highlights three things that he’s learned.

• The non-code business aspect of Freelancing is demanding.
• It takes 10 hours to bill 6 to 8.
• Figuring out your rate is hard.

Read the rest of Tim’s observations and the discussion the followed.

Client issue tracking and documentation

Jeff Judge writes, “Hello all! I was curious to here how people are handling client issue tracking and documentation.”

Several applications were mentioned for handling issue tracking and the general consensus was that there was still a lot to be desired that current options didn’t provide. Be sure to follow the discussions…

Join the Community

These were just a small handfull of the discussions that have taken place over the past several weeks. If you’re an aspiring Rails freelancer or business owner, be sure to join the community and share your experiences and learn from other members of the community that are willing to share theirs.

Until next time, have fun!

Several months ago, a few of your colleagues decided to join forces with you as you had come up with a concept for an innovative web application, shared the ideas with your friends and relatives, and began developing a business plan. After a few months of performing some initial market research, working on your pitch, and raising some initial funding, you decided to bootstrap the project and start designing and developing the product.

During your research phase, you came across several articles about this exciting new technology called, Ruby on Rails. You were impressed with many of the sites that were being developed on this new framework as well as the community that surrounded it. Your team decided that it would be a great idea to follow this trend and use Rails as the platform for your new product.

At this point, you began soliciting freelance developers and/or firms to hire for the design and implementation of your project. Eventually, you make a decision and break ground on building the product.

Let’s jump forward to the present day.

You’ve been in heavy development for quite some time. Your product has gone through a series of design changes and you’ve recently begun to allow other people to begin testing the application. You’re receiving a lot of bug reports as people use the system. Your development team quickly fixes them as they appear, but you’re noticing a trend in the development process.

The speed of implementing new features is drastically slowing down as your development team is spending most of their time fixing bugs. Along with that, they are becoming frustrated by the project because they can’t keep up with your new feature requests while trying to keep up with your growing number of bug reports. You’re becoming concerned about the stability of the product and are slightly suspicious that your developer(s) might not be as good as they suggested they were.

Did you hire a bad development team? Chances are, you may not be able to tell. You’re not a developer, so reviewing their code would almost be a waste of time. How would you know if they were doing a good or bad job? Your developers reassure you that things are going to work out in the end, but it’s going to take longer then originally planned. Along with this, your partners and investors are anxiously waiting for you to launch the product, but something feels wrong. You’re worried that launching it too soon could be the quick death of the entire project if it all comes to a screeching halt due to unforeseen bugs and problems with the application. This wasn’t how you pictured the launch of your exciting new product and you feel a lack of confidence in the entire process.

What can you do?

Before I get into that, let’s discuss some of the possible causes for this situation.

• Your development team may have grossly underestimated this project.
• You might have pushed too many features into the initial release of the product and your development team might not have done a good job of helping you determine what you need, not just what you want.
• Your development team might not emphasize testing enough in their process.
• Your development team may have begun to take a lot of short cuts in an effort to hit your launch date(s)
• Perhaps you asked for quick turnarounds on new features before an investor meeting… maybe this happened on several occasions.
• Your development team might not be very good with Ruby on Rails, maybe this was their first Rails project.
• ...and so on.

At this point, the big question is… what’s the problem?

Can you answer this question yourself? Can your development team answer it? If not, what do you do? How can you get an accurate understanding of how stable the code base of your application is?

Answer: An independent code audit and review

Why is this a good idea? Well, when you have an independent team review your code, you get the benefit of having a fresh perspective.. and often times, an independent team can be much more critical and provide an honest assessment in a very short period of time. This is especially true if they have a lot of experience with the technology. For example, PLANET ARGON has been conducting code audits on existing projects for over two years. We’ve designed a process for checking existing code bases for mistakes that we’ve either made ourselves in the past or found in other projects that we’ve reviewed.

In fact, our process currently walks us through the following areas of your Rails application.

• Security of the application
• Privacy of users’ personal data
• Adherence to the conventions of the Ruby on Rails framework
• Scalability of the application
• Performance of the application and data model
• Testing framework and process
• User interaction (when applicable)
• Information Architecture
• Model-View-Controller (MVC) implementation and organization

Not only does this process provide you with our analysis, but we also provide you with our advice as to where your development team should focus their attention next. If your team is lacking experience in the areas that we recommend they focus on, we’re also here to help them through this with our consulting services. We’re currently assisting several Rails development teams with their testing process, refactoring, user interaction design, optimizing their site, improving their deployment strategy, and plan the implementation of new features.

In general, most freelancers and firms could/should provide you this service, but it should not be performed by your existing development team. They have a bias towards their process and this is your chance to get a second (or third) opinion on the work that you’ve been paying them for. If you’re spending several tens/hundreds of thousands of dollars into this product, an independent review of your investment should be something to seriously consider.

There are several different scenarios that could lead you to deciding to have an independent firm perform a code audit. In fact, I’d encourage you to always get an outside perspective of your team’s work.

To learn more about the Code Audit and Review process that we provide, call us at +1 877 55 ARGON or contact us online.

My colleague, Gary, keeps a stack of Ruby and Rails books on his desk and was implementing an Observer into a client project. It appears that the Agile Web Development with Rails book is still encouraging people to do the following in order to load an Observer.

# app/models/flower_observer.rb
class FlowerObserver < ActiveRecord::Observer
  observe Flower

  def after_create(model)
    # model.do_something!
  end
end

# controller(s)
class FlowerController < ApplicationController
  observer :flower_observer
end

What is wrong with this approach?

Well, in order for your Observer to be used, the model(s) callbacks that it is observing need to be triggered through a controller. If you end up writing any scheduled rake tasks, your observer will not be called. In my opinion, the controller shouldn’t know this much about the model. In fact, the model doesn’t even really know about it’s observer… so why should a controller?

This was actually changed a long time ago (I previously blogged about a different solution here) and the Rails docs for ActiveRecord::Observer are currently correct.

Observers in the Environment

If you open up a recent version of config/environment.rb, you notice in the comments the following.

  # Activate observers that should always be running
  # config.active_record.observers = :cacher, :garbage_collector

Take a moment to go ahead and specify which observer(s) you’d like to load into your Rails environment.

config.active_record.observers = :flower_observer

Then you can remove your observer calls in all your controllers, because that’s not where you should be defining them.

Also, if you’re not using Observers yet, I’d really encourage you to consider reading up on them and giving them a try.

Well, I made it about eight months since I got my new hard drive... and today… I had to run…

sudo port -v install mysql5 +server

Why? I have to migrate some data from MySQL to PostgreSQL.

In a project that I’m currently working on, we’re handling recurring payments for subscribers. I’ve decided to play with a different payment service API on this project (TrustCommerce), which supposedly has one of the easier systems to handle recurring payments as well as one-time charges to the same credit cards. They store all the credit card data so that our delivered product to the client is CISP-compliant.

I came across the TrustCommerce Subscription plugin for Rails, which does just everything that I need to do in this first product release… as well as things that aren’t requirements just yet.

Well, I got my test account from TrustCommerce and was working on some RSpecs to test my new subscription and noticed that it was failing. After some snooping around the error responses, I realized that… test accounts don’t give you the ability to test the Citadel features of TrustCommerce. It’ll be another week or so before finish getting our account setup, so what am I to do? I really want to finish writing these specs and move on to the other portions that are dependent upon this working.

Suppose that you were going to perform something like this in an AR callback.

class BillingDetail < ActiveRecord::Base

  # validations    

  before_create :store_credit_card_data_with_trust_commerce

  private 

    def store_credit_card_data_with_trust_commerce
      # some of this is still test data... prettyu much copied from the README
      # TODO: refactor... but keep me out of controllers!
      response = TrustCommerceGateway::Subscription.create(
          :cc =>  self.credit_card_number, 
          :exp => '0412', 
          :name => self.customer_name,
          :amount => 1,
          :cycle => '1y',
          :demo => 'y'
        )

      if response['status'] == 'approved'
          self.billing_id = response['billingid']
        else
        # handle failure
        end
    end
end

Enter Mock Objects

Since I am unable to succesfully use the TrustCommerceGateway::Subscription.create method until I get our real account, I needed a simple way to emulate the interaction with the web service.

This can be done by using a Mock object, which RSpec provides for you.

TrustCommerceGateway::Subscription.stub!(:create).and_return( {expected response} )

Let’s look at the following spec file (much of it removed to protect the innocent).

module ValidBillingDetail
  def valid_attributes
    { # a hash of valid key/values for this model }
  end

  def approved_trust_commerce_subscription
    { 'status' => 'approved', 'billingid' => '1093423' } 
  end
end

context "A new billing detail" do
  include ValidBillingDetail

  setup do
    TrustCommerceGateway::Subscription.stub!(:create).and_return( approved_trust_commerce_subscription )
  end

  # bunch of other specs

  specify "should store new billing info with 3rd party API and store the billingid" do
    @billing_detail = BillingDetail.create( valid_attributes )
    @billing_detail.billing_id.should_not_be nil
  end
end  

You’ll notice a few things. First, you’ll see that I’ve stubbed the create method and when it is called in the method in my model, it’ll return the hash that I’ve specified.

TrustCommerceGateway::Subscription.stub!(:create).and_return( approved_trust_commerce_subscription )

In the spec, you will see that I am checking that that the .billing_id.should_not_be nil. If you look back in the method in the model above, you will notice that an approved subscription returns a billing_id, which is set when the transaction is successful.

This is working out great for me and because the documentation is fairly easy to follow, I’m going to be able to mock much of the behavior that I’ll be using in the application, without needing to even connect to their API.

If you’re using RSpec, I highly encourage you to read more about mocks objects.

One of our consulting clients consists of a team of .NET developers that are rewriting a rather large product in Ruby on Rails. Every once in a while they have a problem that needs a second set of eyes to look over in order to find a solution with Rails. One of their developers recently asked how they could extend ActionController to provide all of their controllers with an action that would interact with a custom extension they built for ActiveRecord.

One of the few examples that he found to help them do this was a short blog post that I wrote nearly two years ago, titled, Extending ActionController. Given that I wouldn’t do it that way anymore, I felt that I’d quickly post an updated way of doing something similar.

Create Your Extension

This is when you get to take advantage of that lonely lib/ directory in your Rails application. We’ll go ahead and save our custom extension as lib/giraffe_actioncontroller_ext.rb. Now let’s put some code in there.

Looking at the following example, you’ll notice that we’re creating a basic Ruby module, which contains a method named, hot_air_balloon. Within that method, we can do just about anything that we’d normally do in an controller action.

# lib/giraffe_actioncontroller_ext.rb
module PlanetArgon
  module Giraffe
    # add your custom methods here
    def hot_air_balloon
      #
      # if some_condition_in_request?
          render :text => 'the giraffe left in a hot air balloon'
      #end
    end
  end
end

Great, however it’s not going to do anything yet. We need to wire our custom module into ActionController. To do this, let’t go ahead and place the following code at the bottom of lib/giraffe_controller.rb.

# include our custom module in ActionController::Base
ActionController::Base.class_eval do
  include PlanetArgon::Giraffe
end

Now that this file exists, we need to tell Rails about it.

Require Your Extension

You’ll want to update your environment configuration by adding the following to config/environment.rb

# Include your application configuration below

require 'giraffe_actioncontroller_ext' 

That’s all there is to it. Now you can do fun things like…

class ApplicationController < ActionController::Base
    before_filter :hot_air_balloon
    #...
end

Unhiding Actions

As I mentioned, our consulting client needed a handful of methods available to all controllers for use within actions, but they also wanted one method to be accessible via external requests. It turns out that all methods are, by default, hidden from the action processor. Basically, their names are stored in an array, named, hidden_actions. So, to remedy this, they were able to delete their action from the array.

A quick way to do this, is to update lib/giraffe_actioncontroller_ext.rb... like so.

# include our custom module in ActionController::Base
ActionController::Base.class_eval do
  include PlanetArgon::Giraffe
  hidden_actions.delete 'hot_air_balloon'
end

Now every controller in your application has an awesome hot_air_ballon action, which your giraffe friends can use to cruise the night skies in harmony.

Happy coding (and flying)!

¹ Artwork and stories were created by several members of the PLANET ARGON team. I’m not sure why they killed me off in the first issue… or why they removed my thumbs in the story… only to discover hidden giraffes?

Recently, I wrote about using RSpec and autotest (...which I think should be called autospec) together to help boost productivity while working on Rails projects. It seems that a few members of the PLANET ARGON team have picked up on using it, which I’m happy to hear about. :-)

It’s not the only thing that I’m happy about though.

I recently came across another gem. Several of my comrades in #caboose are using piston to manage external plugins for Ruby on Rails. Wait! Isn’t this what Subversion externals is meant for? Well, yes… but externals also eat away at productivity. For example, each day, we may have anywhere from 4-6 designers and developers working on one client project. When we’re in crunch mode, this could account for quite a few subversion commits throughout the day. We all know that we should run svn up on a regular basis to make sure that we’re keeping things in sync… especially when designers and developers are working really closely and fine tuning something specific in the application. Well, the one downside to this process is that each svn up not only checks our repository, but it also checks external repositories.

“But wait! Can’t you just ignore externals on an update?”

Of course, but who wants to type out --ignore-externals each time they run an update? ...or perhaps you could make an alias for this in your shell. In any event, everyone on the team is then left to be responsible for doing this… and an extra 30-60 seconds (if not longer) per svn update times x number of people on project… well… t