Bad Ass Web Applications with Forgettable Names

I recently had a string of good luck finding web apps that are well designed and make my job easier (ironically most of them are built on flash). Unfortunately, I can't ever remember their names because they make no sense and I don't use them every day. I was thinking about making a web app to remember them for me, but couldn't find a name that I would remember for that either. And now the purpose of this post is clear.

I'm very picky and probably try hundreds of new apps a year. I've wasted 10s of hours combing through crap, blah, and broken to get down to these tools. Despite the completely forgettable names, these are the few that don't piss me off:

• Cacoo: Wireframes. The interface reminds me of Gliffy but a little more stylized, hip. If Gliffy is Bill Gates then Cacoo is Steve Jobs.
• Color Schemer: Ready to go color schemes. It's better than agonizing for hours over color palates.
• Gliffy: Online version of visio. I assume this is named after some famous rapper or something. Bling bling bitches.
• Prezi: While it's interesting for presentations, I use it for doing architecture diagrams that are deeply nested. I would not object to gliffy and prezi hooking up and birthing a love child. 

And that's it. Hopefully google indexes this and takes me to this page the next time I search for "that thing that makes diagrams on the web and is flashy". Index it!

Reality TV: So You Think You Can Startup

There is a lot of hype surrounding the startup culture, especially if you are young and fresh out of college. People blog a lot about making your own startup, but rarely about what to consider when joining someone else's startup. This is very different than joining an established company because it's much more likely to fail than succeed. The reality of startups is not the buyout or bust that blogs like TechCrunch make it seem: it is a painful roller coaster of hard decisions, long nights, and a lot of waiting. Oh, the waiting! 

Well, the waiting has come to an end. Today is the last day of operations at Janus Health. It's a huge bummer to say the least. Following a roller coaster of financing issues, the money well is finally dry. Hopefully this eulogy sheds some light on how things really end in startups, and things to think about before accepting a position at that startup that "have the perfect position for a person with your skills".

Backstory

Like many developers, I was working a normal job and doing some consulting work on the side. The company was trying to do a proof of concept of online-offline patient management and I was working the technical implementation. After a couple months, I signed up full time as a lead developer, platform specialist, database admin, etc...  

The next 3 years were insane. I was constantly stressed out, babysitting the system, learning new tech under pressure, and of course reveling in the victory of conquering problems. As the only developer for 2 of those years, I did way more boring code monkey work than I ever imagined. It completely surprised me that startups are the actually the last place to try out new ideas - it's push or perish! 

The product had become my ill behaved child, my obsession, and a continuous source of drama.  I thought about leaving constantly, but who would watch after it if I left? Just like a child, after about 3 years things started to get easy. I had help now. The system was stable and fast, the customers were happy, and we were ready to announce 2.0. Money was coming in, but apparently not enough. 

This was really the second death. A few months ago we were almost dead when a last minute term sheet with a big wig investor gave us enough credibility for a 2 month bridge loan. The deal included a clause saying we wouldn't look for any other investors while the lawyers battled over stock options. 2 months later and 1 month of server costs left in the bank, and the investing company is being acquired. Deal off. No backup funding. Employees cut loose. Customers notified.

The Real Losers

The people who are the worst off in this situation are the customers themselves. A painful contract termination letter went out two days ago stating that they have 1.5 more weeks to use our services. Switching EMR (Electronic Medical Record) vendors is usually a 3 month task. My heart goes out to them since their workflow will be severely hampered. This is the risk of going with a startup to fulfill a critical business operation - I'm grateful they took the risk and sorry that it will probably scar them for the rest of their IT purchasing life times.

On the more positive note, the customers were always happy with the product and seem to be working together to create a grassroots/cooperative maintenance solution of the product. Luckily one of the customers was also a big investor and is willing to leave the source code in it's current installation. I hope they follow through and make the dollars work for them.

Lessons

It is better for the product to go grass roots anyways. I had an epiphany a few months back about why we were struggling in the first place. The company strategy was to be bought out, and that requires a lot of initial capital and an "enterprisey" take on the healthcare market. However, our customer was not enterprisey at all; they are [mostly] grass roots physicians who truly believe that it's better for the health of people to be taken care of at home*. They choose to take severe cuts in pay and deal with billing hell because they believe in the cause. In that sense, it's important to align with your customers market: a home brew market needs home brew solutions to grow with them, and we didn't want to be small. 

I didn't think we would always be enterprisey. When I joined the team, I assumed things would change with time (with my influence of course), and we would become more transparent and "open sourcey". I now know this rarely happens, and if I had took the time to sit down and actually read the financial part of the business plan (which EVERY startup should have) I would have known that. 

After things started going bad, an old friend once told me "some CEO's like to climb mountains, while others like to fly". Most people actually join other peoples startups, and if you are presented with an opportunity you better figure out what kind of passenger you are and what kind of CEO is leading the way. This way, you know how they have the potential to make your life miserable. If that company is climbing mountains, things are slower, the cash pot at the end is less likely and/or a long way away, but you'll be fully aware when things go bad. Flying means you crash into the side of a mountain with no survivors. 

Reflecting upon the accident it's interesting to reveal what actually caused crashed. I don't think it had anything to do with the product, although I had moments where the choice to not use a stock LAMP or Java solution may have prevented lucrative partnerships.The business model was innovative, perhaps risky. I gasped the first time I learned our burn rate. We were flying in style. A lot of money was spent on licensing that could have been shaved. We needed more employees to grow, but maybe we should have been letting them go. 

I never took the time to learn things like bridge loan, diluted stock, term sheets, etc... and I sincerely regret it. If you are thinking of joining a startup, take a crash course at your local SBA or sit in on a local college class to learn, especially if you will enter into a decision making role. Heck, even if you aren't going to a startup I recommend it: business accounting is fascinating. In retrospect, there are several key decisions I made that I now wonder if I would have decided otherwise if I had understood the finances better. Contrary to my previous beliefs, its actually accountants that are our overlords, not octopuses. 

This idea in startups that if you build a great product, eventually you will have great customers and money will just start flowing is absolute horse poo. That meme should die alongside princes saving princesses on white horses. I'm convinced that companies touting this secretly have amazing money wranglers in the background, and should be legally obliged to footnote these claims with "for motivational purposes only". 

Adieu

I couldn't be more grateful for the experience and wish the best to all the people who worked side by side through some truly awful and amazing times, to the clients who tolerated our mistakes as we learned how to steer, and to the investors who believed in the product to begin with. Best of luck to all.

* After tagging along for one house call I truly believe this as well. It's amazing what they find in the home with respect to medication compliance alone. If you have an elderly family member I recommend calling your local house call doctor to see if their insurance covers house calls. 

Update Mania!

It's been a while I know, but I have good reasons I swear! A lot has happened in 2 months and I'll try to be brief. Skip around to specific sections if you like, I won't be sad.

This Blog
I just updated the look and feel of this blog to be up to snuff with the new blogger templates and designs. I rather like the new interface, although I could choke myself on the abundance of fixed width designs out there. Glad to see Plone still hasn't jumped the shark on liquid design. Oh wait...

I also went and updated code snippets from old posts with gists. I'm really happy with the support and although it's no posterous built-in it's easy enough.

Lately I've been blogging a lot more which means I've become pretty passionate about divvying up my blogging so content streams are consistent. I would hate for people to have to fiddle through stuff they aren't interested in. As a result, all of my Plone blogging is now on the PloneChix blog. If that's all you care about then head over there! It's also syndicated to PlanetPlone for your simplified user experience. I also started an unofficial idea blog to help me focus some of the cockameme ideas I've had since I "went solo". It's probably not appropriate for anyone really. This blog will remain my official point of contact for non-Plone tech posts, especially high level ideas, with the occasional personal update.

San Francisco/Work
The move to San Francisco was great and I'm super excited to be here. In short I'm extremely happy with the decision and life is already unfolding some very promising ventures.

In an surprising turn of events my company received a huge some of investment capital. It's not official yet so I can't explode the details but it's a crazy story nonetheless. This means I won't be spilling beans anytime soon about my departure and despite the funding effort, I have already migrated to a contractor role with the company.  The primary focus here will be a Plone 4 migration. After that I'm hoping to hand off the project to those who are happy to work in large system services interfacing - something I loathe entirely. The project has really grown up in the last 3 years, interfaces are solidified and features are stable, so I'm happy to pass the reigns to those that can take it the next level.

I will be dedicating 50% of my time to that effort at least until the end of the summer. The rest of my time is currently dedicated to exploring other opportunities, mostly in technology, and exploiting a new "tech bohemian" lifestyle. More on that in a later post.

Accident Report
Those that know me well will not be surprised by this at all. 1 week ago I was in a bike crash and am stuck inside for the next 5-6 weeks with 5 fractured ribs and a pneumothorax. I clipped a post on a multi-use trail which included me somehow crushing my ribs on my handlebar. I've probably fallen on my road bike 20 times and mountain bike plenty more but this just happened to be the unlucky one. Of course I clipped the post because I was not paying attention. I was not paying attention because 1) I was geek+climb talking with @sudarkoff and 2) I was feeling overly comfortable because I was on a "protected path". I usually ride in the road because Bernat claims that bike paths "are just asking for trouble". We used to argue about it but he definitely won this one. Just goes to show that comfort/apathy, no matter what sport you practice, is more dangerous than any most extreme situations.

And now it's time for consequences. I already did 1 triathlon this year and luckily had put off signing up for 3 more do to being lazy. I am going to bypass the rest of the season to focus on recovering and rebuilding. Although I was running and swimming my fastest ever before the crash, set backs like this are always a great time to rebuild with better technique.

Climbing will be halted a little longer, since climbing from my left upper body is especially precarious.  My trip to Pinnacles has definitely been cancelled and while I most likely won't make the Colorado Tweetup I'm shooting to be back in full force for the 2nd Annual Joshua Tree Tweetup. On a happier note, this injury will force me to do what every climber tries which is focus on feat, feat, feat!

On CT Scans
A quick little aside for anyone interested in a medical tidbit. When I was in the hospital I had a few x-rays and an abdominal CT scan. When the scan was done the radiologist said my kidney had spots - noise from a bad machine reading. My attending doctor said it may be blood clots and dosed me with a blood thinner (heparin) for a few days. A specialist finally looked at it and said "we'll just do another one later". When I was about to be discharged, the attending physician said that he didn't think the spots were "worth the risk" and discharged me without a followup CT.

Of course the specialist called me later that same day and wanted me to still come back for the scan. I had some insurance stuff to work out but then had a thought, what did he mean "worth the risk"? So I did a little research first. Turns out that an abdominal CT scan has the radiation equivalent of 400 x-rays, and the leftover radiation will stay in the system for about 2.7 years. Yikes!

Would I have turned down the first scan? No way. I absolutely needed it. However, I will be taking the risk and turning down the follow-up. I had no symptoms whatsoever of kidney problems and have already racked up 3 abdominal CTs in my life from a previous injury.

I am sharing because I was never informed of these risks, and had I not been discharged would have blindly gone in for the second CT scan. So if you took the time to read this blip and you or a loved one comes across a non-urgent decision to do a CT scan, especially abdominal,  please research the risks involved. When in doubt, get a second opinion!

That is all! See you at the next life changing event.

Coming May 2010 to a Bar Near You: There Will Be Beer

After 3 years of building from the ground up, our company is out of money. There is a small chance that the funds will show up last minute, but after working for almost 3 weeks without pay, I'm not placing any bets on success.

I'm currently not at liberty to explain how it all went down, but I promise to go into detail next month after things have solidified. It was unlike anything I have ever experienced. No one really blogs about what its like when a company fails - the disintegration of morale, the death of the product, and the denial that leads up to the final stake. There are also of course obligatory lessons learned, technical at times but mostly personal, that I hope to detail over the next couple of months in short posts. Hopefully they will be useful for a young gun thinking to get into the startup world, especially someone else's startup.

In the meanwhile, I've decided to finally move to San Francisco and end a commuting relationship of 2 years. I'm very excited to plug the holes in my personal life that my job has kept me from fully exploring. I am also excited to get be in a city exploding with technical prowess and excitement.

For now, I'm getting my crap together and in a month or so will start to act on what's next.  I'm hoping to spend an additional month or two working on some projects I've always wanted to complete (thanks to @yood for the inspiration!). After that I'll probably move into a consulting position or the right full time position should it fall in my lap. More on that later as well once I defrag from all the excitement of the past month.

That being said, my first mission when I get to the bay area is to rally the Plone community that appears to be sleeping soundly there. Be prepared for meetups, sprints, shenanigans and various references to pants. This is your warning ploners... there will be beer.

Knot Pop Quiz

THE QUESTION
what knot is this? any idea?

THE ANSWER
Bowline.  In this form it's sometimes called a 'double bowline'.

In the old days this knot was used to tie the rope around your waist- no harness.  If the leader fell, and the rope didn't   break, the result was not pretty- broken ribs were common.   When  harnesses first came around the bowline, and later the  double  bowline, was the standard tie in knot. Some people still  use it  to tie in, it's supposed to be easier to untie after  being loaded  than a figure eight, but it has sharper bends in  it which means  it's a slight bit weaker than the figure eight.   Any bend in a  rope lowers its breaking strength, and the sharper the bend the  more the rope is weakened. The figure  eight has the least sharp  bends of any known knot, making it  the 'strongest'.  It is also  easy to tie and easy to  glance at  it and verify it is tied  correctly- which are the main reasons  it is preferred by most climbers today.

Note: This post was ghost written by me for "could have been my first guest blogger but refused" Neal Harder in response to http://twitter.com/sudarkoff/status/5836400206. aka I just copied his email response into this form since he's "allergic" to blogging. 

Twisted Reactor w/XML-RPC, POST, GET

Rewriting our Berkeley XMLDB services on Twisted, I decided to implement some couch db type interfaces like responding to post and get requests for DB actions. Oh, and don't forget the already in use xmlrpc interfaces to stay backwards compatible! It was surprisingly simple after staring at the docs for a day or two, so I'm posting a piece of the code in hopes that the example makes it easier for people new to twisted. Below you'll find an example which not only covers the post/get/xmlrpc thing, but also has threadpools, deferreds, xmlrpc kwargs, and a reactor example. There are some pieces missing since the server is actually much more complicated but hopefully you get the idea. Bon appetite!

Plone LDAP and 450% speed increase rendering page load time

"Where I be workin' now we's goin through trubles, perfomance troubles solved by ma jigga... me?"...

ok - so I can't rap. big deal, neither can you. point is that we have been investigating the curmudgeouness in our plone 2.5.3 custom archetypes based product and came across this gem of a performance fart. our setup is weird I confess and I would be suprised if this actually applies to anyone but nontheless, thar she is.

we have many different users base dns in active directory that share the same group dns (scalability reasons) that map to zope roles. so we make plenty o' calls to see groups members to list them. turns out that this setup had something weird: our manager dn had permission to list other portals dns members but not to retrieve them. so if our user dn from one portal instance was "OU=AWESOME,DC=WE_ARE" and another was "OU=OK,DC=WE_ARE", they could share a groups DN of "OU=EDITORS_GROUP,DC=WE_ARE". The query to ldap for members of editors group would then return all user it can list, not edit, from both portals since they share this gruoping. Seems harmless enough right?

WRONG

(that could not be dramatic enough).

so for each user that comes back from the groups listing, there is a call to get that user. if that user call fails (i.e. the permission fails) the user is just ommitted from the list. so if those two portals each have 50 users in them, then there are 100 calls to get users from either portal, even though only 50% are accurate. oh, and each call is 1/10th of a second each.