Nov 19

Twelve Lessons Learned from a Startup Weekend

2014-11-16 20.41.59

This past weekend I participated in my first Startup Weekend Columbus.
During the course of which we built Fairflo, a marketplace for fair-trade items. The front end can use some work, but at the end of the weekend we had a fully functioning e-commerce site. I’ll write about the infrastructure separately, but as an aside Saturday night an attack from China was detected and defeated.

In no particular order, here are some lessons learned.

Lesson 1: Remember to take care of one’s self

Startup weekend is incredibly intense. There were approximately one hundred
extremely creative people all in a relatively small space — enough space in which to work, but close enough that creative juices were flowing amongst the groups. It’s very easy to find oneself living off the energy and forgetting to eat or otherwise feed the body. I’ve seen it elsewhere at festivals and conventions. In some senses it was more intense this time — perhaps due, in part to the close proximity; at conventions there are usually panels or other events which help to disrupt at least some of the flow. The organizers were really good about making sure that there was food available; as the weekend progressed more and more energy bars were placed out for the participants.

Sleep and/or other forms of downtime are needed as well.

Lesson 2: Practice the Pitch. Practice, practice, practice!

Given the limited amount of time to present the pitch, timing is very important, particularly if more than one person is presenting. Setting aside a couple of hours to practice and refine the pitch is very useful, especially for polishing and showmanship. Getting up in front of a crowd and talking is far easier than having a concise and succinct message. Providing a block of time is essential for being able to revise, refine, and review. Additionally the pitch should be given, if possible, to someone not on your team — perhaps a “trade” where teams can practice in front of each other.

Lesson 3: Mental Stealth Checks

Given the timeframe and pressure, it’s important for groups to periodically touch base with each other. In some senses it’s like a standup for an Agile team, but given rather more frequently. In addition to what people are working on and blockers, checking the mental/emotional state is very important. I think that a 10-15 minute standup including touching base/emotional check-in of, say, four times a day is probably about right:

  1. First thing in the morning
  2. Lunch time
  3. Dinner
  4. End of the day

It might be helpful if people are getting frustrated/frazzled to have them more often — even just a quick stretch and “Do you need anything” every couple of hours. Any more than that and flow is likely to be disrupted.

The organizers had daily meetups for all of us to touch base and talk about progress and/or needs. I’ll admit I felt a touch of resentment toward the meetups of all the teams — it was eating up time which I felt could have been better used for working with my team. I understand why they had the meetings; it is far too easy to fall down the rabbit hole and sometimes a break and/or change of pace is needed. In the moment, I felt as though it was disruptive of the gestalt which we were building.

Another reason for having these team meetings is to help maintain focus and keep on task — it is far too easy for Creatives to suffer from “Oooh, shiny!” and get distracted or to zoom from one thing to another when under pressure.

Lesson 4: Do high level planning Friday night

A quick high-level plan and/or breakdown of tasks and/or priorities are very helpful. Some things, are needed no matter what the problem domain:

  1. Overview of the problem space
  2. Feasibility and/or Customer studies
  3. Basic IT considerations (domain, email, etc.)

As such the sooner they can be worked on — or have an idea who is working upon them the better. Process can be important — not to be burdened by process, but it can provide a framework or track so that everyone is headed in the right direction.

Lesson 5: Build out the infrastructure Friday night

Leave as much time as possible for front-end details. Given the short time to pitch, having a “wow” helps translate to a “win”.

Lesson 6: It can be helpful to have a place to work together offsite

Since the venue closes each night, it can be helpful, but also a potential snare, to have a place in which to continue working. The snare lies in staying up too late!

Lesson 7: Have an afterparty/post mortem/closure

Startup weekend is zoom-zoom-zoom high energy build gestalt then stop. The let-down afterward can be really hard. Having space and time afterward provides closure which is really, really important. It doesn’t mean that the project is over, but it’s a time to come together and release some of the energy which has been building all weekend long.

The release can be seen in a lot of rituals, whether a benediction or releasing the quarters. Congregants come together for a purpose, fulfill the purpose and then have a closure. It’s something I think is needed.

Lesson 8: Thank the Organizers, Mentors, and Judges

Important but easy to forget. They have put a tremendous amount of effort into creating a space in which creative magic can happen.

Lesson 9: Think like a Boy Scout

Be Prepared — Boy Scout Motto

At any conference or event such as Startup Weekend there will always be a need for extra outlets, connectors, etc. Simply having a small power strip is a great way to make friends and meet new people. Bring one; you’ll be glad you did.

On the more expensive end of things, a micro-projector or access to a large monitor is useful to have people looking at the same thing without needing to huddle around a laptop. Also, it’s good for practicing presentations.

Lesson 10: Be Excellent to Each Other

A lot of what I’ve learned this last weekend has to do with people and small group dynamics. I was fortunate to be a part of a great group of people.

I discovered, too, that over the years I’ve picked up a lot more than I realized about groups, process, and business. I don’t know much about marketing or making a business plan, but I realize that I have learned a lot about people and how they work. I find that I have a better handle on project management than I might have thought, too.

In the course of Startup Weekend, there will likely be some conflict. A certain level of conflict can be good — if nothing else a better product can emerge through synthesis and refinement. However, it’s still imperative to be committed to each other and to the team.

Many cultures have a version of “Do unto others as you would have them do unto you” — in some ways I think that one of the most profound ways of expressing it is espoused by the most excellent Bill & Ted. On the surface they might appear foolish, but:

The Fool is the spirit in search of experience. He represents the mystical cleverness bereft of reason within us, the childlike ability to tune into the inner workings of the world. The sun shining behind him represents the divine nature of the Fool’s wisdom and exuberance, holy madness or ‘crazy wisdom’. On his back are all the possessions he might need. In his hand there is a flower, showing his appreciation of beauty. He is frequently accompanied by a dog, sometimes seen as his animal desires, sometimes as the call of the “real world”, nipping at his heels and distracting him. He is seemingly oblivious that he is walking toward a precipice, apparently about to step off. — The Fool

Lesson 11: Be Pragmatic

The perfect is the enemy of the good. — Voltaire

It is important during Startup Weekend to dream high. However, there are only 54 hours. There is only so much that a group of humans can achieve in that time. So it’s important to both strive for the best yet accept limitations.

Lesson 12: Have fun

It’s a lot of work. A lot of stress. But in order to be successful, it needs also be a lot of fun. If it’s not fun, you’re doing it wrong.

Thank you to everyone who made Startup Weekend possible. I’d like to thank the sponsors, organizers, mentors, judges, and other teams. But most of all I’d like to thank my teammates. You are all excellent!

Nov 14

Free Cloud Resources

This is a quick list of “free” cloud resources.

Oct 29

First do no harm

If you can, help others; if you cannot do that, at least do not harm them. — Dalai Lama

Over the past couple of years I’ve been trying to put into words my thoughts regarding the type of company where I’d like to work. There are companies I would not consider working for — their ethics and/or business model are radically different from what I consider good or right.

“Evil begins when you begin to treat people as things.” — Terry Pratchett, I Shall Wear Midnight (Discworld, #38)

  • I don’t want to work for a company which takes advantage of others.
  • I don’t want to work for predatory companies or ones which don’t treat their employees well.
  • I don’t want to go home at the end of the day feeling slimy or otherwise compromised.
  • I don’t want to work for a company which treats people as things.

I think technology really increased human ability. But technology cannot produce compassion. — Dalai Lama

I’ve had the fortune to work at a not-for-profit for the last nine years. Not being profit-driven means we’re not out to gouge people. Not that there’s anything wrong with seeking a profit, but seeking profit for the sake of profit leads to evil.

At the same time, without the relentless drive for profits it’s easier to focus on customers and service.

  • I don’t want to be associated with a company that views profits more valuable than people.

Don’t be evil. We believe strongly that in the long term, we will be better served — as shareholders and in all other ways — by a company that does good things for the world even if we forgo some short term gains. This is an important aspect of our culture and is broadly shared within the company. — Larry Page, Sergey Brin, Google IPO

A lot of people have scoffed at Google’s ideals in recent years. Nevertheless, it’s an admirable goal. I wish that more people or companies chose not to be evil in their day to day interactions with others.

The Agile Manifesto has brought a lot of change to Software Development. Other fields have recognized its inherent value and rewritten it to fit their circumstances.

I’d like to present a first draft of a manifesto for business.

A Business Manifesto

We are uncovering better ways of running a business and helping others do it.

Through this work we have come to value:

  • People and interactions over profits and prestige
  • Quality service over quantity of service
  • Customer relationships over contract negotiation
  • Flexibility over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

In a nutshell I want to work for a company which values people — both inside and out of the company. I want to work where people strive to do things right.

Trust yourself. Create the kind of self that you will be happy to live with all your life. Make the most of yourself by fanning the tiny, inner sparks of possibility into flames of achievement. — Golda Meire

At the end of the day, I want to work for a company which isn’t evil. When I go home, I want to be able to look in the face of my daughter and not have to make excuses for the work that I do and the effect it has on others. And I want to be able to look myself in the mirror, too.

Be excellent to each other and Party On Dudes — Abraham Lincoln in Bill and Ted’s Excellent Adventure

Sep 28

Go executables are statically linked, except when they are not.

Generally GO executables are advertised as statically linked.

And they are, mostly, except for those times where they aren’t.

This is about one of those times, and what I discovered in the process.

Read the rest of this entry »

Sep 16

Docker Volumes Quirk

I discovered something interesting today regarding Docker and volumes — there’s a problem below with the call to run the private docker registry container:

docker run -d -v /opt/registry-cache/:/tmp/registry -p 5000:5000 registry

If you run that and curl -s http://localhost:5000, nothing is returned.

As it turns out, the trailing slash in /opt/registry-cache/ causes issues — the web proxy starts up, but the actual registry doesn’t run. In order to get it to work, the following needs to be done:

docker run -d -v /opt/registry-cache:/tmp/registry -p 5000:5000 registry

It’s amazing the difference a single character can make. Remove the extra '/' and it works as expected.

Jul 27

Using Openstack/Devstack Floating IPs from outside

I hope that this is of use to someone. After many hours of tearing down, building up, programming routers, etc., I’ve figured out why my devstack wasn’t allowing access from floating ips. I knew that the address was resolving (arp -a); I just couldn’t ssh to it (or do anything else with it)

It was the security rules.

So, I went in to the security rules in horizon and added the following rules to the default:

  1. Allow all CIDR ICMP traffic
  2. Allow all CIDR TCP traffic
  3. Allow all CIDR UDP traffic

Generally I wouldn’t advise opening it up totally — I’d open up applicable ports.  However, I’m happy to have it working!

Aug 01

Cloudy Update

I’ve been working with Docker a good bit and have updated my list of tools.  Here’s a quick dump of where I am in the design of the infrastructure.

  • collectd will be used to monitor cgroup statistics.  This necessitates compiling all or part of collectd — the current packages do not contain the cgroup plugin. This will run in the hosts which run the containers.  Additionally, information about the hosts will be collected.  Thresholds will be used to send alerts, scale up or down services, etc..  Graphite or some other tool will provide graphs for the dashboards.
  • A log aggregation tool will capture logs from the various containers.  I’m considering logstash due to the large number of inputs which are already defined.  OpenTSDB is another option — it looks like it may be more poweful in some senses, but more difficult to configure in others.  My main concern with both is that they’re java based and in the case of logstash it requires a java collector running in each container and even though it’s a default sized jvm, assume it will require ~128 mb for each container.  That adds up quickly and I’d rather have something lighter.  I’ve not done enough research on OpenTSDB to speak to what it uses.
  • Dynamic DNS will be used to register the various services.  At present I am leaning toward Power DNS using PyPdnsRedis as a pipe backend  and redis to store the dynamic data.
  • Nginx will sit in front of hipache which is a dynamic proxy/load balancer which uses redis. I have not decided whether to use the node flavour of hipache or the one embedded in nginx — that needs to be tested. Calls to the services will be routed through the proxy.
  • An image repository will be available for local hosting of images.
  • A web-based front end to configure hosts, services, and provide a dashboard view.  Given the many other pieces which are using redis, I am seriously contemplating using it to store the data used to define services and hosts.  I’m not 100% sure of this yet, however.
  • Services consist of a particular process, such as a restful service running in a web server, or a jvm, or …. In their definition, the following information will be stored:
    • The name of the service
    • Ports which need to be exposed
    • Whether the service is active
    • The image
    • Dependencies – particularly services which need to be running prior to the start of this service
    • The minimum and maximum number of instances of the service
    • Threshholds
    • System requirements (cpu, memory)
    • Heartbeat – this is in addition to the thresholds
    • There may be a sort of inheritance to help cut down on duplicate information.
  • Hosts run the docker daemon and host containers.  Their information consists of:
    • Name of the host
    • IP address (may be dynamic)
    • Is the host available
    • Does the host need to be started (is it out in the public cloud)
    • Any cloud information needed to start it.
    • Priority – this determines the order in which containers and services are started – I anticipate that private hosts will have priority over public cloud hosts — due to expense; it makes sense to have overflow go to the public cloud.
    • Server specs
    • Currently available resources — this can be grabbed, in part from collectd.
  • There may be a discovery process, akin to the old Sun Jini project whereby a service can advertise itself and other services can utilize that service.  I could see this being used, for instance, if a service needs a cache.  Databases likely would not be as useful.

A picture will follow soon.  However, a good bit of the work’s already been done — where possible I’m integrating existing tools and projects.  Obviously the front end will need to be written.

I’ve decided that I’m going to repurpose my nimblestratus project on github — it’s not like I’d really done much of anything with it.  Unfortunately someone registered two weeks ago, but .org is still available.

I’m pretty excited, though — the pieces/parts are coming together in my head and I believe that this is do-able in fairly short order.  I really, really want to have a simple proof of concept done in the next couple of weeks, or by the end of August — I’m going to Cloud Develop and would love to have something for a “show-and-tell”.

Jul 23

On demand containers

I’ve been interested in Linux Containers for quite a while; I think that they have their sweet spot where they are better than virtual instances — in particular they require less resources.

I am working on a framework to use linux containers for on-demand computing — increasing or decreasing instances of applications as needed.  I envision it being used for things such as:

  • JBoss or other application servers
  • Internet Applications
    • Web
    • Rails
    • node.js
  • Databases
  • Caches
  • And more

At this point I’m planning to use the following:

  • Docker
  • HAProxy
  • TBD Monitor
  • TBD Management (probably written by my self)

At this point, I think the key is in being able to dynamically assign units to HAProxy.  HAProxy: Reloading Your Config with Minimal Service Impact describes a method for activating changes to HAProxy.  Unfortunately there isn’t a good API provided by HAProxy to add/remove hosts as necessary.  I’m wanting to be able to support both public and private clouds, with the idea being to have the ability to add resources from public clouds when private cloud resources are depleted.

Why am I doing it?  For one, well, it’s interesting to me. For another I haven’t heard of any open source tools/frameworks which do this.  Additionally I’ve seen many instances where virtual instances have been over provisioned or sit idle wasting resources, particularly when jvm’s are running inside a virtual instance.

There’s still a number of unknowns, but I think it’s workable.

Jun 22

cygwin and torquebox and rvm, oh my!

rvm, despite being wonderful, doesn’t play very well with torquebox under cygwin. In particular, the gem paths are not working. So, in order to fix this, simply do:

rvm use system

And then it will work right. Once you’re done with the torquebox work, you can go back to using rvm.

Nov 04

JBoss Client Jars for Messaging

Prior to JBoss 5, the jboss-all-client.jar was pretty much all you needed. However, the JBoss 5 Getting Started Guide states the following:

The client/jbossall-client.jar library that used to bundle the majority of jboss client libraries, is now referencing them instead through the Class-Path manifest entry. This allows swapping included libraries (e.g. jboss-javaee.jar) without having to re-package jbossall-client.jar. On the other hand, it requires that you have jbossall-client.jar together with the other client/*.jar libraries, so they can be found.

In order to access JBoss Messaging from a remote client, you need the following jars in the client’s CLASSPATH:

  • $JBOSS_HOME/client/jnp-client.jar
  • $JBOSS_HOME/client/jboss-javaee.jar
  • $JBOSS_HOME/client/jboss-messaging.jar
  • $JBOSS_HOME/client/jboss-remoting.jar
  • $JBOSS_HOME/client/jboss-serialization.jar
  • $JBOSS_HOME/client/javassist.jar
  • $JBOSS_HOME/client/jboss-aop-client.jar
  • $JBOSS_HOME/client/trove.jar
  • $JBOSS_HOME/client/log4j.jar
  • $JBOSS_HOME/client/jboss-logging-spi.jar
  • $JBOSS_HOME/client/jboss-logging-log4j.jar
  • $JBOSS_HOME/client/jboss-common-core.jar
  • $JBOSS_HOME/client/jboss-mdr.jar
  • $JBOSS_HOME/client/concurrent.jar

Older posts «