It took me about 30 minutes to figure out how to point a Gemfile to a GitHub Enterprise repository, in a GitHub organization, in a branch. Here’s the solution I whipped-up:
gem 'mygem', :git => "http://username:email@example.com/organization/mygem.git", :branch => "bugfix/mybranch"
However, do not check this in to your repo. Your username/password is in plain text.
If anyone has a better suggestion, please post it in the comments. Thanks.
I’m currently having a blast leading the technical team behind the LivingSocial Takeout & Delivery web site. One of the challenges of a growing team is maintaining appropriate amounts of communication. You want everyone to know everything that’s important, but not everything. Otherwise, you end up being a case study in The Mythical Man Month.
Although our team did not follow this plan when it was ramping-up, hindsight reveals the need for a team debt management strategy as it grows. After mulling over it for awhile, I’m fairly sure that if I lead a new team in the future, we will follow this path:
First engineer to join the team
- Sets-up the source code repository
- Writes a starter project README
- Provisions the application and team notification email addresses
- Wires-up application notification email(s)
- Sets-up the continuous integration (CI) server
- Provisions the CI notification email address(es)
- Wires-up CI notification emails
- Sets-up the team’s Campfire
- Wires-up commit and deployment notifications (Campfire and/or email)
- Sets-up a scrubbed production database dump that engineers can use for local development
What tech team debt tools do you typically employ, and when do you employ them?
A few years ago, I quit my job to build a bootstrapped startup called SandwichBoard–a content management system for restaurants. Patrick Joyce and I put $5,000 into the business and made a leap of faith to live off savings and occasional consulting gigs.
After we got the sales routine down, we were growing at a steady pace, but not early or fast enough for our personal lives. We both really wanted to marry our girlfriends. We needed money, and ultimately had to ditch the bootstrapping salaries. I was elated to be marrying the woman I had been waiting for my whole life, but throwing-in the startup towel felt like a huge loss. It was something I had been working towards for a long time, but giving it up to marry my wife was the best decision I ever made.
Now that I’ve had time to reflect on what went well and what didn’t, I have my own list of lessons learned–things I would do again or make sure never to go near when building a business or product. But you’ve already seen that sort of list before. Instead of dumping a bunch of do’s and don’ts on people, I would rather leave them with an encouragement–one that will give someone else the courage to take that leap of faith.
My lesson learned: even though the startup plane may come to a fiery end, the pilots have ejection seats.
Our efforts were not wasted. While building SandwichBoard, we became proficient in Ruby on Rails, resulting in a great product and more than two significant open source contributions. This helped land Patrick a position at a company called Hungry Machine and me a job at Razoo. Taking that risk propelled us from working typical IT jobs into the startup world. I’ve had fun just about every day since I took that leap of faith, become a better engineer at an accelerated rate, been able to work with incredible people, and turned that savings loss into a short-term investment.
Patrick’s employer renamed itself LivingSocial, and his first major responsibility was to develop a small site called LivingSocial Daily Deals. (Maybe you’ve heard of it.) I rejoined Patrick this July and am leading the technical team responsible for building LivingSocial’s latest local-commerce product: Takeout & Delivery–restaurant takeout and delivery ordering (currently only in Washington, DC). It’s a fitting end to the SandwichBoard story.
Results may vary, but I still think it’s worth a try. Give it a go; jump off that cliff!
I have never understood why Rails doesn’t strip attributes by default. I know at least one person who tried committing it to core, only to have it rejected. I always end up installing the strip_attributes plugin.
I’m ramping-up a new Rails 3 project, with Shoulda 2.11. I installed strip_attributes. It works, but the strip_attributes Shoulda macros don’t work anymore. I could take the route of upgrading the plugin, but then I would “have to” also refactor the Shoulda macros since macros have been ditched for matchers. Then I’d have to re-write the tests. At that point, I might as well make it a gem and add that feature I’ve always wanted. But, I’m just not ready for that sort of commitment right now (#gtd_maybe_someday).
So, here’s a short line to add to the end of
strip_attributes/init.rb to get the old strip_attributes Shoulda macros working again:
require File.expand_path(File.join(File.dirname(__FILE__), 'shoulda_macros', 'macros.rb')) if Rails.env.test?
One of the privileges I have experienced in my professional life is having worked with Jeremy Keith of Clearleft. I learned a lot from the author and web developer from our interactions and by studying his code.
One example is a thumbnails carousel he designed. If the browser does not have JS support, the thumbnails are arranged in a grid. If the client does support JS, he wraps-up the thumbnails in a single row inside a horizontally-scrolling carousel, so they can be browsed left to right. The carousel presentation of the thumbnails requires a different set of CSS rules, which override the vanilla styles.
Any site I’m involved in will be following suit.
As a software engineer and fledgling product designer, my focus naturally gravitates towards objects: architecture, design, credit cards, order invoices, products, users. However, interactions are what engage users: creating, enjoying, joining, sharing.
Time to level-up.
- Page-specific styles. I see CSS as a way to define general styles that affect large portions of a site (using classes). If you want to do something really, really special on a particular page, just put it inside the handful of elements that want to be different as inline styles. (ID selectors are a dying breed.) There’s no need to define rules in a global style sheet if they’re not really global. If the page has a lot of inline styles, and they are making the markup unmanageable, you can always extract the styles into a page-specific stylesheet. One extra HTTP request on one page (or a handful of pages) won’t kill you or your users.