Install pandoc from source on Ubuntu

Here are some basic notes on how I installed from source on my Ubuntu x86_64 machine.

Generally followed the build from source instructions.

sudo apt-get install ghc6  # this bootstraps so we can build ghc 7

# get latest ghc
wget http://haskell.org/ghc/dist/7.0.3/ghc-7.0.3-src.tar.bz2
tar -jxvf ghc-7.0.3-src.tar.bz2
cd there
./configure
make
sudo make install

# get cabal
wget http://lambda.galois.com/hp-tmp/2011.2.0.1/haskell-platform-2011.2.0.1.tar.gz
tar xvfz haskell-platform-2011.2.0.1.tar.gz
cd there
./configure
make
sudo make install

# get pandoc
# edit ~/.cabal/config to uncomment user-install and set the value to False (so that we get global installation)
sudo cabal install pandoc

pandoc -v

My Lean Startup Machine Boston Experience Report

Lean Startup Machine weekends are a chance to apply the lean startup methodology by trying to build a startup in 48 hours. One of the key goals is demonstrating a process of learning. Learning takes various forms, and might include testing hypotheses through conversations, collecting qualitative and quantitative indicators of interest through surveys, creating MVPs to test acquisition methods and value propositions, getting signed letters of intent to buy a conceptual product, and maybe getting some cold hard cash in hand. Throughout the weekend, teams iterate and pivot as they learn more about their idea and the market through interacting with their customers. A panel of mentors works with the teams when they get stuck, and judge presentations at the end of the weekend to determine a winner.

When I first heard about the LSM in Boston, I signed up. I asked Wes Winham from Indy to join me, and we set off to Boston. This post talks about what I did and saw, and what I learned in the process.

My experience

I had been reading the various resources of the lean startup community for over a year, and was excited to actually put the principles to the test and test out my skills. Doing is a different beast from reading. My personal goal was to work with the team I joined up with to demonstrate that we could work through various difficulties and learn more about the lean startup methodology. I thought whatever team I joined had a chance to win, although it was not my focus.

Our final presentation (PDF, no longer available) gave a good overview of what we ended up doing over the course of the weekend.

The energy and intelligence of the people at this event was a little intimidating at first. There were fifty extremely smart and capable people present. I was a bit out of my element in a city halfway across the nation, but then just started talking with people and things seemed to go well. I enjoyed the networking before the event began. It was clear that everyone was feeling each other out a bit to figure out who they wanted to work with. A weekend is not a huge time commitment, but everyone wanted to have a good experience.

After a round of pitches, everyone cast votes for the different ideas. The top ten idea presenters were chosen as temporary team representatives, and everyone walked around and tried to form into teams. It was a bit chaotic. :)

There were a few ideas and people that seemed most interesting to me, so I walked around for a minute or two getting a sense of the room. I settled on a pitch that was billed as a last minute appointment filler. This could be something that slotted people in for busy service providers, or something that filled up empty slots for not so busy service-providers. It might have been something for service providers, or something more for end users. It seemed open-ended and valuable enough that we could explore some different solutions in the space throughout the course of the weekend. I was excited to work with the team of guys that were interested in the problem as well. It ended up that I was the only "developer" on the team. The rest of the guys billed themselves as "marketers". (LSM also had the distinction of "designer". These roles were pretty open and just served to try to get a range of skillsets at the conference.)

Read on →

Fixing Sporadically Failing Specs

When developing things with a large suite of unit tests or automated specifications, inevitably tests that actually pass fail for some reason. More difficult is the case where the test or spec fails only intermittently. I've taken the approach of late to keep a file around that records when I run into a problematic spec. When I get to five times that the spec failed, it's time to refactor it to be less troublesome.

The first thing I check is to look at the spec and the code it executes and ensure that I think nothing is actually broken. Next, I ensure that the spec is actually adding value. If it's slightly broken and is actually useless, we might as well get rid of it now and not spend more time on it. Generally though, the functionality of a sporadically failing test will be correct, and the spec will add some value.

Read on →

Run Local Scripts on Heroku

In order to run an arbitrary script on Heroku, you can use the Heroku console. They state that "you can use heroku console as a stand-in for Rails’s script runner", but one key component of the script runner is that you can run files. You can run files in your git repository that are deployed to the instance that you want to run them on by using the method advocated by Steve Wilhelm.

What if the file is not checked in or you need to make rapid modifications for prototyping? If you have a lot of code that you want to write and you want to be able to easily modify it, try the solution below. Manually typing in many multi-line statements at the console (and retyping when you make an inevitable mistake) is frustrating.

Read on →

How to Run A Successful Brown Bag System

Software Engineering Professionals has a brown bag system that has been going on for over a year now. This post will describe how this successful system works.

Overview

Brown bags (also known as 'lunch and learns') are a great way to spread knowledge among coworkers. They are a way for managers and employees to present on topics they are interested in. As the name suggests, brown bags are held during lunch. People bring their own lunches, and kill two birds with one stone by learning and eating at the same time. Presentations or fishbowls are generally the formats of choice.

I think the biggest benefits of a well-run brown bag system are:

Read on →