Installing Memcache on Snow Leopard

October 14th, 2009 by admin 3 comments »

Memcache is a great way to store session data in Rails.  It is easy to install on Linux (sudo apt-get install memcached), but how about on Mac OS Snow Leopard?  Follow these directions and you should be up and going:

$ curl -O http://www.monkey.org/~provos/libevent-1.4.12-stable.tar.gz
$ tar xzvf libevent-1.4.12-stable.tar.gz
$ cd libevent-1.4.12-stable
$ ./configure
$ make
$ make verify
$ sudo make install
$ curl -O http://memcached.googlecode.com/files/memcached-1.4.1.tar.gz
$ tar xzvf memcached-1.4.1.tar.gz
$ cd memcached-1.4.1
$ ./configure
$ make
$ make test
$ sudo make install
$ memcached -d -P pidfile -l 127.0.0.1

3 comments »

Posted in Programming

Tags:

Rails Sessions

October 13th, 2009 by admin No comments »

What is a session?

Technically a session is a semi-permanent interactive information exchange between two devices, computers or services.  Many people might not even stop to think about how they work, we use them so ubiquitiously (especially as web developers).

A session in HTTP usually is associated, or referenced, by a session token.  These tokens are typically stored inside a cookie on the browser client.  The actual data that these tokens reference can be stored in the cookie itself (not secure), in a database, or in server memory.  Rails developers like to store their session data either in the database or in memcache (an distributed memory key-value based storage service).  [Actually the full list includes:  PStore, ActiveRecordStore, CookieStore, DRbStore, FileStore and MemoryStore]

Using Sessions in Rails

Using sessions in Rails is pretty trivial.  You simply have to call the session method from inside your controller and assign a value to a key:

session[:user] = { :name => 'Nick', :birthdate => Time.parse('1974-07-04') }

Sessions are stored in Rails as a Base64 encoded Marshal string dump.  This means that anything you’re wanting to store in a session must be serializable by Ruby’s Marshal API.  You also should probably avoid storing any large amounts of data (say a chart or graphic), critical data or objects.  If you store critical data you risk losing it, because the nature of a session is semi-permanent.

You also want to avoid storing objects, but instead store references to those objects (user_id vs. an actual User).  This is especially true of objects that have attributes that are apt to change.  You’ll run into headaches trying to keep the object data in sync with the session data.  Also when you modify an object’s structure you may run into issues with older sessions that still are holding on to the old object structure.  Sharing session data across applications can also be a challenge if you store custom objects.  In short just don’t do it, always reference objects.  It’s however relatively safe to store standard data objects (like String, Hash, Array, Time, etc.)

Setting Up Sessions

Setting up Rails to use sessions is very easy in Rails 2.x.  Look for the /config/initializers/session_store.rb file in your Rails project and modify as necessary.  Below is an example of one using a Memcache store:

ActionController::Base.session = {
  :key         => '_play_session',
  :secret      => '7fb9f9e5a65aed3a6699c6cdfd396313bd'
}
ActionController::Base.session_store = :mem_cache_store

One curious thing, there is no good way to expire sessions in Rails.  If you set the :session_expires in your config ( :session_expires => 20.minutes.from_now) that time is set once and isn’t updated in production mode.  There are some plug-ins that can help (SessionTimeout) or write your own session clean-up code (or sometimes a service does it on their own, like Memcache).

If you are using a DB storage you can setup a cron job ot run periodically, via script/runner:

class SessionCleaner
  def self.remove_stale_sessions
    CGI::Session::ActiveRecordStore::Session
      Session.destroy_all( ['updated_at < ?', 30.minutes.ago] )
  end
end

Learn More

http://www.viget.com/extend/wrapping-rails-session-hash/

http://www.quarkruby.com/2007/10/21/sessions-and-cookies-in-ruby-on-rails

No comments »

Posted in Programming

Tags:

LSRC 2009 – Day 3

September 27th, 2009 by admin 1 comment »

How Much Testing

This presentation was very interesting.  It looked at the age-old question of “how much should we test and what do we test?”  It started out going over several real-life stories of companies who had failed to properly answer the question.  One in particular had a test suite that took over 15-20 minutes to build, over 5 minutes to start the server once built, and then used “webunit” tests that took forever to run.  Also the tests only covered 21% of the system — four years later the coverage was 24%!  (As a side note: Selenium testing is hard, to do right.)

For testing it’s critical to get feed back as immediate as possible.  So if your test suite it taking hours to run then you have issues.  You also should ask yourself if your tests are actually failing from time to time, are they really catching bugs and providing value?

Tests should influence your design.  If you are not finding that tests are influencing your design, they you’re probably not doing something right.  The speaker didn’t seem to specifically push TDD or BDD, but I could understand what he meant by this.  In order to test code easily you have to have testable code to begin with.  Code that is not easily tested is probably overly complicated and not designed/abstracted well.

“How easy is it for you to write a new feature?”  This begs the answer as to why testing is a good thing.  Well designed code is easier to maintain and change, and with tests you gain confidence that your application is working as you expected despite the changes.  Martin Fowler often explains that modifiability is the more important attribute to your code (even above performance), and you gain this through understandability (code is easy to follow/read) and testability.  Writing tests helps you write well designed, understandable, and testable code.

There are a lot of reasons why folks are not writing tests.  The speaker addressed the concerns of both management and developers.  Surprisingly he explained that managers are no longer the road-block, and that most managers now want testing – but the developers are resisting.  To write tests first requires a shift in thinking, and for many developers who’ve been coding a certain way for their entire careers, find this shift sometimes uncomfortable.

Ultimately the answer to the question “How much testing,” can be answered by asking, “What’s the right level of assurance?”  If you’re a company like Twitter (for example) if you lose tweets, or a search doesn’t come back exactly right is it really a big deal?  If you’re a patient in a hospital and your heart-lung machine software fails, is it a big deal?  Obviously you wouldn’t necessarily worry if Twitter admitted to less than 70% code-coverage, but you might be concerned if your heart-lung machine was anything less than 100% code-coverage.

Be Awesome

This was a very fast-paced talked that just touched on values or principals you should adopt to “be awesome,” taken from the speaker’s personal experience:

  • Pair program (remote paring is hard, but possible)
  • Respond to change
  • Use micro-frameworks and tools
  • Creativity and craftsmanship
  • Monolithic processes are unfun
  • Are your apps a joy to maintain?

Cucumber

I got the pleasure of seeing Joseph Wilk in person!  He gave his usual presentation on Cucumber, although there were some new features thrown in there.  Tagging was one of them.  The slideshow was pretty involved and if you would like to see an example of his presentation go check out this video:

Outside-in Development with Cucumber and Rspec

View more documents from Joseph Wilk.

Herding Tigers

This was the last big talk of the conference.  It was presented by Danny Blitz, who’s a very dynamic and interesting character.  He basically talked about agile teams, which he refers to as “tiger teams.”  He didn’t really talk about Scrum or XP or the more formal Agile methodologies, but instead discussed his own take on the corporate environment.

Book suggestions:  The Passion of Command, Corpus Business

What is a Tiger Team?

Small development team where velocity and quality are the primary drivers.  The team self-improves, has no meetings (or very few and short), test-automation is taken very seriously with actual QA members on the team.

“A lot of companies fake agile, wtf is a 3 hour scrum?!”

Workplace Archetypes as Animals

  • Tiger:  calculating, cautions individuals who avoid fights they can’t win
  • Cow: herd mentality, afraid of risk, have no original thoughts
  • Bear: big, mellow, live and let live attitude, also avoid fights they can’t win
  • Leopard: unmatched in ferocity, not a good team player though (avoid these)
  • Elephant: C level execs, invincible in battle (even a tiger will not take on an elephant)
  • Hyena: scavenger, dangerous weasels, steals ideas, back-stabbing

Leadership Characteristics

  • Faith and Love
  • Hope
  • Success belongs to the team
  • Failure belongs to the leader
  • The buck stops here
  • Fearlessness (moral courage)
  • Listener and learner
  • Protector

Also good leaders should manage by intent (servant leadership), not micromanage.  They should reward failure, people will make mistakes – let them feel comfortable in making them, as long as people learn.  Demand to be questioned, if your team is afraid of you they will not question your decisions and warn you when something is wrong.  Glorify the lower levels.

Good “grunts” show politeness and professionalism.  (They got it easy.)

Agile is a buffet not a dogma.  Methodologies are wrapped around Agile, *it* isn’t a methodology itself.

1 comment »

Posted in Agile, Programming

Tags:

LSRC 2009 – Day 2

August 30th, 2009 by admin No comments »

Dave Thomas Keynote

Always a great speaker, Dave came down from Dallas to help kick off the conference.  Dave has been using for over 10 years, and he’s still using it.  He shares his reflections with us as to why he still enjoys programming in Ruby.

Ruby is an interesting language.  It can be described as a multi-paradaim language: object oriented, procedural, prototype-based, and functional (all at the same time).  He also points out that Ruby thinks the way he does, which also means – like Dave (or anyone of us) – it’s imperfect.

We shouldn’t worry about perfection though and instead should be pragmatic.  There isn’t only one way to do anything in Ruby, there is no “right way.”  It’s this ambiguity that helps encourage participation.  If Ruby were perfect there’d be no room for creativity, growth or adaptation.  Ruby is adding stuff – not taking away.

Dave also talked about his experience with being publicly “slammed” by Zed Shaw. He said he realized at that point in time that Ruby is not a community.  Ruby is a tool around which communities form.

Passionate people are messy, Ruby is messy.

Programming Intuition

A lot of people are programmers, very few are great programmers.  The difference in productivity between a good programmer and a great programmer can be a factor of 10.  Ruby rejects the idea that the world is simply two buckets of good and great.

  • Do one thing
  • DRY (Don’t Repeat Yourself)
  • SLAP (Single Level of Abstraction Principle)

How do good programmers think?  Does a good programmer simply boil down to command of the language and ability to recognize/use patterns?  NO!  Programming deals in abstractions and great programmers talk about code as if it were not abstract, but in tangible terms.  Good programmers can “feel” code, there is an emotional reaction.

Our brains are made to adapt to our environment (which we perceive through our senses).  Humans are wired to want physical attachments.  What senses do programmers use?

  • vision (why OO is “easier”)
  • hearing
  • kinesthesia (perception of movement, weight and position)

Code is not 2D, it’s not even 3D, it’s multi-dimensional.  So diagrams are not always useful.  Code sometimes has a “viscosity” and can be felt to push back or resist you.

What do we perceive as beauty?  Elegance?

Cultivate a Sense of Code

  • No specifications / think about it
  • Use tools that help you
  • Practice, use methods that provide immediate feedback

Experts operate on intuition, not on recipes or rules.

  • Master Ruby’s method lookup (it’s worth knowing)
  • Useful to limit scope of magic
  • Can modify individual objects with modules
  • Tr to replace inheritance with extends

Succeeding with Ruby on Rails

This talk was about the owner of Thoughtbot and how they got to where they are today.  Below are some of the notes from the talk:

  • Started in 2003 with 4 people
  • Not everyone wants to run a company
    • wanted to go into business to work the way they wanted to
    • happiness is very important
  • Perl was their “happy language” from Java, but Ruby and Rails ruined it
  • Decided to only do Ruby on Rails, revenue skyrocketed afterwards
  • Hiring is very important and hard
    • hire only people who want to learn and teach (passionate)
    • skilled
    • right attitude
    • salary (the best you can afford, not necessarily that money can buy)
  • Don’t compromise on core principals
  • Be nice

Identify what’s really important for you, don’t compromise on that decision, and be nice.

Hiring Process

When hiring people Thoughtbot first reviews a resume and code of the applicant, before they even do a phone interview.  Then an initial phone call is done, followed by a second interview if there is interest.  The 2nd interview is more technical in nature.  If an application is considered, they have to participate in a week-long immersive pair-programming situation with a developer on staff.  After this last step is then someone considered to be on the team permanently.

Core Principals

  • sustainable development (40 hrs a week)
  • all are technicians (even html/designers)
  • no contracts or outsourcing

Clients

When it comes to client relationships the approach Thoughtbot takes is to “do the best you can.”  This doesn’t always mean you succeed at every project, but you know that you did your best in trying.  Set expectations, be proactive and above all nice.

Thoughtbot does not believe in subcontracting and they insist you should work on the way you want to work.  If a client doesn’t want to work with you then you should ask them to find another team.  In the long run it isn’t worth being unhappy and you’ll just be frustrated (as will likely the client), all around bad.

Client Management

  • project planning form
  • Highrise
  • master services agreement
  • project lead (SM/PM rolled into one)

Design and Development

Like 37Signals, Thoughtbot is a big believer in design first.  They will figure out how a UI looks and works before coding.  This helps flesh out details you might not realize until later, when it’s more expensive to fix.  They practice pair-programming with an iterative, TDD development approach.  Pivotal Tracker is used to manage their backlog.

They also believe strongly that people should do what they enjoy.  Folks are encouraged to work on projects that interest them, there are not set roles or boundaries.  If a designer wants to get more into Rails, he’s allowed to take on some Rail work in a project.  There is always at least two developers per project.  If one becomes bored or wants to work on a different project it makes it possible to swap people out without affecting the project to terribly.

Open Source

Part of the culture at Thoughtbot, they’ve made many open-source contributions to the Rails space.  Abstractions don’t stay internal to the company.  By releasing open-source software they get their ideas validated and legitimized.  Payback includes recognition in the market space.  They also have to support the software less, because the community itself supports the software (crowd-sourced support).

The one suggestion for other companies looking to do open-source contributions:  keep quality high, incubate internally for a while before releasing, make sure it’s something you enjoy using yourself.

Products

The talk ended with the question about why and how do you keep Ruby relevant?

  • consulting scales w/ people
  • but we want a small company
  • products can scale without people
  • make products you use yourself
  • make products you enjoy using

How long will Rails be around for (be popular)?  How long will Ruby be around for?  We have to take responsibility for Ruby and Ruby on Rails so it remains popular.

No comments »

Posted in Programming

Tags:

LSRC 2009 – Day 1

August 27th, 2009 by admin No comments »

Today was a training day.  The conference officially starts tomorrow, but there were some interesting things that I learned in my classes:

Ruby Craftsmanship with Gregory Brown & Brad Ediger

Code is written once and ready many, many times over.  It’s because of this fact we want to make sure we write good code.  Writing good code also helps you avoid shooting yourself in your foot or painting yourself into a corner on a project.  You’ll find your work more enjoyable as well, it’s more pleasant to work in a well-ordered project than one which is in disarray.

Reading code is an important skill.  You should practice often by reading code from other projects, like open source projects, and figure out how things are working.  Try to be as comfortable reading code as you are conversing with people.  Remember docs can lie (they can be out of date or just plain wrong), so it is important to be fluent at reading code.

A good majority of the morning was spent working through design koans and talking about why they are true.  A koan, for those who are unfamiliar with the term, is a Zen practice where the student is demanded to answer the question.  In the class they were a series of unfinished unit tests that had to be completed and made true.  You can find a set of them here: http://github.com/edgecase/ruby_koans

The second half of the class talked about the nuances between a class, a module, and a singleton. Why would you use one over the other?

Classes

  • can be instantiated as objects
  • class variables can have far-reaching (unintended) affects
  • object data exists separately
  • can implement interfaces

Modules

  • cannot be instantiated as objects on their own
  • help manage namespace and be used as a mixin
  • module methods are not included into their calling class

Singletons (class, not pattern)

  • are class-like entities, but cannot be instantiated
  • methods are stored per-object, rather than per-class
  • all class methods of a class are actually kept on a singleton class

The singleton stuff can be mind-blowing, so if you wish to understand it better you can check out an article “Understanding Ruby Singleton Classes“, by Peter Jones.

We were also encouraged to pair-programming during the session.  A rare experience I get to enjoy, since we do not pair-program where I work.  I got to pair with Ben Kimball, a local Austin developer like myself.  He wrote the unit tests (defining what the interface should be) and I wrote the implementation (the actual code to make them pass).  The interesting thing that was happening is that through the process of test/code writing we talked about the design and really came to understand what was going on and what was needed – resulting in a better design (that was also testable and tested) than maybe we could of done individually.

Greg and Brad also shared some other general bits of wisdom:

  • When working on problems, even when doing so alone, talk with your team as you go along.
  • YAML parser will automatically convert things that look like dates into a Date class.
  • Do not ever use class variables, instead use class instance variables (by opening up the singleton class), because class variables can have far-reaching affects.
  • If you work in an “enterprisey” organization you can still do TDD.  Just do your pair session and write your tests, which will flesh-out the design, then go back and create/update your “formal” design documents to match.

Additional things to research:

No comments »

Posted in Programming

Tags:

Getting Ready for LSRC 2009

August 22nd, 2009 by admin No comments »

This coming week I’ll be attending the Lonestar Ruby Conference (LSRC) 2009. I’m lucky that it’s held here in Austin, TX, my home town.

Last year was really insightful, especially given how new to Ruby I was, a little less than a year. Now I am coming up to nearly two years of using Ruby professionally. I’m really looking forward to this one, they usually help energize and excite me in terms of what’s possible with Ruby and Ruby on Rails. It is also cool to see what other folks are working on and doing with Ruby.

You can brush up on my 2008 attendance which I blogged daily about at the links below. This year I plan on doing the same, so stay tuned!

No comments »

Posted in Programming

Tags:

Internationalization (I18n) in Rails

August 12th, 2009 by admin No comments »

You have a great Rails application.  It’s so popular that folks are asking you publish it in additional languages.  Oh that we could all be so lucky!  It’s a problem faced by many successful projects.  At some point you’re going to need to translate your application into other languages.  Luckfully in Rails it is relatively painless to handle.

I18n Class in Rails

Rails has a special class that you can use to both translate strings and localize date / time objects.  I18n is the main workhorse that provides internationalization support out-of-box.  You can also use different a backend like Globalize2 (either as a complete replacement or hybrid solution).  You can learn more bout the I18n API in the official Rails documentation.

Steps to Consider

Setting up your application to support additional languages you’ll need to think about the following:

  • What is the default locale going to be?
  • Where to keep and how to organize your locale dictionaries?
  • How do you set the locale?
  • How do you preserve the locale for the user’s session?
  • How do you switch locale?

Default Locale and Dictionary Locations

Setting the default locale is easy.  In the Rails config/environment.rb file you will find an option commented out for setting the default locale.  Simply uncomment this line and set the locale to whatever default you desire.

config.i18n.default_locale = :en

While you’re in this file you’ll want to also uncomment the line that defines where the locale dictionaries are kept.  The locale dictionaries are just YAML files that define string replacement. You’ll use these dictionaries to define ActiveRecord date and time formats, counts, and standard validation messages.  It also can be used to define custom strings, used for string replacement. Below is a small sample of a dictionary file:

en:
  hello: "Hello world"

You can find more complete starter dictionaries by Svenfuchs on Github.com.  I use these on my own projects to jump-start the translation process and highly recommend them.

<%= t('hello') %>

You can then use string replacement to facilitate translation, the code above would produce “Hello world” if the site was set to the ‘en’ locale.

en:
hello: “Hello world”

Setting the Locale

The easiest way to set the locale is to have locale passed as params in the request.  You could take more sophisticated approaches using URL prefixes, browser preference settings, etc.  Below the code demonstrates a simple implementation using a locale param:

before_filter :set_locale
def set_locale
  # if params[:locale] is nil then I18n.default_locale will be used
  I18n.locale = params[:locale]
end

With this code in your ApplicationController visits to http://www.mysite.com:3000?locale=fr would load the French dictionary file.

Preserving Locale

Another problem you’ll need to contend with is preserving the locale with each subsequent request.  The most usual way of handling this is to modify the default_url_options to always include the locale parameter:

# app/controllers/application_controller.rb
def default_url_options(options={})
  { :locale => I18n.locale }
end

Switching Locale

You’ll want to give users ways to switch their locale when they visit. I’m not going to go into details on how to do this because your implementation will be custom to you. The most popular is using a simple drop down that will redirect the user to the new url with the new locale parameter set. Another possibility, if you have users log in, is to provide a control panel or setting they can configure and redirect them upon login to the correct language.

More Resources

No comments »

Posted in Programming

Tags:

May 2009 Cucumber Presentation

August 2nd, 2009 by admin No comments »
Below is a presentation I gave at Austin on Rails.  You can also find the audio for it here:  nicholas-cucumber-rails-audio
View more documents from ncancelliere.

No comments »

Posted in Agile, Programming

Tags:

webOS on Mac OS X

July 25th, 2009 by admin 9 comments »

webOS is here!  If you’re unfamiliar with the term, it’s the name of the development platform that powers the Palm Pre.  Unlike the iPhone (which requires esoteric knowledge of Objective-C and Cocoa), webOS uses web technologies like JavaScript/Prototype, CSS and HTML5.  This makes it really easy for web developers to pick up and develop on the phone.

The only snag I’ve run into on my MacBook Pro is that the novacom service isn’t started automatically when you launch the emulator.

This error message greets you when you first run the Palm emulator.

This error message greets you when you first run the Palm emulator.

The problem is the service/daemon that the emulator depends on has some wonky permissions, well technically they’re called ‘dubious’.  So they get refused when the installer script does its clean up.  You can start the daemon manually with /opt/bin/novacomd — but that gets annoying after a while.  So to fix it you simply need to enter the following two commands in your terminal:

sudo chmod 644 /Library/LaunchDaemons/com.palm.novacomd
sudo /opt/nova/bin/post-install.sh
$ sudo chmod 644 /Library/LaunchDaemons/com.palm.novacomd
$ sudo /opt/nova/bin/post-install.sh

The first line repairs the permissions so MacOS X doesn’t complain about any dubious looking files when you attempt to add them to launchctrl.  (The root of the issue is the com.palm.novacomd cannot have write permissions for the group, which it does post-install!)  The second command just re-executes the post-install script, and properly installs the service .

Now when you reboot your Mac you don’t need to remember to start-up any daemons before you begin development.  Enjoy!

Running TextMate, Terminal and the Mojo SDK (running VirtualBox) with the Palm Inspector

Running TextMate, Terminal and the Mojo SDK (running VirtualBox) with the Palm Inspector

You can learn more about how to get started developing below:

http://developer.palm.com

http://www.youtube.com/watch?v=YXS3SQauwPE (O’Reilly video)

9 comments »

Posted in Programming

Tags:

Wired Article: What Bugs can Teach Bosses

July 22nd, 2009 by admin No comments »

I was reading an article in the Sep 2008 issue of Wired titled “What Bugs can Teach Bosses.”  The article looks at different animal species and relates them to work patterns and behavior for humans.  It got me thinking about how similar they were Agile principals.  I love when you can find examples in Nature that can be applied to every-day work life.

Ants and Bees – Broadcast Messaging

Ants use chemical signals to transmit messages and bees dance to tell other bees where to find food. This style of communication increases group efficiency by giving everyone access to the information and then individuals can decide what to do with the new information (if anything).

People in Agile organizations benefit from this style of communication as well, commonly referred to as “whole-group communication.”  At the daily Scrum team-members sync with one another doing a sort of “bee dance,” while throughout the day they might be updating themselves through CI build notices, participate in electronic group chats, or view burn-down charts and story boards. (e.g. leaving chemical trails).

Geese – Collective Leadership

Geese fly in a V-formation because it helps conserve energy and so that they can be guided by a leader.  You see, scientists have discovered that no single goose knows the entire route alone.  The lead goose will rotate out, letting other geese take their place.  Each goose knows, or has memorized, their portion of the flight path and they lead the part they’re most familiar with.

Agile teams can learn from this concept.  XP strongly recommends the use of “specialized generalists.”  This isn’t to say that you shouldn’t have experts on your team!  Teams can consult with their subject matter experts, playing off one another’s strengths and weaknesses — which is what makes them more creative and productive than any single individual.  Just like a flock of geese, don’t be afraid to change out leadership for the portion of the flight most familiar to expert individuals.

Worms – Interconnectedness

Worm brains have a mere 300 neurons.  This might be surprising, but the 300 they have are very interconnected.  This exceptional number of connections allows the worm to do a lot, with just a few brain cells.

On a Scrum team the ScrumMaster acts as a hub.  They’re the most interconnected individual working with the PO, tracking issues within and outside the team.  They can interface with other ScrumMaster’s, on other teams, adding to their interconnectedness .  If issues arise, the ScrumMaster can help serve as a guide and help the team avoid bottle-necks.  They can also help “fine-tune” the team’s strategy, especially as new information comes in.

So look at how your own team is working.  Are you leaving “chemical trails,” have you embraced broadcast messaging?  Do you recognize the expert talents of different team members and defer to them when it’s their “time to shine?”  Are you okay with stepping down once your expert role isn’t needed, letting someone else take the lead?  Is someone on your team playing the “hub” role, using their interconnectedness to identify, track, and resolve issues and clear bottle-necks?  There is a lot we can learn from nature…

No comments »

Posted in Agile

Tags: