New Boxcar plans announced!
Yesterday we announced our new suite of plans for Rails Boxcar. You can now get started with a pre-configured VPS designed by Rails developers like you for as low as $59/month.
You can check out our new rates here:
If you’re at RailsConf, be sure to introduce yourself and ask for details. :-)
Meet us at RailsConf
If you’re coming to Portland for RailsConf or CabooseConf, be sure to introduce yourself (and we’ll try to do the same). A few of us from Planet Argon will be attending the conference. I thought that I’d make it easy to spot us by putting some faces to our names.
In corner #1 we have Alex Malinovich who is our Director of Deployment Services. If you have any questions about hosting options, deployment tips, and scaling your Ruby on Rails application.. be sure to tug on his shoulder. I also overheard that he’ll be giving people discounts on our Boxcar products to those he meets in person.
Alex Malinovich, Director of Deployment Services
In corner #2, we have Andy Delcambre who is on our development team. You might remember Andy from his series of blog posts/tutorials on using Git and getting Basecamp RSS feeds working in Google Reader via a Mongrel-based proxy (our team is still using this approach using this after ten months!).
Andy Delcambre, Software Developer
In corner #3, we have Gary Blessington who has been leading our design and development team. If you’re looking for a job working with Ruby on Rails, be sure to introduce yourself to Gary as he’s hoping to meet up with several applicants who will be in Portland this week.
Gary Blessington, Director of Design and Development
In corner #4… is me. I’m not doing any talks this year so I plan to do wander around stress-free as I’m not finishing my slides at the last minute or preparing for panel talks. I’m happy to field questions and exchange stories with you. :-)
Robby Russell
We are hiring... so feel free to introduce yourself to any of the faces above.
...and most importantly, I hope you have a great time in Portland!
Coming to Portland for RailsConf or CabooseConf
If you’re coming to Portland, Oregon for RailsConf 2008 or CabooseConf… I’d like to invite you all to check out our collection of articles that we wrote to highlight some stuff to do in town. We’ll be posting a few more before the conference, but wanted to help you all plan out your visit in our wonderful little city.
Portland Revealed series
- Episode 2: Beertown
- Episode 3: Get outdoors
- Episode 4: Stay Awake During RailsConf
- Episode 5: Places to Work
- Read them all
Stay tuned as we’ll be posting more over the next week.
Boxcar Conductor plugin moved
Update. We’ve moved the Boxcar Conductor plugin for deploying Ruby on Rails applications to a new location on GitHub.
You can still submit bugs/feature requests on Lighthouse here:
Enjoy!
Boxcar on Twitter
We’re about to roll out some announcements for Boxcar, our professional VPS hosting solution for Ruby on Rails applications. As we roll out these new updates, we’re going to offer some extra special deals to those who are following us on twitter. :-)
If you want in on the action…
As usual, we’ll be posting some announcements on our blog as well… so be sure to subscribe to our feed.
The Art of Delivery, part 2
Two years ago, I wrote an article titled, The Art of Delivery. I wanted to post a few updates based on how our process has evolved since then (and continues to).
Over the past few years, we’ve been fortunate enough to work on quite a diverse collection of projects. This has enabled us to work with many different clients and solicit feedback on our process. This has given us an opportunity to evolve a set of best practices that fulfills the long-term project goals/budgets of our client while making sure that we’re able to maintain a design and development process that is agile.
As I’ve mentioned in previous posts, our team typically bills work per-iteration on projects rather than per-hour or a flat-bid per-project. Since iterations are bite-sized pieces of the entire project and limited to 1-2 weeks, our teams estimates are much more accurate and we’re able to keep things rolling and on track.
The basic structure of our project looks like this.
- A Project has many releases
- A Release has many iterations
- An Iteration has many deliverables
- A Deliverable has many tasks
Before we begin working on an iteration, we outline a set of goals that we want to create solutions for. This process comes out of discussions between our client and us until we agree on what is the highest value/most critical to the success of the project, based on our shared understanding of where we are today. These goals translate into Deliverables, which in a typical iteration might require Interaction Design, Interface Design, or Development. We tend to break our process up into stages so that Interaction Design on Module XYZ would be implemented in a following iteration. This is because it’s unrealistic to expect someone to provide an accurate estimate on how long it’ll take to implement something before you know how people will interact with it.
Within any given iteration, our team is spread across several sets of deliverables. As a team, we breakdown these deliverables into smaller sets of tasks. It’s our aim to keep tasks smaller than a full days worth of work as it’s much easier to measure progress across the iteration when we can track tasks at a granular level.
Essentially, tasks are the individual steps needed to achieve these goals. 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. Each person providing estimates should avoid getting too granular and aim to find a good balance that compliments their workflow.
Like most things… mileage may vary.
Through this process, we can get calculate the estimated costs for each deliverable, which then provides us an cost for the entire iteration. In addition to deliverables, we also budget a set of hours/days so that we can be compensated for handling small requests, bug fixes, and project management. It’s important to factor these things into your process.
In future posts, I’ll discuss how we’re handling this process while working on multiple projects… as that’s where it can chaos can start if you’re not careful. ;-)
How does your team work? As we’re always evolving our process in an effort so that we can be more efficient and speed up our delivery cycle, I’d love to learn from those in the community.
Older posts: 1 2
