Tuesday, April 28, 2009

Correcting VIM indention, Python

First off, get your VIM editor up to speed.

http://henry.precheur.org/2008/4/18/Indenting_Python_with_VIM.html

Check that your filetype and settings are correct...


:filetype

filetype detection:ON plugin:ON indent:ON 1,0-1 Top


Now issue the magic VIM command to re-tab the entire file.


gg=G


Or here's an alternative that converts all tabs to spaces


:set tabstop=4
:set shiftwidth=4
:set expandtab
:retab

Monday, April 27, 2009

Revisiting Pyshards

So I had this idea last year after reading several white papers on database scaling techniques. I also had about a week's time between paid projects to spend however I liked. So I turned my ideas into pyshards, a quick and dirty horizontal database partitioning library. At the end of that week, I published my effort on Google Code for a number of reasons:


  1. I really couldn't find a Python-based toolkit like the one I was imagining at the time, and I needed it.

  2. I was looking for Python gigs and wanted to be able to easily refer hiring technologists to something I had written in Python. (Most of my previous work had been written in JAVA or C++, or could not be made public.)

  3. After years of using great free and open source, I was ready to give something back.

  4. I was curious if others would volunteer to help me build the library.



I received a number of messages from other coders saying they were looking a tool like the one I was building and would be interested in joining the project. But the messages were about as far as it went. Actual participation from the outside was nill.

I went on to use pyshards in my next project, but not quite in the capacity I had originally envisioned. I did use the tool to configure my shards and I used its distribution mechanism to evenly spread data across the many databases. I didn't end up use it for querying, as I needed something a little different. In the following months I went on to create a new page (in the Django sub-project) that visually communicated the shard organization and remaining capacity, but that was the only new work done.

Though the library was imperfect and incomplete, it certainly worked for my purposes. I gave it little thought over the next several months. My hands were full building a new system for the company I had started with my partners.

Jump ahead to PyCon 2009 in Chicago. I had a few hours to kill on the last day before catching my plane and decided to attend an OpenSpaces session called "Is my code Pythonic?" I had intended to simply listen in, but when no one offered up their code for review, I volunteered. A lot of my Python code is proprietary, so I decided to offer up a file from pyshards for review, since it was public. There was a LOT of feedback.

At this point you may be wondering, what do they mean by Pythonic? I generally understood it to mean that you should follow the Zen of Python coding principals and stick to the "pythonic" coding style.

In case you missed it, the Zen of Python is always near and dear if you are working in a Python interpreter.


me@mrroboto:~$ python
Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!



So that takes care of the Zen, but what is the Pythonic coding style? There are lots of opinions, but in general it is whatever the core developers and expert users say it is, and that evolves over time even as the fabric of the community evolves.

Jump to the present. This morning I'm finally sitting down to take a good look at the patch that Jack Diederich submitted as well as the notes I took while discussing the code with Moshe Zadka. And as I bring the project back up for testing, I remember that the setup and configuration steps were very incomplete. Okay Devin, quit blogging and get to work on it.

Friday, April 24, 2009

Startup Lessons #2 - It takes a customer

There are startups and then there are startups. We were never going to be a "web-based" company. We had decided to use web-centric technology to address specific enterprise problems, so ultimately we would be an enterprise software company. The problem we set out to solve was summed up by one angel like this, "Everybody knows and understands that data behind the firewall is a mess." We hoped to fix that.

My partners worked on a number of large telco projects that ultimately failed, and for a variety of reasons. We understand what the corporation is left with after the legion of offshore programmers and consultants leave. We've watched the systems go live only to then crush under the weight of massive data. We got it that no matter how good the user interfaces, reports and controls seemed to be, what gets delivered somehow doesn't quite provide the value imagined months or years before getting into the project. There is often disappointment.

We came up with a concept would make data easy to access and integrate and that would be massively scalable. We decided to jump. We were going to launch a startup.

But this isn't your internet startup. There are a whole different set of problems when launching a software company that intends to sell to Fortune 1000 companies. With a web based company, you build it, and when you are ready to go, you make the site public. You are deployed. Typically the web startup's next problem is that no one shows for the party. You've got a whole different set of problems.

But for enterprise software, you have to build it, test it and then deploy it. That takes time---time to not only build the software, but to decide on a target market, to build customer relationships, to persuade someone at the company to let you in the door. It takes time to see through the initial deployments, to make it work in the real word, to seal a deal or two.

All of this comes out as you work through the business plan; you realize that it is going to take big money, bigger than you originally imagined, to make it through to those first customers. It's going to take VC money. It seemed to us, at the time, to be the the only way forward.

But there is a chicken and egg problem: The VCs won't give you the time of day until you have those first customers. Don't kid yourself into believing anything else. Seriously. This is not the late nineties and no one is lining up to throw money at every clever software idea. I swear.

Our team has a combined 50 years of experience in the telco space. We have a salesman with a proven track record, a versatile product manager, a data integration specialist with a knack for people, and a software architect. We knew we could build it and had good long-standing relationships in our space. The combination of our ideas, our relationships, and our technology gave us confidence that we would be able to get our product deployed and eventually sold. The VCs and angels liked hearing this, but they asked, what about the customer?

We know about big problems at Verizon and ATT, we told them. Are you in talks with them? Well, not them specifically, but we have talked to a number of other interested parties. You see, that's why we need your money. We need it to see us through until the software is mature enough and while we work up the relationship hierarchy looking for the best champion within these companies.

That's when they tell us to come back once we're deployed at a customer site.

Using our combined efforts we were able to raise some initial money. It wasn't much compared to what it would take to keep our team working full-time for a year (I'll get to this in another post), but it was a start and it gave us hope. We were able to take advantage of a government program to secure matching seed funds. But additional funding did not come as quickly as hoped and our rope grew shorter and shorter.

I built the software while my partners worked every possible existing relationship. The feedback was always positive. Yes, they really liked our technology. Yes, they wanted to work with us. Yes. Yes. Yes. By February we had developed a small sales pipeline, but we were out of money. With no customer, there could be no investment. With no investment, where does this leave the company?

I have omitted the fact, thus far, that the economy tanked during this our first 10 months. I suspect that had it not, we would have secured funding from one or more of the angels we were courting. There is of course no way to really know that.

At this point my partners are looking for services work. They will eventually find themselves engaged on location with one of our company's target customers. At that time, they will look for problems that our software, or new software, can solve. It may be that they'll learn of new problems that require a completely different solution, but once they find it, they'll be in a great place to recommend a software solution. They will have a technology foundation---that they own---that can be adapted to solve a number or data classification, access, performance and integration problems. They will present their ideas and have a much easier time of getting it deployed than they would if they were coming in from the outside.

This solves a number of problems. They will be able to articulate clearly the specific problem to the next investors, which was a bit of a problem during the first go-round. (Clearly they won't be hired by a client unless there is a real problem to solve in the first place!) They will be getting paid for their services work, eliminating the need to use investment to pay their salaries. And most importantly, they will be engaged with a real-world CUSTOMER.

Hindsight really is 20/20. We probably should have gone this route on month one instead of month ten.

Wednesday, April 15, 2009

Startup Lessons #1 - The Valley of Death

If nothing else I've gained considerable insight into the startup process during these last 10 months of chasing the dream. The lessons are abundant.

You've heard it said that it's all about the journey, not the destination. Well, not when you are a startup. The destination is everything.

But there is much to be said about the journey as well. If you are an entrepreneur and thinking of going off on your own, you won't find a lot of war stories. I imagine that those who succeed guard their formula for success and those who don't prefer to pretend that nothing happened. The way I see it we've neither failed nor succeeded at this point, so why not reflect on a few of the lessons learned?

Personally,the journey has been both rewarding and costly. There were a lot of great experiences. I met fellow entrepreneurs. I learned about what it takes to look someone in the eye and ask them for money. I was able to practice the art of giving presentations to Fortune 1000 CTOs and VPs, and of course, I was able to build a substantial---though incomplete---enterprise software system using some of my favorite technologies. And there is so much more--- consensus building when working with partners, learning to recognize when you are self-deluding, finding the energy to take action on the days when it seems there is no hope.

I probably wouldn't be blogging about this today if everything with the business had gone as planned. Friends and former co-workers keep asking me, "Is the company dead?" Well, no. But it is true that we're not where we had hoped to be at this point, that's for sure.

We recently held a second meeting with an Oklahoma-based VC and he said it best,"You're in the valley of death," a chasm between the initial seed funding and a substantial VC round. It's a place where companies who have burned through their initial funding but have yet to make it to revenue reside. Word to the wise: A substantial revenue generating customer relationship is paramount; this must happen before any serious investment consideration will be given to you by a venture fund.

If you go back and read our business plan, at this moment in time we should have a development staff, a beta release, and we should be engaged with at least two paid pilots. But that didn't happen and for a lot of reasons. So what went wrong and is there any way to turn things around now? I'll reflect and blog on it over the next several weeks.

A List

So many things are going on right now. Where to begin? Here is a list of things that I either need or want to do in no particular order.

  • Blog about the startup experience
  • Find gainful employment
  • Find the time to contribute to Catherine Devlin's sqlpython project
  • Find the time to test the diff that Jack Diederich contributed to the pyshards project, and then refactor everything else
  • Take my tax filing to the post office
  • Evaluate plone, drupal, wordpress and...
  • Revamp my home page (a simple resume currently)
  • Figure out what I want to be when I grow up
  • Find the time to finish recording a new electronica song I started writing a few weeks ago
  • Keep working on my contract job---the only item in here that pays---but without getting so buried in it that I can do nothing else
  • Watch out for typos or misspellings on my blog!