I don’t mind iterating

July 29, 2014 in Soapbox | Tags: ,

One of the things I like best about running a start-up business is that I am often given the opportunity to iterate. By that, I mean I often screw something up so badly that I am forced to change how I do it in order to get the result I was looking for.

I don’t mind it. I don’t mind making changes. I’ll change if I need to in order to win.

But, what I find and endlessly frustrating is failing and not understanding what I did wrong. How can I improve if I don’t understand what I did wrong?

Can You Deal With That Much Frustration?

May 5, 2014 in Learning, Soapbox |

I have an experience that always surprises me is when someone sits down with me to watch me write some code. Most of the time the person will turn to me after a few minutes and say something to the effect of,

I can’t believe that you sit here all day just Googling how to do things on the Internet. I thought you were actually like really smart or something. You do everything wrong four or five times before you get it right.

And just like that the magic is gone…

I had this experience again just the other day after spending some time with someone who wanted to learn how to program. We wrote a few simple programs together and during the course of our time, I Googled “how to do something” every few minutes. I watched for the “ah-ha” moment when they would realize how easy it is. After about twenty minutes I saw the expression I was watching for. What my previously eager guest said surprised me at first,

Maybe I’m just not a computer person…

Huh? I didn’t understand so I said,

But I just showed you how easy it is to figure out how to do anything!

And they responded,

I don’t think I can deal with that much frustration.

Then I realized that it wasn’t the process of writing the code that kept this person from being a developer. It was the experience of the code not working 100 or 1000 times before you got it right. Each of those “failures” can be an extremely painful experience for some folks. My guest then said,

In my mind you sit at your computer and just write out this program. That’s where you spend most of your time, typing the actual code. Then you spend 5 or 10 minutes fixing any bugs. But, in reality, you spend 1% of the time writing the program and 99% of the time fixing the bugs. I could never deal with that much failure.

It made me sad, but I think this is not a particularly uncommon scenario.

Has anyone else had this experience?

Boring is Best

April 17, 2014 in Soapbox |

I really like this blog post by Matt Jaynes about building solid business on proven technologies:


I struggle with this myself, the desire to use the latest and greatest tech in our systems at MaaSive.net, but fortunately I have some really smart people around that help me realize when that’s not the best idea for the business.

It Requires Super Human Discipline to Write Readable Code in Callbacks

February 1, 2014 in Computer Science, Development, Open Source, Soapbox | Tags: , ,

Callbacks can be messy, as Guido Van Rossum said in his recent asyncio talk (@ 56:27 in the YouTube video):

“It requires super human discipline to write readable code in callbacks and if you don’t believe me look at any piece of JavaScript code.” ~ Guido Van Rossum

Fortunately you don’t have to write callbacks if you don’t want to. You need only look to Tornado and Motor

tornado and motor

Python has some neat features that let allow generators to be used as coroutines. The Tornado Web Framework includes decorators to make this dead simple. For me, the biggest drawback to using Tornado was the lack of a good asynchronous db driver. Using a blocking db driver sort of defeats the purpose of a non-blocking web server. Fortunately for those of us who don’t love writing callbacks, now there is a good solution.

Motor is a first class asynchronous MongoDB driver written by Jesse Jiryu Davis from MongoDB that will soon take advantage of Futures to present an easy to use, but still asynchronous, interface with MongoDB.

Jesse announced some changes that make using Motor even easier by incorporating Futures into the syntax, just like recent versions of Tornado. We are waiting on MongoDB v2.6 RC, which roadmap indicates will be released on 2/11/14 and the associated version of PyMongo.

In anticipation of this release, I thought it would be fun to look at just how far asynchronous db drivers for Tornado have come. Despite Jesse’s warnings that we should wait until the changes are official, we’ve been using these techniques at MaaSive.net to supercharge developer productivity and increase clarity in our asynchronous code.

In the Beginning

When I started using Motor v0.1 about a year ago this is what trivial DB access looked like for a simple handler that returns some JSON:

If I only ever had to make one db call, and only had to write one callback handler this would not be so bad. The problem is that in reality I need to make several db calls, and may need to wait until two or more are complete to do anything useful. The callbacks get out of hand quickly.

The worst problem is that debugging becomes a nightmare of epic proportions. The entire reason we use Tornado is to enable long-polling with lots of connections at the same time, and it becomes very hard to tell exactly where the problems are when lots of connections are active at the same time. Most developers (myself included) rely on stack-traces to debug our programs, but with callbacks like this you can kiss that nice stack-trace goodbye.

The Present

Motor v0.1.2 has come a long way since that time. Today a trivial DB access looks like this:

Technically you could also write it like this using motor.Op:

This is much, much better than before. Tornado’s tornado.gen module does a great job putting together a “stack-trace” when an exception is thrown and while this is certainly acceptable and useable, it still feels a little clunky. Why do we have to write motor.Op for example?

The motor.Op class exists because motor has a forward looking maintainer who was planning for the Future.

The Future(s)

disclaimer – this api is not released for Motor yet. It will come out with Motor v0.2 along with MongoDB 2.6 RC0 and PyMongo 2.7.

With Futures, we get to write the same thing like this:

The cursor.to_list method returns a Future directly and yielding the Future blocks this coroutine, returning control to the event loop, until the result is ready. It does not get any easier than that.

Developer Cycles are Precious

For many projects the most expensive component is the time put in by the developers, or as I prefer to call them, developer cycles. One of the main reasons we use Python is for the expressiveness of the language. In my experience we can ship more features that our customers want, more quickly by developing in Python than we can in any other language.

Tornado and Motor are making it much easier to deploy asynchronous web servers than it has been in the past. The new AsyncIO library will likely continue to accelerate that trend and that’s a good thing because I really don’t have time to write a bunch of callbacks.

What business needs are you solving with asynchronous web servers?

How-To Setup DNSMadeEasy Dynamic DNS on a Synology

September 21, 2013 in How To, Knowledge Base | Tags: , , ,

I had a lot of trouble finding any help to get Dynamic DNS (DDNS) set up between a Synology NAS (a great product!) and DNSMadeEasy.com DDNS service so I thought I would post the solution that I worked out in case anyone else was looking.

1. Set up your DDNS domain on DNSMadeEasy.com

DDNS setup on dnsmadeeasy.com

The wrinkle that DNSMadeEasy.com throws in the mix is that instead of the domain being updated, they use a unique ID number that’s generated when you save a record with the “Dynamic DNS” box checked.

After creating the record keep track of the password and the ID. You’ll need them later.

2. Add the DDNS provider for DNSMadeEasy.com on your Synology NAS

If you open the DDNS control panel on your Synology (Control Panel > ezCloud > DDNS) you will notice that there is no DNSMadeEasy.com option on the service provider menu.

Synology DDNS control panel

To add the Service Provider you need to SSH into the terminal. If you need help setting up terminal access check out this tutorial on the Synology wiki.

Once you have terminal access use vi to edit the /etc.defaults/ddns_provider.conf file with this command.

$ sudo vi /etc.defaults/ddns_provider.conf

The vi editor can be found on almost every POSIX system. It can be confusing for people who have never used it before, so if you need help with vi check out this cheat-sheet and tutorial.

Add the DNSMadeEasy.com entry to the end of your ddns_provider.conf file as shown in the following Gist on Github:

We are actually using the same provider as DynDNS and only using the “hostname” variable to support DNSMadeEasy.com’s “id” variable. I was a little concerned that the Synology would do some sort of validation on the HostName field and bounce the string of numbers as invalid. But fortunately they don’t and we can use that field to supply the ID without any further customization.

Save the file and reopen the DDNS control panel on the Synology.

3. Setup DDNS on your Synology NAS

Now you should have the DNSMadeEasy.com option in the “Service Provider” field. Put your “Dynamic DNS ID” from DNSMadeEasy.com into the “Hostname” field. Use the email address associated with your DNSMadeEasy.com account for the “Username” field, and the “Dynamic DNS Password” from the DNSMadeEasy.com record in the “Password” field and “Confirm password” field. Hit apply and if your status says “success” you are in business!

complete DDNS setup on your Synology

<< more posts