I have learned so much about the startup life over the past couple years. I worked with a larger startup, a smaller one, and several that I can call my own. I learned how funding works, how marketing works, how sales happen (how sales don't happen), how to avoid technical mistakes and how to make great products.

Despite all of this, I believe the most important thing I have learned over this time has to do with co-founders.

Co-Founders are those people who share your vision - they work for little or no pay, they do the grunt work early on, they transform the vision into a real product. They do this in hopes of creating something great. Co-Founders are immensely important in shaping the future of your company. Given this, you should take time in considering who should become a co-founder.

What to consider

To become better at this process I have compiled this short list of things to consider. This list is by no means exhaustive, but I think it covers most of your bases.

1. How do you work with this person?

Find out how your potential co-founder works. Things I have found of particular important include:

  • How many hours will this person put in to the business?
  • How fast do they work?
  • How detail oriented are they?

Bringing somebody on board who works slower than you, less time than you, and sloppier than you will make you (and probably the rest of the team) pretty unhappy. Make sure you see eye to eye with your potential co-founder, make sure you are both ready to put in similar amounts of effort and you have similar ideas about the quality of your work.

2. What do they bring to the table?

Ideally, you should bring on co-founders that fill some gap in skills at your company. Given this, make sure the potential co-founder has skills that are valuable to you and your team. Already have five backend devs? It probably isn't wise to bring on a co-founder who loves writing backend code.

However, bringing on a co-founder with overlapping skills isn't necessarily a bad thing if the person brings other things to the table, but just be mindful about how other co-founders or team members may feel if you bring somebody else into the fray that may do the same thing they are doing.

3. Do you like this person?

Arguably one of the most important traits you should be looking for is relatability. This is somebody you are going to be dealing with every day for the next few years so you should pick somebody you generally like.

Do not invite somebody to join your team as a co-founder if you can't stand them - regardless of how skillful they may be.

4. Are there any warning signs?

Generally, people who are up for coveted co-founder positions are people you know somehow. They are friends or co-workers, so you probably know a fair amount about them. You should use any and all of this information to your advantage:

  • Have they done something like this before? How did it end?
  • How do they interact with others? Are they well liked?
  • What is their previous work like? Are they known for quality?

If the answers to these questions are not positive you may want to reconsider bringing this person on as a co-founder. I have found that behaviors from the past rarely disappear completely - if the person has done something undesirable in the past, it is likely that behavior will continue in the future. Make sure you are okay with this.

The team is more important than the idea

If you are like me, you have probably read tons of stories about startups, how they failed, how they succeeded and what could be done better. One common theme I have found is that the team is more important than the idea and execution is key. That being said, you should set yourself up for success by picking the best possible co-founders early. It is easier to be critical now than it is to deal with a bad match later on.

Have any other tips about selecting good co-founders? Please let me know, I'd love to hear your suggestions.

in project, Statusy, status page, hosted status page

After starting Bitkumo I quickly came to the realization that hosted status pages were far too expensive for what they were. The main players right now want upwards of $30-40 per month for what is mostly a static website. This is far too much for a company that is just getting started - in the early stages $30-40 could be difference between profit and loss.

Upon realizing there was a major gap in the hosted status page market, Lev Lazinksiy, Ricardo Feliciano and I started working on a product to fill that gap, Statusy.

We started working on Statusy in mid-January earlier this year, and I am very pleased to announce that Statusy is open to the world in an early release state.

Statusy homepage

Our mission with Statusy was twofold:

  1. Make an excellent hosted status page that truly met all the needs of our potential customers
  2. Make it affordable enough for even early stage startups to afford

I am please to say we have succeeded on both fronts.

Statusy offers almost all of the features of other providers including:

  • Customization - Logos, CSS, domains
  • Social integration - Twitter for now, but more to come
  • Redundancy - All of our infrastructure is fully redundant, your status page will be there when you need it most
  • Teams - No need to share one login, we offer team accounts so any member of your team can update your status page
  • Extensible - We have launched with a robust RESTful API so you don't even need to log in to report things

We have managed to offer all of this for just $10.00 per month, this is nearly 66% off the price of other providers.

Sample Statusy status page

That being said - it would be excellent if you were to give Statusy a try.

We consider Statusy to be in an early release state so we are primarily looking for feedback. If you give Statusy a try and have any feedback please feel free to add it via the in-app feedback button in the bottom-right corner, or via email to hello@statusy.co.

Thanks for reading!

in new years, goals, 2016

I always seem to find myself reflecting upon the year during the holidays - where I was this time last year and where I am now. This year has been pretty good to me overall. I've gone on several adventures, moved to Texas, gotten a new job, started my own company and so much more. I'm super excited that I've kept to this blog going for a whole year - I've always enjoyed writing but I seem to lack the dedication to keep a single project moving. Fortunately, that is not the case for this blog, this is especially fortunate because last year I wrote a post very similar to this one. This allows me the opportunity to compare what I've done this year with what I wanted to do last year. So here it goes!

According to last year's post, I wanted to do these things in 2015:

  • Obtain RHCSA - This did not end up happening, primarily because my situation changed pretty drastically over the course of 2015 - because of this, the RHCSA was not as valuable as it was to me last year.

  • Complete Master's program - This did not happen either. No good reason, just laziness.

  • Learn more virtualization - This definitely happened.

  • Learn Ruby - I would say this one is 50/50 - I definitely know more Ruby than last year, but I am certainly not proficient yet.

  • Work on personal projects - This absolutely happened.

  • Move - I'm writing this from San Antonio, TX where it is 80 degrees in December. Check!

So all in I was able to accomplish a total of 3 (and a half) goals from last year, 60% met, not too bad!

Now, on to what I've actually done this year:

  • Created SpacePanel - SpacePanel is easily the best thing I've ever personally made. I don't mean best as in it was awesome for other people, but best as in I learned so much writing it. I learned about libvirt, KVM, maintaining an actual project with people who care about the project and even a bit about crowdfunding. The knowledge is definitely the best thing to come from the project, but very close runner up was a new position at a Techstars company called Virtkick.

  • Became a developer at Virtkick - Looking back it is amazing that Virtkick and I ever connected. Virtkick learned of me because I made a snide remark on one of their blog posts (saying how SpacePanel rocked and people should use it instead of Virtkick). This got the attention of the founders of Virtkick who apparently admired my dedication to SpacePanel. Shortly after making that comment, Nowaker and Rush reached out to me, told me they liked SpacePanel and wanted me to come work for them in San Antonio. So that is exactly what I did.

  • Left my position at DigitalOcean - After getting a job offer from Virtkick I toiled for days trying to decide what to do. On one hand, I had a great job at an amazing company, but on the other hand: adventure, experience and the chance to do something I love (writing code). I eventually decided to resign from my position at DigitalOcean and move to San Antonio to work with Virtkick.

  • Moved to San Antonio - About a month after I left DigitalOcean and started working at Virtkick remotely April and I packed up all of our stuff in a big Penske truck and began the three day drive to the great state of Texas.

  • Wrote some cool software - Working at Virtkick has been amazing - I wrote code, all day every day. Previously this was something I only did for fun, but the idea of doing it all the time and getting paid for it was incredible. I learned so much throughout the year and I made a super cool new backend system for the company. Said super cool new backend system is now being tested at Bitkumo.

  • Traveled a bit - The Grand Canyon has always been on my bucket list. Right before we moved we were planning on flying out to Arizona to check out the Grand Canyon. Unfortunately, the move was pretty expensive so we had to cancel this trip. Fortunately, not long after getting to San Antonio we were able to visit the Grand Canyon with several friends. Getting there was an adventure - wanting to do the trip as cost effective as possible we did the 16+ hour one-way trip in a single day, spent two days checking our Arizona, and then did another super-not-fun 16+ hour day in the car. But all in, it was super worth it. You can know something is big, you can see pictures of it and see that it is big, but I find it almost impossible to comprehend how big something like the Grand Canyon is until you are standing there before it. It is, in a word, incredible.

  • Started a business - Along with two of my great friends and colleagues Lev and Mike I started a new cloud hosting called Bitkumo. Bitkumo of course uses Virtkick (specifically the backend system that I wrote myself - how cool is that?). The company is still young (about a week old at the time of writing) but things are moving fast and it is awesome.

So I think the tl;dr is that it has been an awesome year. Now that the year is nearing its end, its time to look to the future. That being said, my goals for 2016 are:

  • Grow Bitkumo into a strong, thriving business - I love business, I love strategy and I feel 100% in my element working with Bitkumo. I'm dedicated to making Bitkumo an awesome platform and a great company in 2016.

  • Get my code into production - I've spent most of 2015 working on the aforementioned backend at Virtkick. In 2016 I want to see this code go to production. This would be the first time something I've written is actually used for anything remotely resembling production - that idea is both frightening and very exciting.

  • Learn Ruby/Rails - This didn't completely happen in 2015 so I'm adding it to my goals for 2016. Ruby as a language, and Rails as a framework have a huge following. I firmly believe becoming proficient in RoR will be a good thing for my career overall, so I'm going to make it happen.

  • Continue growing as a developer - The most rewarding thing for me as a developer is seeing my code in use, but a super-close second is seeing my code improve. I love looking at code I wrote a year ago, saying "Wow this is terrible!" and realizing how far I've come. This needs to continue.

  • Continue growing as a person - This means traveling, spending time with my friends and family, learning, and overall learning to live a better healthier life.

I'm looking forward to another great and productive year in 2016. I hope 2015 has been great for you and I hope 2016 is even better!

in Getting Started, node.js, promises, callbacks

Coming from Python, Node.js quickly blew my mind with the whole concept of asychronous stuff. I don't think I actually understood managing things asynchronously for a few months after I started writing Javascript (lets be honest, I probably still don't completely understand it). While the wound is still fresh, I figured I would take some time to write a basic guide for navigating callbacks and promises in Node.js.

Why

If you've come from something like Python or other popular languages threading has likely been something that was either done automatically by a module or something you've had complete control over. In Node threading doesn't really exist, you have one thread so good luck and have fun!

With >1 threads you can do several things (perhaps things that are even blocking) at the same time without impacting the application as a whole (that is, other requests can still be served). With a single thread, a blocking action will block the application as a whole - if you make a synchronous call other requests will need to wait for that task to finish. This is clearly undesirable for things like web applications. What good is an application that can only serve one request at a time? Node addresses this with callbacks, and more recently promises.

Callbacks

A callback is a function that is executed after a task is completed. It usually looks something like this:

asynchronousFunction(argument, function(response) {
	// When the function is finished doing whatever it is doing, this stuff is executed
    // The callback takes any return values as arguments, so if asynchronousFunction returned 1+1, response would be 2
    console.log("asynchronousFunction is done with the response", response);
});

You can also use a callback that is defined elsewhere like this:

asynchronousFunction(argument, callbackFunction);

function callbackFunction(response) {
	// This is executed when the function is done doing its stuff
    console.log("asynchronousFunction is done!");
}

In general, callbacks will first take an error argument and then other arguments that are returned by the function that is utilizing the callback. You can test to see if the error object exists after each call to see if the call was successful:

asynchronousFunction(argument, function(error, response) {
	if (error) { 
    	console.log("Something broke!");
        return; 
    }
    // If this is executed there was no error!
});

The problem with callbacks is they are a little messy. Consider a chain of asynchronous functions that need to run one after another:

aFunction(argument1, function(response) {
	// This runs after aFunction is done
	bFunction(argument2, function(response2) {
    	// This runs after bFunction is done
        cFunction(argument3, function(response3) {
        	// This runs after cFunction is done
        });
    });
});

Not too pretty right? It gets even uglier if you want to deal with errors properly at every step of the chain:

aFunction(argument1, function(error, response) {
	// This runs after aFunction is done
    if (error) { return error; }
	bFunction(argument2, function(error, response2) {
    	// This runs after bFunction is done
        if (error) { return error; }
        cFunction(argument3, function(error, response3) {
        	if (error) { return error; }
        	// This runs after cFunction is done
        });
    });
});

Fortunately promises help make this much neater, easier to read and easier to control.

Promises

A promise is essentially an abstraction of a callback that uses simple to understand syntax and structures. A promise is just that, a promise to give something in the future. For example, say asynchronousFunction from above makes a call to an API requesting all of the virtual machines on an account. That process isn't instant, so it returns a promise which is a placeholder for the list of all the virtual machines on an account. A promise can be either resolved or rejected. A resolved promise is one that fulfilled its promise so to speak and actually has the data you were promised. A rejected promise happens if an error is encountered.

So to rewrite the asynchronousFunction from above using promises you would do something like this:

asynchronousFunction(argument).then(function(response) {
	// Executed after function is done
});

The flow works just like it states, do this function, then do this. You can also pass around promises pretty easily:

function aFunction() {
	return asynchronousFunction(argument);
}

aFunction.then(function(response) {
	// Executed after asynchronousFunction is done
});

Error management is a breeze:

asynchronousFunction(argument).then(function(response) {
	// This is executed if the promise is resolved
}).catch(function(error) {
	// This is executed if the promise is rejected
});

Promises really shine when you have to link a bunch of stuff together. Recall how callbacks looked with multiple functions and then take a look at the syntax used by promises:

aFunction(argument).then(function(response) {
	// Executed after aFunction is done
	return bFunction(argument2);
}).then(function(response2) {
	// Executed after bFunction is done
	return cFunction(argument3);
}).then(function(response3) {
	// Executed after cFunction is done
    return "All done";
});

Much cleaner and easier to read in my opinion. Errors can also propagate up the promise chain fairly easily as long as all promises in the chain are returned properly. A single catch statement for the entire chain will catch any errors thrown while processing those promises:

aFunction(argument).then(function(response) {
	// Executed after aFunction is done
	return bFunction(argument2);
}).then(function(response2) {
	throw new Error("foobar"); 
	// Executed after bFunction is done
	return cFunction(argument3);
}).then(function(response3) {
	// Executed after cFunction is done
    return "All done";
}).catch(function(error) {
	// Caught error from bFunction and stops executing
});

Bluebird is (in my opinion) the best library to use for this sort of thing. You can do tons of really cool stuff with it, including converting things that require callbacks to promises using promisifyAll:

var libraryThatUsesCallbacks = require("callbackLibrary");
var Promise = require("bluebird");

Promise.promisifyAll(libraryThatUsesCallbacks);

// libraryThatUsesCallbacks can now be used like so

libraryThatUsesCallbacks.aFunctionAsync(argument).then(function(response) {
	// I'm a promise now! 
});

// Bluebird adds new functions that basically map to the old function name + async, so bFunction would become bFunctionAsync

This can generally be done for all functions that use the callback(error, arguments) pattern though Bluebird does support other arrangements as well. Bluebird supports a wide array of other things, I would recommend taking a look at the API documentation.

Conclusion

Given the single threaded nature of Node applications learning how to write asynchronous code, and more importantly, think asynchronously, is necessary to becoming a successful Node developer. This isn't an easy task, especially if you are not used to thinking about things in this way, it took me a long time to fully grasp the concepts and properly use asynchronous functions so don't worry if it takes a bit. Hopefully this post will help you learn the basics if you are looking to develop Node applications. Please feel free to leave any questions in the comments.

in libvirt, node, node.js, node-libvirt, promises

After adding a couple things to Node-Libvirt one of the maintainers pointed out my original article on Node-Libvirt referenced the old callback style of using the library so I wanted to take a moment to write up a new guide for using Node-Libvirt with promises rather than callbacks. Since my first post offers a fair amount of detail regarding Node-Libvirt in general, I'll limit this one to showing syntax only.

Hypervisor

First lets take a look at connecting to the hypervisor using promises. Of the changes, this is the most prominent (in my opinion anyway).

Connection

var libvirt = require('libvirt');
var hypervisorObject = libvirt.hypervisor;

var hypervisor = new hypervisorObject('qemu:///system');

hypervisor.connect(function() { 
    // The hypervisor object is now connected. From here you can do just about any call you want...
    // Like hypervisor.lookupDomainById(1);
});

You'll probably want to wrap the code you need to access the hypervisor with in the hypervisor.connect() function to ensure the connection has been made before you attempt to communicate with the hypervisor.

Everything Else

It isn't really worth noting each and every function I mentioned originally, but I will give you a couple examples for how things look using promises.

The basic idea is you add Async to the name of the function you want to call, and then use then instead of a callback. For example:

hypervisor.helloWorld(function(callback) {
	// Old style
});

hypervisor.helloWorldAsync(arguments).then(function(return_value) {
	// New style
});

For real example take a look at a call to getNodeInfo:

hypervisor.getNodeInfoAsync().then(function(nodeStats) {
	// nodeStats now has the return value from getNodeInfo
});

Domains

Domains use pretty much the same syntax shown above but I'll run through a few examples:

// Lets make a new domain
hypervisor.defineAsync(domainXML).then(function(domain) {
	// Use domain to access this domain now
    
    // Now lets restart that domain
    domain.startAsync().then(function() {
    	// Domain has been restarted
    });
});

// Lets lookup a domain with the id 1
hypervisor.lookupDomainByIdAsync(1).then(function(domain) {
	// Use the domain object to do other stuff
});

Would you like to know more?

From here, everything looks almost identical to the syntax you see above. Just append Async to the name of the function and use then instead of a callback and you will be good to go.

If there are any specific calls you are interested in seeing please don't hesitate to leave a comment. Most of these calls do have examples in the Node-Libvirt tests. If you are planning on using Node-Libvirt consider following me on Twitter as I intend to document the full Node-Libvirt API in the future.

Thanks for reading!