mattjaynes

Remember that Paul Graham was a key leader in the early days of spam fighting using Bayesian filtering etc.

http://paulgraham.com/better.html

Spammers aggressively try to game email. Likewise, promoters aggressively try to game HN.

How do promoters try to game HN?

Voting Rings

If you're not familiar with that term, a voting ring is basically a group of people (or robot accounts) that collude to upvote certain stories.

It shouldn't be surprising that Paul Graham would take a similar approach to Voting Rings as he did to Spam.

In one of your comments, you said: "I know it doesnt work because I click upvote and it doesnt assign any points while a friend sitting right next to me could do the same thing and assign points."

If you and another account always seem to upvote the same stories, yet no one else seems to upvote them at the same rate, then it starts to look like a voting ring.

Just like with spam, there will be false positives. I've heard of this happening to folks who have an audience that are also largely HN users. When they send out a new post, then many of that audience upvotes the post, but since it's often the same people, the voting-ring protections get triggered and the post will quickly drop off the front-page.

There are probably many signals that pg uses to detect voting rings. I'm sure they're not perfect, but I'm glad they're there. Otherwise HN would be overrun by aggressive promoters and HN would quickly lose its usefulness.

Advice to promoters: 1) create valuable content that helps users be awesome (no one cares how awesome your brand is), 2) submit it to HN, and 3) don't ask your audience to upvote it

Many promoters just can't help themselves and will do #3 anyways. Just be forewarned that you will likely trigger the voting-ring protections and will be shooting yourself in the foot.

For help with #1, see http://shelby.tv/video/vimeo/54469442/kathy-sierra-building-...

Please don't hesitate to post links to your own work. You're putting serious effort into providing value to the community. How else will we know about it?

Here's the link:

http://www.kickstarter.com/projects/909377477/learn-ruby-on-...

For my recent technical book, I spent 3 weeks writing over 200 pages and then 3 weeks editing to get the book down to under 80 pages.

It's funny because I then had several complaints (from non-buyers particularly) that the book cost too much for an 80 page book.

Someone can certainly save their money and reproduce the experience of the book by spending a couple of painful weeks combing through documentation and hitting their head against walls. OR, they can spend less than what they probably make in an hour and get the same knowledge in 80 pages.

My target audience was people that value their time far more than their money, so that's why I spent so much effort making the book as succinct as possible.

As an aside: I'm really glad I put a price on the book. Initially I was tempted to have it be "pay what you want" so it would be more accessible, but that would have devalued it I think. Instead, I've offered a special cheaper option for students, junior developers, and those in countries where the book would be prohibitively expensive. So far, I've had about 50 people take me up on that.

The book has been successful enough to give me another month where I don't have to take contracts and I can focus on creating more content. If I hadn't charged sufficiently for it, then I'd have to pause everything and do contract work.

So, spending that extra 3 weeks making the book shorter and more focused was a win for both me and my target customers.

For anyone curious, here's the book: http://devopsu.com/books/taste-test-puppet-chef-salt-stack-a...

Ansible has been taking off in the DevOps world and this newsletter curates the latest news from the community.

Just launched the first issue today, which you can see here:

http://devopsu.com/newsletters/ansible-weekly/1.html

If you're not familiar with Ansible, check out my earlier blog post on it: "Shell Scripts vs Ansible: Fight!"

http://devopsu.com/blog/ansible-vs-shell-scripts/

I battle with this and one thing that's been helping me a lot is "Letting It Cool". By that I mean that I delay reading "new" things until they've had a chance to lose their "newness".

I've found that newness is a false signal for value. Just because something is new, we tend to errantly assign extra value to it.

You can combat this by removing the new quality from the item by putting it somewhere where it can "cool down".

For me, I save all the articles I want to read for the weekend. I just email the articles to myself and they go in a special folder and that's where they cool off for a few days.

When you first start doing this, it is surprising how much some articles lose their perceived value over a few days. An article that I was really excited about when I first saw it will often induce a "meh" a few days later.

On the other hand, some articles still retain their value and appeal several days later.

I end up spending far fewer hours a week reading articles because of this method. It also helps to keep me focused since I don't let my mind wander to other topics during my work day.

This also works for other things like movies, tv shows, facebook, etc. If you want to see the true value of something, delay enjoying it until the newness has worn off. It helps reduce what you consume and increases the quality of what you do.

If your goal is to produce more and consume less, then this strategy can really help.

http://devopsu.com/blog/productivity-tip-let-it-cool/

I totally understand where you're coming from. That's actually why I wrote this. Many of the existing tools just don't have the ROI for smaller systems. The exciting thing is that there are new tools to choose from that have dramatically lower barrier to entry. I'd encourage you to check them out when you have a chance. Also, would love to hear if you ultimately use one, please feel free to email me.

Initially I was using Ansible's `lineinfile` module to do exactly that. It's pretty trivial to do if you want to compare true Apples to Apples. Here's an article with some examples: http://fabian-affolter.ch/blog/the-lineinfile-module-of-ansi...

However, I wanted to show the actual process I went through. Editing the file in place seemed silly to do with Ansible, so I went with putting the config file in version control and copying it over. That also had the benefit of showing how Ansible encourages better practices than shell scripts.

Of course, that's totally subjective, so for some folks that use shell scripts, they may already know to put their config files in version control. However, in practice, I've not seen that be the case.

Great question.

Github has a project called Boxen that does this for Mac OSX: http://boxen.github.com/

Google uses their own Puppet solution for their developer workstations: http://www.youtube.com/watch?v=YlKXRdSAZhY

Ansible will work great for this too - particularly if you're on Linux.

That's a great point. I initially didn't have comments for any of those code sections. However, most of my reviewers encouraged me to add the comments so it would be clearer what each step was doing for beginners.

This article will be preaching to the converted for many of you, but I still see so many folks still doing manual installs and shell scripts even for large companies that I felt I needed to try and convert a few more folks over to saner systems.

Fortunately Ansible has dramatically lowered the learning curve and now is a great time to make the switch. So, if you have friends that need an "intervention" from their manual installs, hopefully this will help you make your case to them :)

Of course there are many great config mgmt tools out there. I singled out Ansible because it's so simple to get started with and I've found that the learning curve is usually the biggest hurdle to adoption.

"Obviously, if the only criterion was that it should just work, everyone would go with the simpler system."

It's obvious to you and me, but to many people it's not obvious at all. You only have to look at the very large deadpool of companies that made these mistakes and died because of it.

People optimize prematurely, scale prematurely, make ego based decisions, care more about interesting tech than making the business grow, etc etc. That's really the whole point of the parent article - people make bad decisions because of the allure of some "cool" but complex and unnecessary tool.

Also, thanks for the note on the background - I'll fix that :)

Novelty Driven Development (NDD)

Chris points out a great example of NDD here with Hadoop.

I do a lot of client work and I see this mistake CONSTANTLY. So often in fact, that I recently wrote up a story to illustrate the problem. Rather than use a tech example, I use a restaurant and plumbing to drive the point home. When the same scenario is put into the context of something more concrete like physical plumbing, it shows how ridiculous NDD really is.

http://devopsu.com/blog/boring-systems-build-badass-business...

One of my favorite quotes from Rich Hickey:

"Simplicity is hard work. But, there's a huge payoff. The person who has a genuinely simpler system - a system made out of genuinely simple parts, is going to be able to affect the greatest change with the least work. He's going to kick your ass. He's gonna spend more time simplifying things up front and in the long haul he's gonna wipe the plate with you because he'll have that ability to change things when you're struggling to push elephants around."

http://devopsu.com/blog/simplicity-is-key/

Hi Dan,

It really depends on your situation. Please shoot me an email and we can discuss in more detail: matt@nanobeep.com

All of the tools will scale to at least several thousand servers, but they each have slightly different ways of doing it.

I'd recommend choosing the tool that makes the most sense for you at your current scale since they all can probably scale to what you need.

I mention that the book is for folks with less than 100 servers because I don't go into how to set up these tools for higher scale in the book.

So, to get the info on how to scale up to very large pools of servers it'd probably be best to first pick a tool and then look at its specific documentation for scaling up.

Thanks for letting me know! I had no idea, though I probably should have guessed given the word root. Very interesting, that gives me a new perspective on the word :)

This is awesome. I especially love his focus on reducing the complex down to the very simple. He put a lot of work into simplifying the design and the payoff was huge - only 3 shapes make up the whole thing!

From the article: "The three shapes we derived above amount to a remarkable simplification in fabrication and construction. We have decimated the complexity of the dome."

"Decimated" is the perfect word for it.

Here's a related gratuitous simplicity quote from Rich Hickey (of Clojure fame):

"Simplicity is hard work. But, there's a huge payoff. The person who has a genuinely simpler system - a system made out of genuinely simple parts, is going to be able to affect the greatest change with the least work. He's going to kick your ass. He's gonna spend more time simplifying things up front and in the long haul he's gonna wipe the plate with you because he'll have that ability to change things when you're struggling to push elephants around."

http://devopsu.com/blog/simplicity-is-key/

Just finished writing a book where I compare the experience of using Puppet, Chef, Salt, and Ansible. I use each tool to build an identical system so you can get a sense of how each one approaches the same problem.

The most valuable thing I got from that project was my introduction to Ansible. It was really a shining star in the pack.

I have to give credit to its predecessors (CFEngine/Puppet/Chef) and its competitor Salt all for being great tools in their own right. But it is Ansible that has the power and simplicity to really take on the ultimate competitor: manual installs and hodge-podge shell scripts.

Many of you would be shocked at how many tech companies still don't use any kind of configuration management (CM) tool.

When you think about it, a company's server setup is essentially the foundational "app" that the actual business app runs on. So, not using a CM tool is kinda like having no tests and no version control for your most important software.

Sound insane? It is.

Most developers would laugh at a company that had zero tests and didn't version control or even backup their code. But that's exactly what many companies do with their systems.

Yet, for many businesses, they don't realize the astronomical risks and costs of this neglect.

At a recent client job, the former system administrator set up all their servers manually and left ZERO documentation. I had to spend a few weeks devining what he did and try to capture everything into a CM tool (Chef in this case). Not one week after I finished doing that, one of their key servers inexplicably failed. Fortunately, I had done the work needed and they were able to bring up a replacement within minutes. Had that work not been done, the company would have been severly crippled and might have even died due to the days of downtime that would have been inevitable.

That's just a tiny example. The cost savings for a business are huge when the team uses a CM tool. When it takes a couple minutes to bring up a new server instead of hours/days/weeks, that's a huge savings (assuming your engineers cost greater than $0).

With Ansible, there is no more an excuse for not using a CM tool. It's so simple that it can actually be easier than doing a manual install or writing a shell script. Some of the more complex CM tools take difficult weeks to learn, but with Ansible you can be up and running with confidence in a couple hours.

Not only that, but Ansible gives you robust remote execution capabilities right out of the box along with a lot of other cool stuff.

Shameless plug:

If you want to see Ansible in action and how it compares to the other CM tools, check out my book. Just barely launched a few days ago: http://devopsu.com/books/taste-test-puppet-chef-salt-stack-a...

Consider that 37Signals probably has a much larger dataset and is still happily scaling vertically due to Moore's law.

http://highscalability.com/blog/2012/1/30/37signals-still-ha...

It's probably the cheapest, quickest, and least risky option if your engineers' time is expensive (which it most likely is).

Of course, you'll ultimately also want to find bottlenecks and tune the DB and cache the hell out of everything, but scaling vertically will at least buy you some good time so you can do that in a more relaxed time-table.

Related links:

http://37signals.com/svn/posts/3202-behind-the-scenes-the-ha...

http://37signals.com/svn/posts/3090-basecamp-nexts-caching-h...

http://37signals.com/svn/posts/3112-how-basecamp-next-got-to...

Thanks! Yeah, I'm going to be blogging a lot more now that the book is released.

Would love to chat about devops - feel free to email me anytime: matt@nanobeep.com

It might seem like the same page since the book cover is at the top of both pages. Just in case, here's the direct link: http://devopsu.com/books/taste-test-shell-script-sample-chap...

I joined Hacker News 6 and 1/2 years ago and it's been a great community to be a part of. I was one of the early karma leaders and I remember writing a blog post (hilariously embarrassing now) about reaching the top spot with ~650 karma points. I'm sure tptacek and patio11 beat that nowadays before their morning coffee :)

I've only had about 300 visits to DevOpsU.com from HN so far, but of those, over 100 signed up on the email list to be notified of this book.

Given my history with HN and the early interest from here, naturally this is where I'm launching my first book. And here's a special early-bird HN discount link that's good for today's launch: http://gum.co/taste-test/hn

It's very important to me that this be available to everyone that wants it, so if you're a student or for any reason can't afford to buy the book, please contact me: matt@nanobeep.com

Of course, if you can afford it and it will be a win for you, please buy it and support the creation of more business-focused devops training.

Cheers! Matt

The article mentions Salt and Ansible - if you're interested in these new generation config management tools, check out my book which launches tomorrow: "Taste Test: Puppet, Chef, Salt, Ansible"

http://devopsu.com/books/taste-test-puppet-chef-salt-stack-a...

In the book, I implement an identical project with each tool so you can see what each one is like to work with.

I definitely had some big surprises when writing the book. Spoiler: Ansible was by far the simplest, easiest to understand, and quickest to get up and going.

To get a discount for the book release, just sign up on the mailing list: http://devopsu.com/books/taste-test-puppet-chef-salt-stack-a...

Thanks :) Docverter is new to me, I'll definitely check it out!

For my technical book, I was getting frustrated with the page breaks interrupting the code sections in weird places.

There's a bit of a hack you can do to create a continuous single-page PDF if you're generating your book from html/css:

    @page {
      size: 216mm 17600mm;
    }

That tells the PDF printer to make the page 8.5 inches wide and really really long.

It's dirty, but it works!

Derek Sivers said this about it when I sent him a copy:

"I love that continuous-page PDF format. Never seen that before, but it's so much handier than artificial pages."

For my upcoming book, I'm releasing both a page-breaks and a continuous version of the PDF.

http://devopsu.com/books/taste-test-puppet-chef-salt-stack-a...

The continuous PDF doesn't work well in some PDF readers, so unfortunately I have to also provide a version with page breaks.

## Full Setup

For the curious, here's the rest of my setup:

I'm using Jekyll so I can just do everything in markdown/html/css. It uses pygments for the syntax highlighting and I'm using my own customized syntax coloring styles. Then I use PrinceXML for generating the pdf.

It makes for a nice workflow...

First I start the jekyll server with the --watch flag so it will auto-recompile the html:

    jekyll serve --watch

Then I use PrinceXML to generate the pdf:

    prince http://0.0.0.0:4000/breaks-no.html -o breaks-no.pdf

If I want to have the pdf auto-generated too, I use fswatch (OSX utility similar to inotifywatch):

    fswatch dir_to_watch_for_changes "prince http://0.0.0.0:4000/breaks-no.html -o breaks-no.pdf"

Jekyll is handy since I can have multiple versions of the book, but still keep things DRY via includes. For example, I have the book version with page breaks (breaks-yes.html) and a continuous page version (breaks-no.html).

I tried several other pdf generation utilities, but none came close to the quality and consistency of PrinceXML.

The pro license for the server version of PrinceXML is pricey - $495 ( http://www.princexml.com/purchase/ ). So, I'm only using the pro version for development and for the final versions, I'll be using their SaaS product which is only $15/mo: http://docraptor.com/plans

Anyway, that's the process so far!

## Book Launch Tomorrow

Manage servers? One of the biggest wins for making your systems more awesome is to use a configuration management tool like Puppet, Chef, Salt, or Ansible.

If you want to make sure your systems are fast, scalable, and secure, the first step is having full control and power over them.

Tomorrow, Sept 4th, I'm launching my book "Taste Test: Puppet, Chef, Salt, Ansible" which is designed to save you the days or weeks of research when picking one of these tools.

In the book, I implement an identical project with each tool so you can see what each one is like to work with. You may be surprised at which ones were super easy and which ones were really difficult to work with.

To get a discount for the book release, just sign up on the mailing list: http://devopsu.com/books/taste-test-puppet-chef-salt-stack-a...

Hire engineers that will optimize your apps and systems for the highest business value and the lowest cost.

It seems silly and obvious to say that, but many engineers seem to have forgotten that goal.

The 2 mistakes I see over and over are systems that are optimized for Novelty and systems that suffer from Neglect.

## Mistake: Optimizing for Novelty

Bored engineers often optimize for novelty. That means they add technologies to your systems not because they're needed, but because the engineers want to play with them. Rather than consider the implications of making the systems more complex and more costly to manage, they are easily lured by shiny new technology and come up with justifications to use it even if it provides negative business value.

These engineers aren't bad people. They will legitimately think that the new technology is a good idea. They may even make an impassioned business case for it. But listening to these engineers is the equivalent of a naive young girl believing a teenage boy "really loves her" at the end of a first date when he wants to go to Make-Out Point "just to talk". The boy may actually believe this in his heart, but any woman with more experience will see exactly what's really going on.

To see companies that suffer from this, it's as simple as looking at a few job postings for developers. Look for the postings that list requirements for waaaay more technologies than the company could possibly need. It's a sign that novelty has cursed that company.

For more on this, see my post: http://devopsu.com/blog/boring-systems-build-badass-business...

If someone offers to make your systems "exciting and cool!", be very afraid. Your systems are the foundation of your business and they should be simple, secure, scalable, and generally pretty boring.

## Mistake: Neglect

The other problem I see frequently are systems that are simply neglected.

No one knows if the database backups work. No one knows if there are critical security updates that need to be applied. No one knows if the site is down until a customer complains. No one knows if the guy who quit a year ago still has a copy of the production database. On and on...

You will often see neglect in systems that became complex due to novelty. Every new technology that is added to a system requires monitoring, documentation, and security updates. The more technologies that get added to a system means the more technologies that are at risk of becoming orphans and neglected.

## Shameless Plug

Manage servers? One of the biggest wins against neglect is to use a configuration management tool like Ansible, Salt, Chef, or Puppet.

If you want to make sure your systems are fast, scalable, and secure, the first step is having full control and power over them.

Tomorrow, Sept 4th, I'm launching my book "Taste Test: Puppet, Chef, Salt, Ansible" which is designed to save you the days or weeks of research when picking one of these tools.

In the book, I implement an identical project with each tool so you can see what each one is like to work with. You may be surprised at which ones were super easy and which ones were really difficult to work with.

To get a discount for the book release, just sign up on the mailing list: http://devopsu.com/books/taste-test-puppet-chef-salt-stack-a...

Michael Shermer of "Skeptic" magazine covered how easy lie detectors are to game here: http://www.youtube.com/watch?v=GLL3wtgBiFA

In the video, a former Polygraph Examiner, Doug Williams coaches him on how to beat the test. Then they test Mr Shermer and he defeats the test easily.

Polygraphs are so prone to bad data, they should be retired ASAP. They're slightly more effective than dowsing rods. http://en.wikipedia.org/wiki/Dowsing

In related news, Iraq spent $38 million on dowsing rods to "detect" bombs: http://www.businessweek.com/articles/2013-07-11/in-iraq-the-...

How many lives have been lost or ruined due to lack of basic understanding of available science?

Seeing these classics discussed at all is awesome.

Code Complete was (to me) revolutionary at the time. Though it may seem a bit dated now, it was a foundational work that much of what we take for granted was built on.

I don't hear enough talk about Steve McConnell's other book "Rapid Development". http://www.amazon.com/Rapid-Development-Taming-Software-Sche...

I just looked at its Amazon page and it has 5 stars with 115 reviews. That doesn't surprise me at all - it's well deserved.

It came out well before the agile movement, and I would contend that it laid the foundation for it.

I'm so glad I read that at the beginning of my career. As a junior developer, it helped me immensely and even more so over the years.

I've been recommending and using Puppet and Chef for years. However, the new generation of tools like Ansible and Salt are miles ahead in terms of usability.

Ansible in particular makes it easy to be up and going in a matter of minutes where some of the other tools literally take days. So, if you're on the fence, I'd try Ansible first, then if for some reason it's not working for you, then consider Chef.

OpsWorks is a nice convenience on AWS and is implemented with the Chef configuration management tool (provided by Opscode, the company behind Chef, hence the name).

Shameless plug:

If you know you should be using a configuration management tool, but haven't picked one yet, I'll be releasing a book on Wednesday Sept 4th just for you.

The book is called "Taste Test" and compares Puppet, Chef, Salt, and Ansible.

In the book, I implement an identical project with each tool so you can see what each one is like to work with.

I definitely had some big surprises when writing the book. Spoiler: Ansible was by far the simplest, easiest to understand, and quickest to get up and going.

To get a discount for the book release, just sign up on the mailing list: http://devopsu.com/books/taste-test-puppet-chef-salt-stack-a...

I never said a week. This will obviously take years. It's just starting - that's the point.