Read my latest article: Ezra Zygmuntowicz -- Farewell, Friend. (posted Mon, 01 Dec 2014 17:53:00 GMT)

[ANN] Brian Ford joins PLANET ARGON

Posted by Wed, 31 May 2006 16:39:00 GMT

1 comment Latest by Chris Wed, 28 Jun 2006 23:26:21 GMT

If you’re a regular in our IRC channel or a client of ours… this is probably old news (well… a few weeks old). Earlier this month, we hired some more local talent to join the PLANET ARGON Core Team.

I’d like to take a moment to introduce you to Brian Ford, the newest member to our development team. When not working with us, he is currently finishing his degree in Mathematics. During one of his interviews, he described how he was fascinated by the Costa Minimal Surface, which we all googled after to see what the heck he was talking about. Brian also speaks a little of both Japanese and Spanish… and is versed in many programming languages… and recently got interested in Io.

Allison finished up his illustration the other day. :-)

Keep an eye on his new blog, Bright Red Glow. I highly encourage you all to subscribe to his feed. :-)

Welcome to the team, Brian!

The Art of Delivery, part 1

Posted by Wed, 31 May 2006 05:09:00 GMT

1 comment Latest by David Rosebaugh Wed, 31 May 2006 20:52:02 GMT

Over the next few weeks, I am going to interact with the readers of my blog in a segment that I call… The Art of Delivery.

As a professional developer, my experience with working in development environments has been fairly unique each time. Up until PLANET ARGON, I had very little say in how we structured the very process that I was expected to follow. Granted, there is is a benefit to having leaders who have some good experience to help guide a team throughout the life span of a project, but a leader should also posses a sense of humility and stay agile in their processes. You cannot succeed in an environment where an old dog can’t learn new tricks. This sort of thinking reminds me of managers who feel that their sole responsibility is to manage people. People manage themselves, a leaders helps facilitate self-management. I’ll be the first to admit that I have much to learn in both areas. :-)

Delivery!!!

Earlier this year, the PLANET ARGON Core Team met to outline new processes. One hot topic was project communication and delivery. One of the areas that we all insist that we excel at is building better estimates and managing project delivery more efficiently. Every one on our team has their own ideas of how best to coordinate projects and we wanted to find a way to invent our own pattern… but what we realized is that we were borrowing a lot of ideas from books we’ve read as well as the lessons learned in previous environments. One of the things that we realized is that while we weren’t horrible at building estimates for a six month project… it was that we knew that the requirements of (almost) any project would change scope within six months. How could we accommodate new ideas in a project without disrupting the budget and the agreed timeline? We wanted to rethink this process and push ourselves to follow an iterative approach.

Focus on the now and then the then

Since then we have begun to define and redefine what each stage of a project looks like. How do we communicate stages of a project with our clients in a meaningful and clear way?

I’m now about to give away how we do business at PLANET ARGON.

Project(s), Release(s), Iteration(s), Task(s)

It’s not rocket science… and it shouldn’t be!

  • A project has many releases
  • A release has many iterations
  • An iteration has many tasks

What we do is isolate an iteration by collecting a set of goals to be accomplished that the client and we agree on as being of high value to the success of the project at this point in time. Tasks are essentially the individual steps needed to achieve those goals and we don’t go out of our way to list each one of those during an estimate process as some tasks take less time than it takes to generate an estimate for them. We include our developers in our estimate and specification process as they often have many great questions to send to the client to get further clarification. Often, much of this clarification process happens during a first iteration, which some call Iteration Zero... as no code is developed during this iteration. Prototypes, estimates, mockups, and Q&A is what iteration 1/zero consists of. This is that important design phase that people talk so much about. :-)

Let’s get back to thinking about delivery… and we’ll make the assumption that you’ve already worked out your estimates and are now ready to work on your (next) iteration.

Open Question: As developers, project managers, and curious readers… how do you proceed?

...to be continued

The Daily Stand Up, part 2

Posted by Mon, 29 May 2006 16:11:00 GMT

4 comments Latest by Reagan Wed, 31 May 2006 04:29:40 GMT

In a previous post, I outlined how the PLANET ARGON team handles their communication of day-to-day work with the daily stand-up. Several people posted comments about similar processes and some suggestions were made to keep them from getting too stagnant. I wanted to highlight a few of those comments.

Aslak Hellesoy suggests, “Use a token – a rubber ball or something – for each person giving status. Only the person holding the token is allowed to talk.”
Florian Weber said, “Everybody standing up makes meetings go faster and more focus…”

However, not everybody is convinced…

Doug said, “I hate meetings, why on Earth would you punish your employees on a daily basis?”

Perhaps Doug has worked in environments that encourage too many bad meetings. A client recently said, “meetings are expensive” when we agreed to not have too many meetings throughout the project. Less meetings that are well-focused are much more valuable and productive. :-)

The one that caught my attention was the comment made by Aslak Hellesoy… he goes on to say, _“When a speaker is done, throw the token to a random person instead of just handing it to the left or right. This forces everyone to stay more alert, as noone knows who’s next.”

This got me thinking about how we had made it a ritual to stand in similar positions and I would start off the meeting. The team wasn’t too keen on throwing a ball around the room as we often hold coffee in our hand… so I came up with the following solution…. which reunites us with our little friends, the index cards!

Randomizing Daily Standup Meetings

Basically, all I did was take a stack of index cards and write a number on each one. Then at 9:15am PST, we all walk into the meeting room and take one. Whoever got #1 goes first and we work our way up from there. We’ve done this three times so far and most of the team seems cool with it. I’ll keep you posted as we solidify our approach to The Daily Stand-up.

...and of course… this comment also reaffirmed our decisions to do daily stand-ups…

Kevin Rutherford said, “Cool. And by “inventing” the idea yourselves, I guess you have much greater buy-in too?”

Related Posts

Install Ruby, Rails, and PostgreSQL on OSX

Posted by Mon, 29 May 2006 14:46:00 GMT

15 comments Latest by Manjoor Thu, 13 Jul 2006 11:00:30 GMT

WARNING: This post contains some outdated instructions. Please read Installing Ruby on Rails and PostgreSQL on OS X, Second Edition.

Our Creative Director, Allison Beckwith, picked up a new black MacBook this weekend and I had the luxury of getting it setup to model our standard setup. We all try to keep our setups fairly similar so that we don’t hit too many issues when working together on projects.

I’ll try to keep this short and to the point… because if you’re like me… you just want to start playing with Rails! ;-)

The steps I followed to get her setup like the rest of the development team at PLANET ARGON went something like this.

XCode and DarwinPorts

  • Download and install iterm (the Universal dmg)
  • Download and install XCode tools from Apple (dmg)
  • Download and install DarwinPorts (dmg)
  • Start up iterm.
In this step we are going to modify the default bash profile so that every user on the machine that uses bash will get the path for darwinports in their bash_profile.
sudo vi /etc/profile

Modify the following line to include /opt/local/bin in the PATH… save the file (see vim documentation for details)


  PATH="/bin:/sbin:/opt/local/bin:/usr/bin:/usr/sbin" 

Ruby and Rails

  • Open up a new iterm tab (apple-t)
  • Install ruby with darwinports with: sudo port install ruby rb-rubygems
  • Install Ruby on Rails and all its dependencies with: sudo gem install -y rails

PostgreSQL and Ruby libs

  • Install PostgreSQL8 with: sudo port install postgresql8
  • We need to modify the /etc/profile file again because the postgresql8 install doesn’t add programs like pg_ctl to /opt/local/bin. Change the PATH to now look like this and save.

  PATH="/bin:/sbin:/opt/local/bin:/usr/bin:/usr/sbin:/opt/local/lib/pgsql8/bin" 
  • Install the postgres gem with: sudo gem install postgres
    • Oh NO!!! You should see an error about it not finding libraries… what will we do?

  cd /opt/local/lib/ruby/gems/1.8/gems/postgres-0.7.1
  sudo ruby extconf.rb --with-pgsql-include=/opt/local/include/pgsql8 --with-pgsql-lib=/opt/local/lib/pgsql8
  sudo make && sudo make install
  # for good measure...
  sudo gem install postgres

Successfully installed postgres-0.7.1

Configure PostgreSQL for single user

In our development environments, we don’t find it necessary to keep PostgreSQL running all the time on our servers. We only want it running when we’re doing development. We also typically install it per user on a machine to keep us from needing things like usernames and passwords to connect to it from an application we’re running on the machine. Let’s setup PostgreSQL the PLANET ARGON way!

  • Open up iterm and go to your home directory
  • Init your new PostgreSQL database with: initdb -D pgdata
  • Start up PostgreSQL with: pg_ctl -D pgdata -l pgdata/psql.log start
  • Create a new database with: createdb argon_development
  • Test the new database with: psql argon_development
  • Did it load up your new database? If so, great! If not… check your steps… :-)

Test Rails + PostgreSQL

  • Navigate to a directory where you don’t mind sticking projects… mkdir development; cd development
  • Generate a new Rails application with: rails -d postgresql argon
  • Navigate to new Rails application directory. cd argon
  • Generate a new model to test with: ./script/generate model Argonista
  • Edit and save the migration that was generated ( db/migrate/001_create_argonistas.rb ) file with your favorite editor…

  class CreateArgonistas < ActiveRecord::Migration
    def self.up
      create_table :argonistas do |t|
        t.column :name, :string
        t.column :blog_url, :string
      end
    end

    def self.down
      drop_table :argonistas
    end
  end
  • Edit config/database.yml to look like the following… you’ll notice that we don’t need to supply a username or password.

  development:
    adapter: postgresql
    database: argon_development

  test:
    adapter: postgresql 
    database: argon_test

  production:
    adapter: postgresql
    database: argon_production
* Run the migration with: rake db:migrate

  $ rake db:migrate
  (in /Users/allisonbeckwith/development/argon)
  == CreateArgonistas: migrating ================================================
  -- create_table(:argonistas)
  NOTICE:  CREATE TABLE will create implicit sequence "argonistas_id_seq" for serial column "argonistas.id" 
  NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "argonistas_pkey" for table "argonistas" 
     -> 0.0399s
  == CreateArgonistas: migrated (0.0402s) =======================================
* Test your new model from console

  $ ./script/console 
  Loading development environment.
  >> a = Argonista.new
  => #<Argonista:0x24569dc @attributes={"name"=>nil, "blog_url"=>nil}, @new_record=true>
  >> a.name = 'Robby'
  => "Robby" 
  >> a.blog_url = 'http://www.robbyonrails.com'
  => "http://www.robbyonrails.com" 
  >> a.save
  => true
  >> exit
* Great, let’s go look at our database table…

  $ psql argon_development
  Welcome to psql 8.1.3, the PostgreSQL interactive terminal.

  Type:  \copyright for distribution terms
         \h for help with SQL commands
         \? for help with psql commands
         \g or terminate with semicolon to execute query
         \q to quit

  argon_development=# SELECT * FROM argonistas;
   id | name  |          blog_url           
  ----+-------+-----------------------------
    1 | Robby | http://www.robbyonrails.com
  (1 row)

There we go, we’ve setup Ruby, Rails, and PostgreSQL on a brand new Intel MacBook without breaking a sweat!

Extra Goodies

  • Subversion: sudo port install subversion
  • Lighttpd: sudo port install lighttpd
  • ImageMagick: sudo port install ImageMagick (known to take a while…)
  • GraphicsMagick: sudo port install GraphicsMagick
  • Install the rmagick gem: sudo gem install rmagick

Have fun!

Rails Business Hosting Encourages Weekend Getaways

Posted by Sun, 28 May 2006 17:34:00 GMT

Wow, it’s only been two weeks since the PLANET ARGON team announced our new suite of Rails Business Hosting plans and the response has been great! Some of our existing customers are taking advantage of this and upgrading their accounts and moving to the new exclusive resort of Rails hosting.

A few people have asked some important questions about our new Rails Business Hosting plans.

  • Can I use it as a reseller account?
    • No, this suite of plans is targeted towards businesses who need a more isolated environment for hosting their new web application running on Ruby on Rails! This would violate our 10-15 customers per server arrangement.
  • How is this better than my own VPS?
    • We’ll admit, a VPS is a nice option and would be a competitor to our new plans. However, one key difference is that we manage the server for you. Not all developers are also Unix system administrators. We’ve been hosting Rails applications for well over a year and understand the complexities that surround deployment and hosting them and leverage this experience when we architect our hosting environments.
  • Do you have documentation for your new plans?
    • Yes! We’re modeling our environment to be very similar to our standard rails hosting plans, so the information being collected on the PLANET ARGON Documentation Project is accurate. This also makes it easy for you to move from one of your current accounts to the new service as only a few variables will change.

How many of you have taken a long vacation and not needed to worry about your servers and applications staying up? We’re hoping to help you take that cruise, those three weeks on a tropical island, or the rafting trip your friends keep talking about.

We’re here so you don’t have to be!

Learn more about out Rails Business Hosting plans.

The PLANET ARGON dot ORG project and asset compiling gone wild

Posted by Fri, 26 May 2006 14:17:00 GMT

InfoQ recently unlaunched their new site that is dedicated to “tracking change and innovation in the enterprise software development community.” One of the first articles published on the site was written by Jeremy Voorhis, Lead Architect at PLANET ARGON. Jeremys’ article, Agile Asset Management with Ruby DSLs outlines an approach we took on a client project earlier this year for managing tons of assets for a Rails application. Our development team extracted this work and built asset_compiler, which is now available as a gem on RubyForge and we’ve recently setup a trac so you can post bugs, patches, and all things similar. We’ll be announcing a few more open source plugins, gems, and projects in the near future as well. I know that many of you are wondering when and where acts_as_legacy will show up… keep your eye on the trac. ;-)

To install asset_compiler, run:

gem install asset_compiler

Read the asset compiler documentation.

The PLANET ARGON dot org project

Enjoy!

Older posts: 1 2 3