Big Bang Technology Blog

Installing Postgresql for use with Rails 3.x using Homebrew on Mac OS X Lion

2012-05-18T00:00:00+00:00

This installation process has always frustrated me and I always do something wrong. I decided to finally document it.

Pre-Requisites

Make sure that Homebrew is installed and `brew doctor` is happy.
Make sure rvm (or equivalent) is installed and configured.
You know how to edit files in terminal and are comfortable using sudo.

Installation

The biggest gotcha is that by default OS X Lion comes with postgres installed already. It resides in /usr/bin which by default takes precedence over /usr/local/bin/ which is where homebrew will install postgres. To fix this edit /etc/paths to order /usr/local/bin above /usr/bin. Your file should look like this:

*Note: You'll need to use sudo to edit this file.

Install postgres using homebrew

Follow all installation instructions

Make sure you pay attention to the output after installing via homebrew. You need to make sure you've done the following before proceeding:

Initialize the database
Setup the server to run using launch
Install the pg gem using the proper arguments

Verify paths are correct

*Note: If this command returns something different you may need to restart your terminal session or double check the steps above.

Create admin user

Add pg gem to Gemfile

gem 'pg'

*Note: Make sure to remove any other database adapters such as sqlite.

Add database details to the config/database.rb

*Note: my_rails_app should be the name of the user you created above.

Test & Verify

*Note: If this returns without errors then you've done everything correctly!

Javascript Hack Night #10

2012-04-09T00:00:00+00:00

Hey folks, I wanted you to know that I'm not going to be facilitating this months Javascript Hack Night as I'll be unavailable Tuesday night, my partner Max Cameron will be here though and everything else is business as usual. Feel free to bring your own ideas or come with an open mind willing to help others with their project. Hit up the meetup page for more details.

Facts:

Big Bang Technology HQ - 642 King Street West
Tuesday April 9th at 6:30 PM

See you there!

Effectively owning your roadmap

2012-03-25T00:00:00+00:00

A few good tricks to help you maintain influence over your product roadmap.

As products grow balancing the feature requests from customers and internal stakeholders can become increasingly difficult. The more people involved, the longer the list gets and the harder it becomes to identify what the most important things to focus on are.

It can be even more of a challenge convincing those that hold the purse strings to sign off and give you the resources you need to execute. If you are a Product Manager like me, you may not have the authority to make these decisions on your own but it is your job to know and advocate for what is best for the product. So to ensure your next planning session produces a roadmap that everybody is happy and committed to, take a look at some of the persuasion techniques outlined in Influence: The Psychology of Persuasion. This book is primarily targeted at sales professionals but is full of great ideas for the software pro as well.

Commitment and Consistency

Engage the decision makers. One of the most effective ways to earn trust and reach an agreement is to involve the stakeholders in the process. This doesn't have to be complicated, for example when it comes time for planning here at Big Bang we like to write each feature/release down on sticky notes and then work together to prioritize them. This is a common practice in the agile development community and is not only a quick way to get organized but by getting stakeholders to physically write things down and agree on the priority they are far more likely to honour that commitment... even if the estimates or cost do change a bit in the future. The more people that witness the commitment the better so don’t be afraid to post their work on the wall where everyone will see it.

Liking

People tend to be easily persuaded by others that they like or respect. If a key stakeholder is a little unsure find a second opinion from someone the stakeholder often looks to for advice or guidance. If they can see that others that they respect are on-board it will make it much easier for them to make the commitment.

Scarcity

Create the opportunity to make the required decisions. Whether it is a “new” opening in the release calendar or some newly available resources, creating that “limited time offer” will help generate the necessity to act quickly in order to take advantage of the opportunity.

Social Proof

If you are in catch up mode or are finding it hard to compete use this to your advantage. Your VP or CEO may not be aware of your platforms vulnerabilities. If there is something others have that your product needs, don’t be afraid to show your stakeholders how and where you are exposed. If a feature has already been validated in the market there is less risk associated with the commitment making it an easier decision one to make. If others are doing it, it is much easier to follow than to trail blaze.

Reciprocity

Sometimes you need to give in order to receive. During your next planning session don’t be afraid to ask for more features and releases then you are prepared to settle for. By asking for more, getting shot down and then retreating to your initial stance you are likely to be more successful and get buy in for what you really wanted all along. Being able to make a concession or 2 to the other party their natural instinct is going to be to find a way to return the favour. By following up with a smaller option your stakeholder will be more likely to agree and repay you after they have taken other items off the table.

So the next time you are walking into that big meeting, keep a few of these ideas in your back pocket and you will no doubt emerge successful.

Javascript Hack Night #9: Spring Time!

2012-03-12T00:00:00+00:00

Don't let the beautiful weather deter you from hacking on Javascript. This month we're doing a regular evening of pizza and programming. Feel free to bring your own ideas or come with an open mind willing to help others with their project. Hit up the meetup page for more details.

Facts:

Big Bang Technology HQ - 642 King Street West
Tuesday March 13th at 6:30 PM

See you there!

Links of the Week 10

2012-03-07T00:00:00+00:00

This Week: Design, HTML5, Rails, Dev-Ops, iPad, Privacy Policy

Design

Developers Should Design

I am trying to build a company full of developers like this.

HTML5

HTML5 Clear

It's definitely not as polished as the Objective-C version but this shows that we're not that far off.

Replacing the -9999px Hack

A better way of doing the -9999px hack.

Open Sourcing BankersBox

Seems like a much cleaner way of interacting with LocalStorage.

CardinalPath / gas

A better way of working with the GA JavaScript API.

Rails

Rails Master GitHub Security Mess

The best overview of the situation from Mike Gunderloy

Edge Rails: PATCH is the new primary HTTP method for updates

I will embrace this change. PATCH is the right way to think about this type of interaction.

jfirebaugh / konacha

Integrate the fantastic Mocha testing framework into your Rails stack.

atmos / smeagol

I think this will greatly decrease the cost of setting up a new developer workstation.

iPad

How to Disable iPad Home Button (Kiosk/Store Demo Mode)

Self-Explanatory

Photoshop Touch app arrives for the iPad

Another step towards world domination for the iPad.

Privacy Policy

tumblr / policy

A great way of showing changes to your privacy policy by using GitHub.

iubenda - privacy policy generator

Hey man, you've got a privacy policy in your privacy policy.

An Async Experiment

2012-02-27T00:00:00+00:00

Or: How we let our agile team work remotely and asynchronously.

As our team grows, it’s become apparent that not everyone is necessarily ready to drop bombs at 9am sharp. During one of our recent retrospectives, we identified several “sacred cows” that were regimenting our work. One of them happened to be our nine-to-five workday. So we decided to slay it.

And since we LOVE experiments, we decided to to break our highly controversial, never imitated, nine-to-five workday to see if a less structured schedule would improve morale and help us work more effectively.

The basic ground rules are simple:

We’re still working 40 hours per week, slackers!
Come in whenever you want, or work from home
When working, you must be hanging out in the Campfire room
Ask for help if you are blocked - still no heroes here
Our weekly iteration goal is whatever our natural velocity is
Dave Huntington Banks, the Product Manager, controls task priority
When you start your day, tell the gang what you did yesterday, what’s blocking you, and what you’re going to do today
Check the calendar for important company events so you don’t look like an ass walking into someone’s presentation
If you are not in the office for an important event, we’ll Skype you in

And most importantly...

Be here Mondays at Noon if you want to participate in our world famous company lunch!
Be here every second Friday for our retrospective

The team is responding quite well to this experiment, and we definitely have an interesting mix of early risers, with others coming in later. (Personally, I’m mixing it up to find my groove.) We’ve also noticed some pains, but nothing mission critical yet. Watch for a post-mortem once we’ve let the experiment play out for a few more weeks.

Links of the Week 9

2012-02-22T00:00:00+00:00

This Week: An Essential Video, Static Analysis Tools, Web Developer, Community, Rails, Design, Misc

Essential Video

Bret Victor - Inventing on Principle

Are you a craftsmen focused on skills? How about a problem solver focused on the opportunities? Are you willing to take responsibility for a principle and become an activist? This mind-blowing video will force you to question what you spend your time doing and why.

Static Analysis Tools

Alistair McKinnell and Jason Cheong-Kee-You gave a great talk last night at XP Toronto on Commonality and Variability. The big takeaway was you should be using static analysis to find code smells and make them visible to your team. I've compiled a list of the best tools currently available for modern Ruby projects.

Web Developer

Front-end Job Interview Questions

Saved for reference. I'm sure we'll ask some of these questions in our next job interview. Thanks to my friend Darcy for doing all the hard work for me.

Flickable.js

More and more evidence that native apps are overkill for most problems.

JavaScript Closures Explained

If you're just getting started with JavaScript closures can be very confusing. Here is yet another blog post explaining them in detail.

A fresh look at JavaScript Mixins

A great way to write testable and maintainable Javascript. Used heavily by our friends Dan Wrong and Angus Croll at Twitter.

Community

Face of the Faceless

A great argument for putting your open source projects on an individual account instead of on an organization account.

Vendor Prefixes - about to go south

Probably the best starting point to build context on the vendor prefixes issue.

The Vendor Prefix Predicament: ALA’s Eric Meyer Interviews Tantek Çelik

Another take on the vendor prefix issue, this time an interview with Tantek.

Rails

rumblelabs/asset_sync

A sweet way to sync your assets over to S3 when you pre-compile them. Designed for use with Heroku. We'll probably get this to work very easily with CloudFront.

Developing a RubyGem using Bundler

I keep looking for this when I need it. Saved for reference.

Design

Basecamp Next: UI Preview

You might think client side MVC is the only way to build websites these days but you'd be dead wrong. 37signals shows time and time again that simplicity and developer happiness are the only things worth optimizing for.

Offscreen Magazine

Physical media of the best kind.

Misc

Presentation about RubyMachine

I'd like to try building a small app in this.

Why We Created Julia

This new programming language seems to have lofty goals, but it also seems frickin' badass. Bring it on!

Xcode, GCC, and Homebrew

What a great story. I'm a big fan of the smaller osx-gcc-installer and the fact that this is now an officially supported project by Apple is even better.

Javascript Hack Night #8: HTML5 Video

2012-02-13T00:00:00+00:00

This month my friend Wes Bos is giving a short talk about HTML5 video to kick things off. This is a small deviation from the normal hack nights. We're hoping that it will give a little bit of focus to the night and let people try things out with video. Hit up the meetup page for more details.

Facts:

Big Bang Technology HQ - 642 King Street West
Wednesday February 15th at 6:30 PM

See you there!

Links of the Week 8

2012-02-08T00:00:00+00:00

This Week: Essential Reading, Testing, Ruby/Rails, Database, Javascript, Design

Essential Reading

The Hacker Way

Essential Reading.

Introducing Chrome for Android

I hope this spurs some competition from Apple. I'd love to use that remote debugging everywhere.

thoughtbot presents: The Playbook

Noticed a bunch of new improvements on the playbook. Very inspiring.

Testing

Decoupling Data from Presentation

I'm not a fan of using data-attributes for this purpose but it's an interesting take. Storing state in data-attributes always seems so non-semantic to me.

Yes, You Should Write Controller Tests!

Yes. Yes you should.

Acceptance and Integration Testing With Kookaburra

I feel like I dreamt about this after reading the same book. This is killer, I can see even non-developers using the Domain Driver.

Ruby/Rails

ileitch / hijack

I'm not sure where I would use this, but I have a feeling I should save it for reference.

josevalim / active_model_serializers

I really want these to be in Rails. In any case I really want to convert our application to use them. Great idea.

assembler / browsernizer

An easy way to inform people that they need to upgrade their browser.

Ruby Trick Shots

Cool tips that you may not know about Ruby.

Database

PostgreSQL by Harold Giménez

Cool Presentation on PostgreSQL. Thanks to @releod for tweeting it.

VIM

Vim anti-patterns

I do basically everything that they say you should not. Slowly...weaning...

JavaScript

Backbone versus Ember Transcript

Long and civil argument between wycats and jashkenas. Very very interesting.

UIkit Modern UI components for the modern web

Some of these components are pretty sweet. I can see myself using them on new projects.

JavaScript Jabber

New weekly JavaScript podcast.

Design

engineyard / engineyard-theme

This is an interesting way to make your theme easily includable in other projects. We're following this approach for our next redesign of Woople.

What's the difference between a dashboard and an activity stream/feed?

Surprisingly interesting thread. Last version of Woople we basically called everything a dashboard. Next version we be much clearer.

Pears

I was a little confused at first thinking this was another html/css framework. It's actually much better, a framework for documenting your framework. Huzzah!

Links of the Week 7

2012-01-31T00:00:00+00:00

This Week: Testing, Front-End, Back-End, Reference, Teamwork

Testing

commondream/tconsole

Seems like a great way to remove the startup overhead without hassling with the configuration.

Taming a Capybara - Emmanuel Oga's Software and Stuff

More on getting capybara to run smoothly. I'm glad the community is sharing these sorts of things, we're definitely benefiting from it.

The evil unit test

I 100% advocate testing behaviour over implementation. That doesn't mean mocking is bad. It means you need to use it to mock out dependencies.

Front-End

HTML5 Please - Use the new and shiny responsibly

A good way to lookup how pervasive the feature you're about to use is. Ideally you'd just use Modernizr and make your application work either way.

Gettext style i18n for Modern JavaScript Apps

I know of a few front-end heavy projects that should be using something like this.

Color - Method of Action

Another cool game designed to teach developers about design.

Back-End

Inject that Rails Configuration Dependency

I love any article that helps me understand dependency injection more. We've recently started using our config more as we're connecting multiple applications together. This does make testing bothersome. Great tip.

On My iPad

A seriously great list of applications. Fraser is definitely an iPad expert.

PUT or POST: The REST of the Story

Great resource for API developers out there. Are all your PUT requests Idempotent?

My five favourite "hidden" features in Rails 3.2

Some of the lesser known features in Rails 3.2

Reference

Node.js reference

A more readable form of the Node.js documentation.

The Little Redis Book

I'm going to use Redis for something one of these days. Saved for reference.

Teamwork

Scaling GitHub

Zach shows why GitHub is so awesome.

Why Software Development Estimations Are Regularly Off

An fresh perspective on why software estimates are bad bad mojo.

Links of the Week 6

2012-01-23T00:00:00+00:00

This Week: Movies!, Gems, Essential Geek Reading, Reference, Teamwork

Movies!

Wat

Seriously hilarious. Also an awesome catalog of e-learning videos. Why didn't I know about this sooner?

Gems

acts_as_api

Putting view logic in your model is never a good idea. This is an anti-pattern. Use a presenter to handle this.

Factory Girl 2.5 Gets Custom Constructors

While we heavily use Factory Girl I can't help but think that it keeps getting more complicated. We're relying on stubs a lot more these days.

Essential Geek Reading

The Trello Tech Stack

I love this stack. Although I'm not completely sold on 100% single page apps things like pushState are slowly convincing me.

Distraction is a Symptom of a Deeper Problem: The Convenience Principle and the Destruction of American Productivity

We believe the right kind of distraction is a symptom that knowledge hasn't been properly socialized on the team. Cross team interruptions however are definitely bad.

An object is not a hash

I can see a whole new generation of javascript injection/cross site scripting issues because of this.

Reference

JSRef - JavaScript Reference Manual

Seems like a YARD style reference for JavaScript built on top of the MDN

How to run rvm scripts as cron jobs?

Dave was having problems with this one earlier this week.

Teamwork

visionmedia/git-extras

Seems like there are some good commands in here for working with teams.

Advice for Lean Startup Machine Toronto Attendees

2012-01-18T00:00:00+00:00

Last year I flew down to Boston with some colleagues and we participated in Lean Startup Machine. I’m not lying when I say it changed my life. All of a sudden, I could separate and connect the theory of customer development from its practice. But more importantly, I was stripped of the fear (and any other excuse) of finding customers and trying to sell them a product.

I also learned a ton about customer development and I've been trying to share those lessons ever since. After that experience, I immediately knew that Toronto needed this event. This year, I’ve been lucky enough to be acting as an LSMTO event organizer and participate as a mentor. And because of my prior experience attending as a participant, I’d like to share what I learned last year so you can make the most out of your weekend.

Joining a Team

This is the first big decision you’re going to make when you show up at LSM. A few people have asked me if they should try to pitch the idea they’re working on, or if they should join another project. My advice to them has always been the same; whether you’re pitching your own idea or joining another team, there are three things to keep in mind:

Customers - Choose a product that has customers who will be accessible to you over the weekend. Definitely avoid projects that can only be sold to the VP Marketing at fortune 500 companies. They don’t work weekends.
Agility - Choose a project you’re not afraid to change. This might be a good argument not to pitch the project you’ve been married to for the past two years. LSM is about rapid change based on validated learning. So if you’re afraid to kill your ugly baby, don’t pitch it.
Balance - find a team with a balance of designers, developers and “marketers.” The last thing you want is to join a group where nobody can install google analytics on your landing page.

Tips for Winning

I believe the winning team will be the group of people who show the most acceleration in their pirate metrics based on the pivots they make. Each pivot should be based on validated learning. So how do you make that happen?

Once you’ve picked a product to work on and you’re ready to get started, I would suggest that you split the group into two teams: the Inside Team and the Outside Team. The main strategy is for both teams to collaborate on structuring experiments, and then run each experiment independently to accelerate the learning process. Consensus among both teams is paramount, so there are certain activities which should be done together. Namely, defining the problem, defining the solution and agreeing on each pivot.

The Inside Team is responsible for testing the viability of the online channel. They’ll be putting up landing pages and A/B testing various pricing models and value propositions. They’re going to be writing blog posts, and building out the MVP.

The Outside Team is responsible for hitting the streets, making customer contact, validating problem areas, leading solution interviews and selling the MVP face-to-face. Personally, I think this is the place where you want to be.

After each group completes a round of experiments, you should regroup, review the results, brainstorm many possible pivots, decide on which one should be implemented, and then start the experiment cycle all over again.

How Can Mentors Help?

We have some great mentors attending the event that can help you out in a few different ways. The mentors are your objective source of feedback, your fresh eyes, who can tell the forest from the trees.

They’ll let you know if they see an opportunity for you to pivot when you’re slamming your head against the desk. They’ll help you brainstorm novel ways to put yourself in front of customers, and they’ll do their best to help you structure your customer development experiments. And most importantly, they’ll motivate you, hold you accountable, and force you out of the building.

That’s it

I can’t wait to see everyone out at LSMTO. Good luck to everyone, and remember to look out for me if you want to work with the most aggressive mentor on the floor. And if you want to talk more before the event, feel free to get in touch.

Links of the Week 5

2012-01-17T00:00:00+00:00

Instead of posting links the minute I find them, I've started holding on to them for a week and then blasting you with them if they still hold my interested by the end of the week.

The Twelve-Factor App

If we wanted to move our app to Heroku here is how we'd have to design it!

Evaluating alternative Decorator implementations in Ruby

Decorators, and presenters, and patterns! Oh, my!

Media queries and multiple columns

A cool way to use @media queries to create dynamic columns based on the vertical height. Not applicable to our upcoming redesign though.

wbailey/command_line_reporter

We have lots of scripts which execute on the command line. This seems like a good way to get feedback from them. We currently use "puts" :)

Factory Girl 2.4.0 (Factory Girl 2.4 Goes Meta)

Our application has 6000 factory instances in it. This should speed things up a lot.

Paulasmuth/fnordmetric - GitHub

Seems like a self-hosted version of mixpanel.com with less analysis.

Exceptional Ruby: Master the art of handling failure in Ruby

Avdi has some great blog posts and this is sure to be great as well.

Android Design

Design reading for all, not just Android developers.

Links of the Week 4

2012-01-11T00:00:00+00:00

Instead of posting links the minute I find them, I've started holding on to them for a week and then blasting you with them if they still hold my interested by the end of the week.

Resourcing Pair Programmers in an Agile Team

2011-12-27T00:00:00+00:00

Everyone knows that practicing pair programming and agile development are the best ways to produce high quality software as fast as possible. But setting these pairs up is a lot harder than it looks. Here’s how we do it. How can we improve?

The Challenge

Resourcing pairs in an agile shop is difficult for a lot of reasons. One of the big challenges is that they have to constantly change. While one of the big objectives of pairing is to reduce developer blind spots, the same thing can also happen if you pair the same developers together for too long.

To further complicate matters, not everyone starts the day with a clean slate. They might have started a story yesterday and not finished it, or they might be leaving for an hour to go to the doctor’s office. The big point is that not everyone has the same amount of hours to devote to writing code.

Every developer has areas of expertise - and every developer has areas where they’re a novice. One of the biggest opportunities pairing brings to our team is to have these areas of specialization transfer to other developers. And unfamiliarity increases the quality of the pair because the expert is forced to articulate the challenge in a simple way to the novice.

In our experience, the key to resourcing pairs is to match people based on expertise and availability. We don’t have the perfect approach to resourcing, but we wanted to share what we’ve been doing lately in hopes of learning from you.

Our Approach

Every morning we meet for our day-planning meeting. It runs from 9:15am to 10:00am. The first order of business is to review the work each person completed yesterday, and review the work they started but didn’t finish. This step is repeated for each team member. Based on the commitments they have, we count the hours they have available for writing code, and we write it on the whiteboard.

The next thing we do is open Pivotal Tracker. As a team, we review each user story that was completed yesterday, as well as each story that was started but not finished. Then, we begin selecting new stories from the current iteration - which have already been prioritized by our product manager and customer support agents.

After we select each story (starting with the ones that weren’t completed yesterday), we create a pair based on their available hours, and their level of familiarity with the particular story. We’re looking for people who have about the same amount of productive time available. We also keep an eye out for an expert and a novice. We keep assigning stories until all the pairs have a full plate.

Next, we sequence the stories - discussing any dependencies or scheduling conflicts, and discuss any risks associated with other commitments. Once that’s done, we open up the floor to questions, and when those are done it’s time for announcements, which can be professional or personal. And we generally save a few minutes to look at one of Dave’s awesome youtube favourites.

If you like lists, I’ve included one below so you can review it and put it use. If you have an idea on how we can improve the way we resource pairs, please find me on twitter or write something more detailed on hacker news.

The Big Bang Morning Meeting:

Each person states yesterday’s accomplishments
Each person states work that was started but not completed
The number of available hours are recorded on the whiteboard
Repeat for all developers
Open Pivotal Tracker
Review work finished yesterday
Review work started but not completed
Select a story from the top of the current iteration (including stories started but not finished)
Assign the pair based on available hours and Expert/Novice
Sequence the activities to account for prior commitments
Assess any risks
Questions and Announcements
Get to work!