Robby on Rails

Lesson Learned: Git Ref Naming

Robby Russell — Thu, 18 Sep 2008 23:23:00 -0500

Our team has been working our way into the Git world. One of our big client projects is now 100% git while the other is still on Subversion for another month or so. (I’m getting by with git-svn, the gateway drug on that). We’ve had pretty much nothing but success with Git for quite some time, but recently this repository started to get chaotic, which has eaten up time… which isn’t conducive to productivity.

So, I wanted to share a quick lesson that we learned today after scratching our head for a while. It’s important that you avoid having a branch on a remote repository that shares the name of a tag in your local and/or remote repository.

I REPEAT.

It’s bad mojo to have a tag and branch share the same name. Things that you’d expect to just work... don’t. This was causing us to see warnings and errors like the following, which we weren’t really sure what to make of it.

“warning: refname ‘staging’ is ambiguous.

“error: src refspec staging matches more than one.”

This started about two weeks ago when we started a few new remote branches: staging and design. It seemed to be going okay but we managed to muck up things when we merged those two together and some of us were having success fetching/pulling/pushing to staging and others were having to specify :heads/staging and couldn’t have a local branch named staging. Needless to say, it was causing some problems and slowing us down.

This afternoon, we finally noticed in the GitHub interface that there was a tag named staging. Hmm… interesting. We verified this by using git show-ref.


git:(master): git show-ref | grep staging
6a18119ca9.... refs/heads/staging
82caa5f121.... refs/remotes/origin/staging
6a18119ca9.... refs/tags/staging

Notice the tag reference at the end? After asking in #git, we were able to remove the tag with the following:

git tag -d staging

Then we needed to remove the reference of staging on Github with git push origin :staging. (we got rid of the remote branch temporarily as well so that we could clean this up).

The next step was to push our local branch back out to the remote branch git push origin staging:staging.... and now we’re back in business with a simple:

git checkout --track -b staging origin/staging

Anyhow, if you end up having those warnings/errors above, you might take a look at git-show-ref to see what is in your local repository as this could be causing you some unnecessary headaches.

Kudos to Allison for taking the time to really read and digest the git documentation, which helped us figure this shit out. :-)

Since we’re still learning to get around through things like this, if you have any more insight into this issue, feel free to help educate us a bit by sharing your wisdom in response to this post. :-)

MySQL is just a toy

Robby Russell — Thu, 11 Sep 2008 13:04:00 -0500

Are you using PostgreSQL? EnterpriseDB want’s to hear your story at Postgres Rocks

Ubiquity meets RubyURL

Robby Russell — Tue, 02 Sep 2008 20:41:00 -0500

Alex Malinovich decided to take some time this afternoon to write a Ubiquity command for RubyURL using the new RubyURL API. You can take a look at Alex’s Ubiquity code for RubyURL. He’s taking advantage of the JSON support that I added to RubyURL this weekend and JQuery. Be sure to read Alex’s blog post, which includes a screencast! =)

Also! We added this to RubyURL so that if you have Ubiquity installed, you’ll be presented with the following the next time you visit: http://rubyurl.com.

Google Chrome: discuss

Robby Russell — Mon, 01 Sep 2008 21:40:00 -0500

I’m sure that most of you heard the news that Google is releasing a new web browser named Chrome. Their comic for the announcement was very refreshing and entertaining read. Granted… nobody that I know has seen it (as of today)...

For me, I’m really interested in seeing what they’ve done to hopefully improve some of the short-comings of the user experience through their interaction design process. For example, tabs containing their own url/search fields sounds refreshing (I really dislike the hierarchy currently). Also, I’m really looking forward to their dashboard-like default page.

From a web development standpoint, it definitely raises questions about what we’ll be able to do in the coming year(s).

What are your initial thoughts on this? Discuss…

Update: Gary came across this amusing quote from a response by a representative at Microsoft.

“The browser landscape is highly competitive, but people will choose Internet Explorer 8 for the way it puts the services they want right at their fingertips … and, more than any other browsing technology, puts them in control of their personal data on-line,” Hachamovitch said. (read article on CNN)

I’m really not sure what that even means. Don’t we already have our online services at our fingertips? I suspect CNN interviewed the wrong person.. because this person said nothing.

Update #2: Only a PC version available… OSX / Linux are in development. Oh well…

The new RubyURL API

Robby Russell — Sun, 31 Aug 2008 13:55:00 -0500

We’ve just deployed the initial version of an API for RubyURL. It makes it really easy to create RubyURLs and is now open to the public. Should it end up being abused, we’ll consider introducing an API KEY for authenticating and tracking abuse.

In the meantime, you can now start to use the RubyURL API.

For example, the following…


$ curl  -i \ 
        -X POST \
        -H 'Content-Type: application/xml' \
        -d '<link><website_url>http://github.com/robbyrussell</website_url></link>' \
        http://rubyurl.com/api/links  


	...would return the following response.




	I’ll be updating the ShortURL gem in the coming days (unless someone else wants to patch it first wink) to take advantage of new API, versus how it’s currently creating RubyURLs.


	You can see the code & changes for this new API on the RubyURL github site.


	Update with JSON


	I took a little time today to update the API and extend it to support JSON. So… you can now use the RubyURL API to generate RubyURLs via JSON. (see commits)




	Enjoy! If you’re using RubyURL via the new API, I’d love to hear about it. :-)



Flash Message Conductor
Robby Russell — Fri, 29 Aug 2008 16:35:00 -0500
Do you find yourself copying and pasting the same code from Rails application-to-application as new projects start? Our team has a handful of projects in development right now and we notice that some of these reusable components tend to get out of sync when we bounce between projects. So, we’re making an effort to spot these and are creating a handful of plugins so that we can keep them updated between projects. (I’m sure that a lot of you do this as well)


	In an effort to share some of our patterns, we’ll try to release them into the wild for others to use and perhaps if you have better patterns to offer, we’re always interested in improving our approach.


	Introducing Flash Message Conductor


	Over the years, our designers and developers have approached the management of flash messages several different ways. In Rails, the default way to add something to a flash message is to do something like this in your controller.


flash[:message] = "You have successfully signed in to your account."

	What we began doing a while back is to create a few controller helper methods:


add_message( "You have successfully signed in to your account." )
add_notice( "You've Got Mail!" )
add_error( "Oops! Something got fucked up!" )

	Really, nothing too crazy here, just a pattern that our developers have preferred to managing our application’s flash messages.


	Okay, so now for the part of the puzzle that we aimed to make consistent across our projects. Rendering flash messages would usually result in several lines of conditionals in our application layout to check if the flash had any values assigned to it. As we worked with our HTML/CSS designers to define a consistent pattern, we moved our code into a helper for rendering flash messages.


	With Flash Message Conductor, we just need to pop in the following into our application layout.


<%= render_flash_messages %>

	If we had called add_message, it’d render the following:


<div id="flash_messages">
  <p class="message">You have successfully done XYZ...</p>
</div>

	Or, should you have called add_error, it’d render the following:


<div id="flash_messages">
  <p class="error">Oops! Something went bonkers!</p>
</div>

	What we’ve done here is defined a consistent pattern for our designers and developers to follow. We’ll always have a div container that will use a p tag to display the flash messages with a CSS class value that maps to the type of flash message that we’re displaying. This makes it easier for us to reuse the same flash message styling (and tweak if necessary), but we know that it’ll produce the same HTML across our applications.


	Installing Flash Message Conductor


	Like most modern Rails applications, you can install with:



script/plugin install git://github.com/planetargon/flash-message-conductor.git


	Then all of our helper methods will be available to your application. We’ve also included an example CSS file, which you’ll find in the plugin directory.


	Sample output:



Uploaded with plasq’s Skitch!

	Anyhow, we’ve posted the plugin up on GitHub for you all to use, if you’d like to adopt a similar approach. If you have any alternative patterns that has helped your team, do share and I’m looking forward to sharing some more of ours in the near future.


	For more information, visit the Flash Message Conductor plugin on GitHub.


	If anything, hopefully this will inspire those of you who find yourself copying/pasting artifacts from application-to-application to extract that code into it’s own reusable plugin. :-)

   



Git: Push it! (real good)
Robby Russell — Fri, 29 Aug 2008 13:23:00 -0500
After wrestling with some git-remote-branching-merge-problems… I remembered this song…




	If you’re using git, you might add this to your [alias] section in .gitconfig.


	(notice the up-on-this alias)



   



RSpec: It Should Behave Like
Robby Russell — Tue, 19 Aug 2008 21:47:00 -0500
I was going through an older project of ours and cleaning up some specs and noticed how often we were doing the same thing in several places. When we started the project, we didn’t get the benefits of shared groups. Now that we have some time to go through and update some of our older specs, I’ve been trying to take advantage of the features currently available in RSpec. One feature that I haven’t seen a lot of mention of by people is shared groups, so I thought I’d take a few minutes to write up a quick intro to using it.


	To pick some low-hanging fruit, let’s take an all-too-familiar method, which you might be familiar with… login_required. Sound familiar? Have you found yourself stubbing login_required over and over throughout your specs?


describe Admin::DohickiesController, 'index' do

  before( :each ) do
    controller.stub!( :login_required )
    Dohicky.should_receive( :paginate ).and_return( Array.new )
    get :index
  end

 ...
end

	If you’re requiring that a user should be logged in when interacting with most of the application (as in the case of an administration section/namespace), you might want to consolidate some of your work into one shared specification group. The basic premise behind this is that you can write a typical describe block and load it into any other spec groups that you need. For example, in our case, we’ll need to stub login_required in several places. We can set this up in one shared group and reference it wherever necessary.


	For example, here is what we’ll start off with.


describe "an admin user is signed in" do
  before( :each ) do
    controller.stub!( :login_required )
  end
end

describe Admin::DohickiesController, 'index' do
  ...

	However, the new describe block isn’t accessible from the block at the bottom of the example… yet. To do this, we just need to pass the option: :shared => true as you’ll see in the following example.


describe "an admin user is signed in", :shared => true do
  before( :each ) do
    controller.stub!( :login_required )
  end
end

	Great, now we can reference it by referring to it with: it_should_behave_like SharedGroupName. In our example above, this would look like:


describe "an admin user is signed in" do
  before( :each ) do
    controller.stub!( :login_required )
  end
end

describe Admin::DohickiesController, 'index' do
  it_should_behave_like "an admin user is signed in"

  before( :each ) do
    Dohicky.should_receive( :paginate ).and_return( Array.new )
    get :index
  end

 ...
end

describe Admin::DohickiesController, 'new' do
  it_should_behave_like "an admin user is signed in"

  before( :each ) do
    @dohicky = mock_model( Dohicky )
    Dohicky.should_receive( :new ).and_return( @dohicky )
    get :new
  end

  ...

	That’s it! Pretty simple, eh? We can now reference this shared group in any describe blocks that we want to. A benefit to this approach is that we can make change the authentication system (say, we decide to switch it entirely and/or even just change method names, set any other prerequisites necessary when an admin is signed in), we’ll have a single place to change in our specs. (tip: you can put these in your spec_helper file)


	You can learn more about it_should_behave_like and other helpful features on the RSpec documentation site.


	If you have any suggestions on better ways of handling things like this, please follow up and share your solutions. I’m always looking to sharpen my tools. :-)


	Update


	In response, Bryan Helmkamp suggests that a better solution is to define a method in our specs like, for example: build_mock_user_and_login. then calling it in our before(:each). So, maybe the approach above isn’t the most ideal method but I did wantt o draw some attention to it_should_behave_like. I suppose that I need a better example.. another post, perhaps? :-)


	Also, Ed Spencer has posted an article titled, DRYing up your CRUD controller RSpecs, which will introduce you mor to it_should_behave_like.


	Thanks for feedback people!


	Related Posts


	
	Be Careful that you don’t Stub your Big Toe
		Spec Your Views
	

   



Things.app syncs with the iPhone!
Robby Russell — Mon, 18 Aug 2008 23:18:00 -0500
Awesome. Things 1.1 for the iPhone was just pushed to the Apple iTunes Store, which means… I can finally sync my Things.app with my iPhone!


	


	I’ve been using Things for quite a while to manage my life (work and personal) and bringing this to my phone definitely makes my day.


	


	For more information about Things, visit the following sites:


	
	http://culturedcode.com/things/ (Things for OSX)
		Things (iPhone)
	


	I’ll post a review in the coming days as I get a chance to play with it. Just wanted to share the news. :-)

   



Alan Cooper @ Agile2008 slides
Robby Russell — Tue, 12 Aug 2008 18:19:00 -0500
Alan Cooper, author of About Face, has slides from his presentation at Agile 2008 online.


	
	The Wisdom of Experience
	


	If anybody knows if there is video of this talk, please let me know. :-)


	Here are a few skitches from the slideshow.











   



Expanding Rails Boxcar packages
Robby Russell — Mon, 04 Aug 2008 09:30:00 -0500
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.

   



Pair Programming and Micro Projects
Robby Russell — Thu, 31 Jul 2008 21:55:00 -0500
It’s been quiet because I’ve been busy over the past few months. Projects, vacations, and pair programming with our new developer, Nigel. ;-)


	


	In other news, Chris and I launched http://ohmyscience.org (on twitter) in an effort to get a small one-night micro-project out the door.




	I have a growing list of a few micro-projects that I hope to be helping get developed and launched before the summer is over. Stay tuned!




	I hope that you’re all enjoying your summer!

   



ShortURL on Github
Robby Russell — Thu, 24 Jul 2008 10:56:00 -0500
After noticing a few patch requests on Rubyforge.. I decided that I’d put the ShortURL gem up on GitHub as I spend quite a bit of my time there these days. :-)


	
	http://github.com/robbyrussell/shorturl/tree
	


	I’ve also thrown up a few lines of code so that you can get the gist of the gem. ;-)



   



Ruby 1.8.7 on MacPorts causing some problems
Robby Russell — Fri, 20 Jun 2008 16:11:00 -0500
It appears that MacPorts has upgraded to Ruby 1.8.7, which is good news if you’re running Rails 2.1… but if you have an older Rails application… it’s not going to work too well.


	In order to get Ruby 1.8.6 installed with the latest MacPorts, you’ll need to do the following.



  $ mkdir /Users/Shared/dports



$ svn checkout -r 36429 \ 
    http://svn.macports.org/repository/macports/trunk/dports/lang/ruby/ \ 
    /Users/Shared/dports/lang/ruby/


	Then you’ll need to modify your macports to use this new local source. You’ll need to edit /opt/local/etc/macports/sources.conf  and add the following line above the existing rsync record.


	file:///Users/Shared/dports and create that directory


	Next, you’ll want to index this new local source with the following command:


	portindex /Users/Shared/dports


	After that, you can do the following.


	sudo port uninstall rb-rubygems ruby


	sudo port clean rb-rubygems ruby


	sudo rm -r /opt/local/lib/ruby/gems/1.8/doc/rubygems-1.1.1/


	sudo port deactivate autoconf


	sudo port install ruby rb-rubygems


	..and hopefully you’ll have Ruby 1.8.6 installed and be able to retain the rubygems you installed already.

   



Basecamp...
Robby Russell — Wed, 04 Jun 2008 12:13:00 -0500
Kudos to the 37signals team for launching what looks like a nice way to get the word out about their products.


	I’ve been using Basecamp for three years and it’s been a great tool for collaborating with our clients.


	


	Disclaimer: This is my get-rich-quick scheme for the day.

   



New Boxcar plans announced!
Robby Russell — Fri, 30 May 2008 14:30:00 -0500
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:


	
	http://railsboxcar.com
	


	If you’re at RailsConf, be sure to introduce yourself and ask for details. :-)

   



Meet us at RailsConf
Robby Russell — Wed, 28 May 2008 08:46:00 -0500
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
Robby Russell — Fri, 23 May 2008 07:45:00 -0500
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
	



Uploaded with plasq’s Skitch!

	Stay tuned as we’ll be posting more over the next week.

   



Boxcar Conductor plugin moved
Robby Russell — Fri, 23 May 2008 04:23:00 -0500
Update. We’ve moved the Boxcar Conductor plugin for deploying Ruby on Rails applications to a new location on GitHub.


	
	http://github.com/planetargon/boxcar-conductor
	


	You can still submit bugs/feature requests on Lighthouse here:


	
	Boxcar on Lighthouse
	


	Enjoy!

   



Boxcar on Twitter
Robby Russell — Thu, 22 May 2008 22:00:00 -0500
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…


	
	Follow @boxcar
		Follow @planetargon
	


	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
Robby Russell — Thu, 22 May 2008 13:42:00 -0500
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.

   



Was away on vacation
Robby Russell — Sun, 11 May 2008 17:33:00 -0500
It’s been quiet here the past several weeks and that’s because for the first time since I started Planet Argon, I was able to take an extended vacation.


	


	My partner and I headed to France (Paris, Nice, Lascaux II, and Bordeaux) for a few weeks. It was a first time for both of us. I’ve posted some photos on my flickr (vacation set).


	


	I’d like to thank my amazing team for helping make it easy for me to take off for that much time. :-)


	In any event, I wanted to post a few non-technical links…


	
	Veggie Tastespotting (tastespotting without the meat)
		Robby’s Muxtape
		Robby’s Grabb.it 
		Robby on twitter
		Robby’s feedflix (netflix queue/stats)
	


	Link yours up!


	In the coming weeks… I’ll be posting some more thoughts on Project Management, time management, and anything else that seems to come up. If there is anything you’d like me to write about, feel free to drop me a line with a request.

   



RubyURL meets Zombies!
Robby Russell — Tue, 22 Apr 2008 11:43:00 -0500
Last Friday, Greg Borenstein sent me a link to ZombieURL after it got launched. The folks at Bottlecap Labs took RubyURL and threw in Zombies… the rest you’ll have to see for yourself.


	
	don’t click this link
	


	There… I warned you.


	You can check out the source code for ZombieURL on GitHub


	
	http://github.com/bottlecaplabs/zombieurl/tree
	


	You can also grab the underlying source code for RubyURL on GitHub.


	
	http://github.com/robbyrussell/rubyurl/tree/master
	


	I’d love to see what other fun things people come up with to do with RubyURL.

   



Review: Braintree
Robby Russell — Wed, 16 Apr 2008 15:58:00 -0500
Zack Chandler (author of the TrustCommerce gem) writes..


	
		“How do you like Braintree? I’ve haven’t used them yet but may in the future…”
	


	Good question. I was actually planning to write up a quick review of their exceptional service because not many people know about them yet. Now is as good of a time as any.


	We’ve been using Authorize.NET for over four years as it’s what our primary banking institution hooked us up with when we began researching merchant services. However, they didn’t provide us with some of the subscription-based management features that we found with some other payment gateways and we began referring our customers to TrustCommerce. We planned to switch over to TrustCommerce with the development of Cobalt (our new billing and hosting support platform).


	After we began to set milestones for going live with Cobalt, I tried to get in touch with TrustCommerce. I was provided a demo account and really wanted to get in touch with their sales department to get an application.


	...a week goes by. No response. So, I tried to contact them again. No response. tried again… and (yet) again… no response. To date, I have yet to hear back from them.


	This was echoed by one of our consulting clients that said, “their support staff seems real responsive, but I can’t get ahold of anyone to actually get an account.” So, I planned to start looking at other options or stick with Authorize.NET.


	..and then (as if they were listening to my thoughts)... I receive an email from Bryan Johnson, founder of Braintree, a payment processing company.


	(snip)


	
		“I am the founder of Braintree, a payment processing company. We provide credit card and electronic check processing, simplified PCI DSS Compliance through remote storage of credit card data, payment gateway/virtual terminal, etc. We’re a one stop shop.”
	


	He goes on to introduce himself and explain that they’re really focused on subscription-based services, which is exactly what our new centralized billing app is handling.


	So, since I hadn’t heard from TrustCommerce, I requested a demo with Braintree. We were able to take advantage of the hard work that has put into the ActiveMerchant project, which already works with Braintree. So, our application that we’d been focusing on integrating with TrustCommerce was just a few lines of code away from working with Braintree.


	While I’m sure that many people have had great experiences with TrustCommerce (as I did when I worked with their support team while working client projects)... not being able to order an account isn’t doing them any favors.


	So, we just launched and now running Cobalt with Braintree as our backend for managing recurring credit card processing. Their customer support has been great so far. In one case, I messed up some security settings and locked myself out and after they saw that I had failed to login a few times, I received a call from one of their support people. I didn’t prompt it… they took the initiative to call me. She said she’d look into it and called me back when she figured out what I had done wrong. :-)


	On Monday afternoon, after I announced that we launched Cobalt on my blog, I got a congratulations from another of their developers who congratulated us and wished us the best of success.


	So… Zack. To answer your question, “How do you like Braintree?”


	My answer is… I think they’re fantastic so far. Their web interface for managing your account could use a few IxD eyes, but we like that it’s minimal and most importantly… the core functions of their product appear to be working great. Our team has now talked to roughly 5-6 different team members at Braintree and have nothing but great things to say about those interactions. Great customer service that definitely seems to echo that they want their customers to be successful and are here to do what they can to provide us with the tools we need to fulfill our goals.


	I only wish that we had the same service from all of our vendors.


	Bryan, thanks for introducing yourself. You have a great team.


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


	Related Posts


	
	Be Careful that you don’t Stub your Big Toe
	

   



Boxcar Conductor: Rails deployment made easy
Robby Russell — Tue, 15 Apr 2008 12:16:00 -0500
In a previous post, I showed how we’ve been working on an interactive deployment process for Rails applications to reduce the time it takes to deploy to a Boxcar.


	We began to move our Boxcar deployment recipes into it’s own Rails plugin and just made it available on GitHub.


	Introducing Boxcar Conductor


	The Boxcar Conductor plugin aims to automate the entire process for deploying to your Boxcar. We’re down to just a few simple commands to run to get your application up and running. While mileage may vary with other hosting providers, we did want to open up this work to the community and centralize our work with the community of Boxcar customers who have helped us build and test these tools.


	Install Boxcar Conductor


	If you’re running on Edge Rails… you can take advantage of the new support for installing plugins in git repositories.



  $ ./script/plugin install git://github.com/planetargon/boxcar-conductor.git


	note: If you’re not using edge rails, you can download a tarball and install the plugin manually.


	Installing the plugin will add a custom Capfile and config/deploy.rb, which has a few things for you to define based on your Boxcar subscription.


	Configure Your Boxcar


	Once the plugin is installed, you can run the following task:



  $ cap boxcar:config


	This will ask you a few questions about your deployment needs.



Uploaded with plasq’s Skitch!

	
	Which database server will you be using? (along with db user/pass info)
		How many mongrels should run in your cluster?
	


	After a few quick multiple choice answers, you’re application is ready to be deployed and you can run an Boxcar-specific deployment task.



  $ cap deploy


	We’ve also created a new public project on Lighthouse so that you can submit tickets and ideas to us. With Boxcar, we’re really aiming to remove as many steps from the deployment process that aren’t necessary.


	To follow along, visit the project on lighthouse or GitHub.


	If you’re interested in learning more about Rails Boxcar, feel free to drop us a line.


	Related Posts


	
	Deploying Rails with an interactive Capistrano recipe to your Boxcar
		Announcing Cobalt and monthly subscriptions for Boxcar
	

   



Announcing Cobalt and monthly subscriptions for Boxcar
Robby Russell — Mon, 14 Apr 2008 10:24:00 -0500
We’ve been designing and developing a new centralized billing platform over the past few months and late last week, we launched it! Along with this new billing platform, we launched another new application, Cobalt, which is a new account management and support tool for our hosting customers.



Uploaded with plasq’s Skitch!

	We’ll be migrating all of our past customers over to this new system in time, but are initially using it for new Boxcar customers.


	


	We’ve been building the new system to use Braintree as our new credit card payment gateway. With this switch, we’re also introducing monthly subscription rates for Boxcar, which means that you can try it out month-to-month now.


	Over the next few weeks/months, we’ll be announcing several features to Cobalt that will ease your Rails deployment experience.


	I want to thank all those on my team that helped get these new applications up and running.


	If you’re looking for professional VPS-based Rails hosting, hop on our train by ordering a Boxcar today for $99/month!


	For more information, visit railsboxcar.com or Planet Argon.


	Also, be sure to follow Boxcar on twitter.

   



Interviewed by Hanselminutes
Robby Russell — Fri, 11 Apr 2008 08:31:00 -0500
Earlier this week, Scott Hanselman from Hanselminutes came down to the Planet Argon studio to interview Andy, Gary, and myself about adoption of Git.


	


	The podcast interview is available online now.


	Thanks for stopping by Scott!


	update: I’d recommend that you also check out another episode of Hanselminutes when he sat down to speak with David Heinemeier Hansson and Martin Fowler.

   



Portland is calling... (you)
Robby Russell — Fri, 11 Apr 2008 01:30:00 -0500
We’re not looking for rock stars or ninjas at Planet Argon. ;-)


	We’re looking for individuals that share our core values.


	
	COLLABORATION – We believe that an open dialogue between all members of a group helps to produce more reasoned and intelligent decisions.
		ENTHUSIASM – We recognize the unique power of people who are passionate about their craft. We believe that fun is an essential ingredient in a collaborative and vibrant company culture. We think happy people make better software.
		COMMUNITY – We are part of many communities. Our neighborhoods, our cities, our workplace, and our professional communities. We give back to our communities by implementing socially responsible business practices and sharing our knowledge and tools with our peers.
		VERSATILITY – We believe that it is important for our team to be open and flexible, as well as the work that we do. This allows us to adapt to change and encourage innovation.
		EXECUTION – We value action and when people make things happen. It is important that we follow through on our commitments, plans, and ideas.
	


	..maybe you’re a .NET/Java/PHP/Python developer (who secretly plays with Ruby on Rails at night/weekends). We’re looking for an intermediate-level Rails developer to join our team. Ideal candidates would be in the Portland, Oregon area or willing to relocate.


	


	If you’re interested, take a moment and introduce yourself.