pedoh

I wonder what would happen if you tried to make the negotion process as transparent as possible; something along the lines of:

"Look, I've read all of the negotiation strategy books, and clearly you're an expert in your field, so let's agree on the value that I bring to your company and find the right compensation package."

> No re-registration or change of any kind of the existing domains is necessary.

So who gets to own www.foobar, the owner of www.foobar.com, www.foobar.net, or www.foobar.org?

Does the reverse (finding a business cofounder) also apply? What resources do you recommend a technical person gather (beyond things like Rework, which I grok, and Four Steps to the Epiphany, which I need to reread and try to grok)?

What do you view as the advantages of PostFrenzy vs. FogBugz's Trello?

I think 0MQ is brilliant. If this is your first time looking at 0MQ, I'd suggest the following:

http://www.zeromq.org/intro:read-the-manual

Watch the first video by Ian Barber. He's an excellent presenter.

The guide ( http://zguide.zeromq.org/page:all ) is very lengthy and comprehensive, but the "hello world" example and the "Divide and Conquer" example (fan out jobs, work, fan in results) will get you up and running and start showing you a sliver of the amazing power of 0MQ.

They've even got a lot of their examples in many languages:

C++ | C# | Clojure | CL | Erlang | F# | Haskell | Haxe | Java | Lua | Node.js | Perl | PHP | Python | Ruby | Scala | Ada | Basic | Go | Objective-C | ooc

What python module did you wind up using for your Python bot?

I think a StackOverflow style app would be powerful, and yet I don't want to add yet another "knowledge base" style application on top of, say, an internal wiki, ticket tracking systems, git commit messages, et cetera.

What do you use to tie these things together, and how do you decide what goes where? The line seems to blur between Q/A-style like Coordino and a wiki, in particular. Does anybody integrate these different knowledge systems well?

This is a great list. Thanks for creating it.

There's no mention of PagerDuty in the Alerts / Monitoring section. There's also nothing in the way of DevOps tools a la Puppet / Chef, and metrics tools such as Graphite.

ExtJS has two commercial licenses and an open source license: http://www.sencha.com/products/extjs/license/

I can't argue with that one, but gravity's a bit tough. Several of my colleagues are using git-svn, and would probably love to flip over to git.

Chef and Puppet can definitely do this for you, without servers involved.

Another great use of Chef and Puppet can be seen in Vagrant (http://vagrantup.com/). Vagrant uses VirtualBox (http://www.virtualbox.org/) to create virtual instances easily (REALLY easily) and then can automatically provision them via Chef or Puppet. Sweet stuff. I love the ability to bring up a new server with the things I want to have so quickly.

We're using Puppet for our deployments, and not just initial deployments, but for code deployments as well. The puppet node classifier talks to a MySQL database that has the "right" versions for a particular server in it; upgrading consists of changing the version for a server to the desired version, and then running Puppet. I think you could create an EC2 instance that automatically runs Puppet (or Chef) on startup pretty easily. And as someone else mentioned here, you don't have to do a complicated setup with a server to get going, either with Chef or Puppet.

mopoke,

You're absolutely correct; without the people processes in place, the world's best tools aren't going to do anything for you. I'll ponder over that for the next blog post.

We're currently using Graphite ( http://techblog.appnexus.com/2011/metrics/ ) and loving it, but using MongoDB is an interesting spin.

I'd love to see some performance benchmarks and see how many datapoints you can pump in and out of Cube. We've been collecting about 1 million metrics every minute on a speedy dual proc / quad core box backed with SSDs for storage.

The big takeaway for me from this article is "treat your employees well". It may be that some devs prefer sitting in a beanbag chair with a 13" laptop. Do you think Fog Creek is going to say no? Heck no. They're going to do whatever it takes to keep your developers (and all employees) happy. We are at work a huge percentage of our lives. Not being happy at work is depressing, particularly when the employing company can take steps like this to make the environment welcoming and positive.

I think that from an employer perspective, sometimes it's the "little" things that pile up and really make a difference. For example, how much does having bagels, cream cheese, coffee, and fresh fruit available every morning really cost a company? In the grand scheme of things, probably not very much. But for those people who need something to kickstart their day, offering this sort of freebie is going to make them happy.

In my opinion, the desk setup as described above would make me FAR happier than free breakfast. Knowing that a company does this for their employees would certainly push that company to the top of the list of companies to work for.

I just wrote a blog post about metrics. We're collecting about a million datapoints every minute, using an open source package (that we're contributing back to) called Graphite.

http://techblog.appnexus.com/2011/metrics/

Buy one domain, then use one subdomain for each idea.

Here's Pingdom's response:

http://blog.pingdom.com/2011/06/22/about-yesterday%E2%80%99s...

If I were a customer, I would think this is a good response. It's essentially, "Here's what went wrong, and here's how we're going to fix it." If I were Pingdom, I'd go one step further once they've made the changes they're going to make. I'd write another post that says, "Remember that outage? Here were the steps we said we would make. Today, we're announcing that 100% of those steps have been taken, and to prove it, we just did a firedrill that replicated that outage, and everything is fine."

Any time you put your eggs in one basket you're setting yourself up for potential problems. Use Pingdom, but then add in either a direct competitor or someone else like Keynote or Gomez (no endorsements of any of the above by me, by the way). Then when one goes down, there's only momentary panic, and when they're all going off, you can panic for real.

I wouldn't jump off of Pingdom because you think someone else is good. Unless that someone else can provide some pretty hard evidence, their architecture may be just as susceptible to a hardware failure as Pingdom.

I would expect Pingdom to write up a report on what happened and write up what they plan on doing to prevent it from happening again. I don't see it anywhere on the Pingdom site, yet (I'm not a customer).

How do you propose handling the abusers who download the app and then point their virtual fingers at some random person in the theater?

Roots by Alex Haley. My copy is read, re-read, worn, and well loved.

http://en.wikipedia.org/wiki/Alex_Haley#Roots

Some of these companies are direct competitors in that how they differ is in their algorithms or the sliver of the market they're trying to "be the best" for. But then you get into the difference between networks, exchanges, DSPs, et cetera, and the differences and relationships between them get complicated. Check this graph out:

http://chrisohara.files.wordpress.com/2010/07/ecosystem_0110...

Is the owner aware of how unhappy you are? Is your boss aware of how unhappy you are? Is there any chance you can be happy at your current company?

If the answers are "yes, yes, no", then your path seems pretty clear. Give appropriate notice, leave on good graces, and move on.

Otherwise, if you think there is a chance you can be happy at your current company, go talk to your boss and / or the owner (I'd go to the boss first so that the boss doesn't ever think you've gone behind his back). You might be surprised by what they're willing to do to keep you. The results of those conversations should solidify the answer to whether there's any chance you can be happy at your current company, and therefore make clear your next path.

Best of luck.

What are the reasons you think AWS is your ultimate destination instead of Linode?

My advice would be to use a DevOps tool like Puppet or Chef to create recipes to make deploying new infrastructure as painless as possible. If you take it far enough, it could completely build your new infrastructure in a new datacenter, but even in its simplest form it will help you when it comes time to migrate. Spooling up more nodes in your current datacenter to handle spikes in traffic becomes much easier, too.

I'm going to comment solely on the adoption of Dev Ops, which I personally consider to include change management, incident management, deployment, monitoring, metrics, and file distribution.

I believe that the barrier to adopting solid Dev Ops practices is so low that for most startups, adopting them early is a smart move. Sure, today, your startup doesn't need to use Puppet or Chef to ensure that all of your servers (whether they're VMs or baremetal) are running the same pieces of software with the same configuration files, because manually installing those is easy. Once those same VMs have had features X, Y, and Z added to them, and files have been changed over and over, and then all of a sudden, you need more servers because your startup has been featured on Hacker News, you're probably going to need to re-invent the wheel and figure out all of those steps that you've done to your initial servers. Puppet and Chef make consistency across your entire environment possible, and getting them up and running is not difficult. Puppet (and probably Chef, although I'm not Chef fluent) can be run in serverless mode, if desired, too, which makes the installation and use even easier.

If you manually manipulate your servers now, you're going to need to automate later. You might as well spend a little time creating your "Dev Ops way" now, so that when tomorrow comes, you'll be spooling up identical servers that are monitored and have metrics coming out of them, you won't break a sweat, and you won't be awake at night wondering if you'll be able to recover fast enough when the Hacker News crowd comes and plays Mozart on your servers.

Here's a simple Puppet conf file that makes sure /etc/hosts is identical to /tmp/files/etc/hosts (untarred from a tarball):

file "/etc/hosts": { source => "puppet:///tmp/files/etc/hosts" }

That's it. Now of course Puppet gets more complicated. I'm using Puppet to do our code deployments backed by a MySQL database for the puppet node classifier. I can take a stock installation of an OS and bring it up to spec with the proper users, packages, our applications, config files, et cetera with a click of a button. But you can start small and simple, and as your business grows, so can your Dev Ops infrastructure. And it may very well be that your Dev Ops infrastructure doesn't need to grow very quickly. The barrier to entry, though, is so low, that for many if not most it is worth the minimal amount of time spent to get a simple and scalable method of deployment up and running.

The open source components of my Dev Ops stack consist of:

Puppet (http://puppetlabs.com) - Create and maintain files, packages, services, mounts, et cetera. Same on every server, every time.

Nagios (http://www.nagios.org) - Sets our email inbox and cell phones on fire when there are problems.

Graphite (http://graphite.wikidot.com) - Fantastic metrics collection and display software.

It's going to vary so much from child to child. This is your first, so you've got a lot to get used to.

I think you don't want to travel too early. Sleep is going to be at a premium. Establish your rhythms. Give it six weeks or two months and see what your bodies are telling you. On the other hand, if you have an ailing grandparent who cannot come and see you ... go. I am so glad that my two older children got to meet their paternal grandmother before she passed away. Circumstances will sometimes drive you the way you need to go.

Oh, and we haven't talked about cloth vs. disposables, either, right? I had never changed a diaper before our first, and yet I changed all of her diapers in the hospital, and then we used cloth diapers once the umbilical cord had dropped off. I never would have guessed I'd ever be rinsing off cloth diapers in the toilet ... it's another area where I'm sure you can find data about the environmental effects on either side of the fence. One thing I'm convinced of, though, is that when it came time to potty train, the cloth diapers helped, because they don't do as "good" a job at keeping liquid away from the body, so there was a desire on our kids' part to potty train sooner rather than later.

Hah, I like the floor analogy. I can also attest to sleeping with the baby on my chest without crushing her, despite our decision to not have her in the bed with us. As you can see, there are lots of different opinions, and they're all held by smart, rational people, so the bottom line is that do what works for you, and anyone who complains about your way of doing it can go fly a kite!

Yes, you'll get staunch supporters on all sides of every aspect of parenting. For us, we didn't want the kids in the bed with us to ensure their safety and our ability to sleep as much as possible, but still make it convenient to get her and feed her. I'm an advocate for getting them into their own room and crib as soon as possible, but when they're up every two hours, having them far away just hasn't made sense.

The cosleeper is essentially a pack 'n play with the bottom raised up. With the first two kids, we just used a crib but had them next to the bed. The cosleeper means we don't have to get out of bed to do a feeding, although if she needs changing, we still have to get up, as the changing table is across the room.

Another tip I'll pass along is not to insist in absolute quiet and darkness when the baby is sleeping. I think the sooner they get used to sleeping with normal house noises, the better. If they get too used to quiet and absolute darkness, then when you need to get them to sleep in a different environment, it'll be tough.

Oh, and travelling when they're really young is easier than you'd think. It's when they want to be mobile that it gets harder. But when they're really tiny, they're just going to sleep anyway!

2. When baby cries, he's hungry, needs a change, or has a bubble that needs to go either up or down. And you won't necessarily know which of the three he is until you've tried to fix all three.

Congratulations on your new startup! My third daughter is now two and a half weeks old.

I think that the biggest step for you will be to come to terms with the fact that nothing will ever be the same. And I say that, knowing that you won't fully grasp that until the first time you see your child. And then you'll relearn that with any subsequent children! For me, the first time I've held each of my children, I've been completely floored and awed and instantly in love. All of a sudden, here is a person on earth that I would die for. It's amazing.

You and your wife are about to be very tired. Your son will need to be fed, changed, and burped ... and sometimes it will seem like there's no break in between! I think establishing very regular patterns is a good thing for everyone. Same time to bed, same time to get up, et cetera. It will take tweaking and modification as time goes on, but talk to your wife on a regular basis about how the patterns are working or not working, adjust, and keep on going. For us right now, the pattern is that she goes to bed earlier and I stay up with the baby, letting her get some solid sleep until the baby needs to be fed again. We're still tweaking the parameters, and we've been so fortunate to have my wife's mother staying with us, and she's a huge help, so once she's left, it will be another adjustment.

I suggest using a cosleeper. Having the baby sleep with you in the bed may very well mean that you don't sleep as well because you'll be paranoid that you'll roll over onto the baby. Or worse, you'll roll over onto the baby! A cosleeper puts the baby conveniently close.

Crying is okay. Let him cry a little bit. The natural instinct is to immediately feed / change / console. If you are solving his problems a microsecond after he announces there's a problem, then he'll expect that every time. If he's allowed to cry a little here and there, he'll understand that mom and dad will still take care of him. It will ease the transition to the day when he's sleeping in a crib, not in the same room (also highly recommended).

Take ALL advice with a grain of salt. What works for me won't necessarily work for you. Be ready to try different approaches. Note that this may be in direct conflict with establishing regular patterns!

Best wishes to you and your wife, and if you have any questions you want to run by a new dad (before or after your son is born), please feel free to reach out, my email is in my profile.