pedoh

A specific cover letter targeted to the company is much better than a generic one. You can have common paragraphs in all of your cover letters, but I would recommend sections that particularly target the needs of the company you're applying to. For example, if they say in their job description that using technology FOO is a bonus, mention that project you did with technology FOO and why you were really excited about it.

Otherwise, you lump yourself in with every other person out there. You need to make yourself stand out without lying or going over the top. If you can make it clear that you are really interested in THEM and not just the job, that's a positive from the employer's perspective.

While I agree with the praises directed towards Patrick, I don't think it's wise to make assumptions about his (or anyone else's) motivations. If Patrick wanted to, he could walk any of the paths mentioned in the OP.

We just don't know that Patrick isn't exactly where he wants to be in the long run. Maybe he doesn't want the things that come along with $100k, $200k, $1MM per year.

If it is his aspiration to make that kind of money, I wouldn't bet against him having a plan. Patrick's transparency about his work might give the illusion that we know what he wants in life. We don't.

I saw a javascript trick that would show the first letter of the password as you type it but then turn the letter into a dot after you type the next letter, just like a lot of mobile devices do. Seems like this would give some added sense of security / privacy.

Link: http://blog.decaf.de/2009/07/iphone-like-password-fields-usi...

Granola with raw milk, but boy does that breakfast burrito speek had sound good!

Oh, this is fun. One aspect that's interesting is that you don't know whether the other people playing are trying to be collaborative (I'll stay out of your way, let's fill up the board together) or not (I'm gonna try to make you crash). I've been playing in attack mode (be the longest, crash everyone else), personally.

As to your "Why do people pay them?" question, companies get to the scale where managing their servers in an automated fashion is necessary, and deploying new boxes within a matter of minutes instead of hours is critical. As a DevOps guy, our job is to always automate ourselves out of our job. Why do I want to do anything more than once? Deployment tools like Chef and Puppet help with the "Don't Repeat Yourself" concept.

Disaster recovery is another area where these tools can help. Imagine your database server goes down. Downtime can be really expensive, depending on your application. With Puppet / Chef and an interface on top, you could click a button and have a new box spooled up and your data automatically restored from your most recent backup. Downtime would be reduced pretty dramatically.

Auto-scaling is yet another possibility; if you can detect when you need another server, you could script it so that another server gets reserved and deployed and brought up to snuff. Then, when your traffic drops down, you could release the server.

At some point, it makes sense to either hire a DevOps guy, and / or spend money to have the deployment cycle consistent, dependable, and repeatable.

Suppose you rent a server at a hosting facility. This server could be a physical server or a VPS. It could be a piece of "cloud" infrastructure (a good list can be found at https://www.cloudkick.com/providers/).

Some people who have little technical operations experience will write their code and copy it over to their production server to deploy it. As time goes on, the server needs to be changed; perhaps you need to add a library to extend the function of PHP. More time goes on, and then all of a sudden you need to build out a second web server, identical to the first. How do you do it? The first web server has been hacked and modified, and it's not necessarily trivial to build out a new one.

Opscode uses Chef to create "recipes" that determine everything you want on a box. So instead of logging into the first web server and hacking on it to get it in your desired state, you modify your recipes to add your PHP module there. Then, when you need to build out more boxes identical to the first, you run your Chef recipe and away you go.

What I'm not sure about with Opscode is how they do Configuration Management. If I have three applications on the box, and each of them have independent configuration, does Opscode manage that versioning for me, so that I really can take a new server from nothing and have it up and running with identical versions of my code and identical versions of my configuration files, substituting values in where appropriate? You might want every web server to be identical except for X, Y, Z (maybe you route one web server to one MySQL slave and one web server to a second MySQL slave, for example). I'm not sure what Opscode is doing to make that simple.

I've built out a web interface and underlying architecture for the company I work for to do exactly this sort of thing (and a whole lot more) via Puppet (http://puppetlabs.com). My interface handles rolling upgrades to eliminate downtime and a whole host of other slick things. Our developers do not hand over code to a deployment team; they do their own deployments. I can't recommend Puppet over Chef as I have no Chef experience, but can say that I've been thrilled with what Puppet can do for me.

If you want more information, let me know either here or via email, I'm happy to go deeper if you want.

DTerm. http://www.decimus.net/dterm.php

It's not easy, is it? Imagine being able to spool up a new environment (on one server as opposed to, say, 5 in production) and feed it a copy of production data, run tests, and then tear it down. And imagine knowing that this environment was identical to production in every way except for minor configuration changes to get it to run on one box. And when you're done with it? Throw it away. That's really powerful. A new employee comes on board? Here, here's your environment. Mess with it as much as you want, we can just rebuild it if you totally hose it. All QA except for performance testing, which would need to be done on real hardware anyway, could be done in these environments.

I think tearing down walls between SysOps and Developers is important. I don't like the "this is mine, stay out" attitude. That being said, I'm all in favor of dependable and repeatable environments, and when you give people carte blanche to do what they want on the boxes, that can be a recipe for disaster.

"Oh, I just upgraded this package, yeah, can you put that in our master image?" sigh

Do it right, and you can get the developers all the info they need without having access to the box itself. Not only that, but you make it easy to spool up new dev environments for new employees.

If access does need to be granted today, then thought should be put in to see if that can be avoided tomorrow. Need a tcpdump today? Great. Access granted. Tomorrow, I'll have a script for you that takes a tcpdump and puts the file where you can access it. Access revoked.

I've used them, and yoga balls, and I've discarded them and gone back to a chair. I'd recommend looking into a standing desk; I've heard great things about working while standing.

Agreed on the branding. When I saw your post I knew it had been done before but didn't know how to do it, so I threw the link into a bare HTML page to see what it would look like.

What about doing your own form and data store, via Heroku or something similar?

Good luck with your launch!

If you don't mind the Google branding that shows up, and all you want to do is collect emails and URLs, you can embed a Google Form in your document and have it collect the info for you. After you create the form in Google Docs, go to the Form menu and choose "Embed form in a webpage". Copy the link into your landing page, and you're done.

As a remote employee, this looks amazing. I can't count the number of times I've been involved in company meetings where the presenter has forgotten to pass around his presentation or start a web conference. I can't even count the number of times I've had to ask people to repeat themselves due to bad connectivity and lack of visual clues. Having my own QB to keep in the office would be great. I don't think I can get my boss to drop $15k on one, though.

At a previous job we were using Ganglia (http://ganglia.sourceforge.net/) to collect both system metrics and custom metrics from our servers. At my current job, we still use Ganglia for redundant storage of our metrics, but then we feed the data into Graphite (http://graphite.wikidot.com/) for graphing. Graphite uses Whisper for it's storage mechanism. It's very similar to RRD. The author wrote a page about why he decided to write his own instead of leveraging RRD (http://graphite.wikidot.com/whisper). We've got over 60k metrics in our system; happy to talk shop if you want more info.

I made the switch. My first job out of college was teaching at a private high school. I certainly felt that I was making more or less a permanent decision when I decided to go; now, I'm less convinced, but I certainly agree that going back to a tenured faculty position would be difficult.

What makes you think that this new position is going to be the bee's knees and satisfy your itch? How do you know that you won't be trading one type of pain and suffering for another? Is there any chance you could use a sabbatical to do work for this company, to "test the waters"? I'm guessing you couldn't actually become an employee, but perhaps you could work some deal that would further your academic research while seeing if joining the non-academic tech industry would suit you.

To me, "major Silicon Valley tech company" smells like Google, Yahoo!, Microsoft, et cetera. Keep in mind that while all of these types of large companies have different approaches to being large companies, they all have to deal with human scale, and with that can come a load of bureaucracy and overhead that may in time frustrate you as much as it does in academia. Some of those companies do a better job at that than others.

One last thought. When I saw the light bulbs go on in my students, and when I saw them teach other students what I had taught them, so I knew they truly "got it", that was very special and very rewarding. Moving to the tech industry has had it's own rewards and intellectual challenges, but for me, teaching others was very rewarding, and I find often that the times I spend teaching my colleagues something are some of the best. Don't forget the good parts of your current job, too!

For new RoR programmers, is it recommended to just start in with Rails 3, or stick with Rails 2 until Rails 3 "stabilizes"? There are a bunch of Rails 3 books out there; do they generally line up well with this release candidate, or are they full of old information that a new RoR programmer would stumble upon and not understand how to fix?

[EDIT] The three books I saw available that specifically mention Rails 3 in the title are available for pre-order, so hopefully they will be pretty up-to-date.

I'm not familiar with AMT, but you might check out http://crowdflower.com and see if they might be a good fit for your needs.

From a startup SaaS perspective, is it really that detrimental to have your customers sent to another site (Google Checkout or Amazon FPS, for example) and then brought back after the conclusion of the sale? Do enough customers walk away if the payment system is 3rd party visible as opposed to 3rd party behind the scenes? For any small startup trying to minimize costs, it seems like eliminating those monthly minimums and setup costs might outweigh the benefits of a more seamless customer experience. Can those with firsthand experience chime in?

One issue I would caution about VPSes is that because there can be more than one VPS on a physical server, there has to be contention for resources. The vast majority of the time this may not (and hopefully will not) be an issue, but imagine that one VPS starts hammering disk. The disk has a performance limit, and therefore the resource can be starved. The managing server will do its best to prevent one VPS from affecting another, but it can and does happen. If the physical server has a huge RAID array of disks this problem will be lessened greatly; likewise if it has 8 cores instead of one. If it's not standard practice for a hosting provider to tell customers what hardware your VPS is running on and how many other VPSes can be on the machine, it should be.

Suppose you have a website that has completely constant traffic. You can therefore anticipate exactly how much computing power you need, and a dedicated machine or two will suit your needs well.

Now suppose that same site (hosted on two dedicated machines) gets a sudden increase in traffic, beyond the capabilities of your two machines. Instead of reserving another dedicated machines, spool up a cloud instance (or two) to help handle the traffic, and once the traffic returns to normal, release the cloud instance(s).

Here's another possibility. Suppose you need 100 machines to crunch data for an hour. Launch 100 cloud server for that hour at their rate and you pay 100 x $0.15 = $10.50 for the hour instead of 100 x whatever they'll charge for a month of dedicated machine usage.

If you haven't read any of Richard Feynman's books, I highly recommend them. They're not only fascinating, but with a wonderful sense of humor, as well. I particularly love the chapter in "Surely You're Joking, Mr. Feynman!" about his safecracking exploits. Not only did it show his physical skills and dexterity, but his ability to do social engineering, as well. Great stuff.

In "What Do You Care What Other People Think?" he talks a lot about the investigation into the Challenger explosion. Amazing writing on such a serious topic, in my opinion.

If you're doing SaaS and discovering your price is too low, do you raise your price grandfather in your current users for a certain period of time?

Conversely, if your price is too high, do you lower your price give your current paying users freebies (an extra month or two) for paying at the higher price?

I know at the very least I'd want to avoid another ZenDesk situation (http://news.ycombinator.com/item?id=1357592); having happy customers seems very important. Obviously there's a certain point where one needs to cut bait, though.

Can you expand on this, please?

I read the front-page and then new, and I rarely hit the More button on either of those pages to dig any deeper.

I went to an audiologist and paid $100 to have molds of my ears taken. A week later, I had a set of ear plugs with filters in them to block out most frequencies. I bought them for flying, and now that I have them, I would rather miss my flight than fly without them. If you're just looking for the noise silencing aspect of headphones, I'd highly recommend a custom plug.

For music, I have a pair of Shure E2Cs. They not only block out sound really well, but in my opinion produce very good sound. One big advantage of in-ear design like this is that you can significantly lower the volume of your sound source, which will keep your ears happy and healthy. But not everyone feels comfortable with the in-ear style. When I bought the Shures they were @100; today the Shure SE210s are available for $100, but I don't know their product line very well, so I don't know the difference, say, between the SE210s and the cheaper SE110s.

Also note that with most of the in-ear headphones, you can take them to an audiologist and get custom plugs made, as well. It's probably not worth it to buy a $100 set of headphones and then pay an extra $100 to get custom molds, but if I were purchasing a higher end set of Shures (or a similar product from Westone or Etymotic), I'd get the molds.

It's never too early to think about monitoring and metrics. In my opinion you should collect metrics on everything you can think of:

1) How long does it take for my page to load? 2) How long is this database query taking? 3) How long does this API call take? 4) How much storage am I using?

et cetera. Your metrics should give you keen insight into common system metrics as well as application level metrics. Your metrics should show you your trends and tell you when you need to add capacity and / or improve performance.

Cloudkick (http://cloudkick.com) is doing (among other things) a lot to make not only metrics collection but monitoring simple. I'd check them out.

Interesting. Are you using Chrome for Windows, perhaps? I'm using Chrome for Mac (5.0.375.29), and all that happens when I click "See it in action" is that the page is scrolled to the top.

This looks pretty amazing ... in Firefox. I tried Chrome, but no luck. Is that because Chrome doesn't support HTML5 as completely as Firefox?

Some people might lean towards this instead of Puppet / Chef / cfengine because the "normal" way to use Puppet is in a client / server model, and that might seem overly complex for some projects. But Puppet can be used in a serverless way.

At it's simplest, Puppet can do what it looks like Babushka is doing, without the interactive nature of Babushka (which could be viewed as a positive or a negative). Getting more complex, rules about what gets done / installed / modified can be pulled from a central location, even without a Puppetmaster (server).

I'm not saying the Babushka author is crazy for creating this. Perhaps he had an itch that needed scratching and wanted to build this just for the pleasure of it, or felt that Puppet was overly complex for his needs. I think the work he's done is pretty slick, but there doesn't appear to be much add-on value for anyone who is already using Puppet or Chef or cfengine.

If Ben is lurking around here, I'd enjoy hearing his motivations for creating this. He might disagree with my assessment, too, and that'd be interesting to hear.