WALoeIII

Did you get stuck in the Fedora 8 trap as well? It was the 'starter' in 2008/2009 and it took us two years to get off it.

Because the US is big and fuel is expensive.

LA -> Denver is 837 miles. (http://www.wolframalpha.com/input/?i=distance+from+los+angel...)

London -> Rome is 892 miles. (http://www.wolframalpha.com/input/?i=distance+from+london+to...)

LA -> NYC is 2,462 miles. (http://www.wolframalpha.com/input/?i=distance+from+los+angel...)

You can fly the longest flight I can think of in Europe in the same distance. (http://www.wolframalpha.com/input/?i=distance+from+Lisbon+to...)

We're working on that right now. We have persistent XMPP based chat with embed support. Try it out, my email is in my profile if you have any questions.

http://onehub.com/try/beta

Your chained cert might actually be the bottleneck if the total data exceeds 4K and the user has to do a second round trip to ACK the cert.

http://journal.paul.querna.org/articles/2010/07/10/overclock...

Basically, unless you are certain you need it 4096 bit security, use a 2048 bit key (1024 is not secure anymore) and only include the minimum number of intermediate certs you can get away with. OSCP stapling doesn't seem worth it if it cause you to over flow the initial TCP window.

Heroku.

I wrote a pretty detailed piece on doing exactly this last summer, hopefully soon iClassify will be replaced by Puppet Dashboard, but for now I run both.

http://onehub.com/blog/posts/coordinating-the-onehub-cloud/

Puppet (as of 2.6) has a pure Ruby DSL. Puppet and Chef are rapidly converging on the same feature set, at this point its like arguing .rpm vs .deb. There are certainly differences and if you spend a ton of time with both tools you will have a favorite, but fundamentally they both serve the same purpose and will enable you to get the job done.

Merlin Mann's comment seems so fitting:

http://twitter.com/#!/hotdogsladies/status/12525667593752576

"Pass it over to some other thread"

What you are suggesting here is exactly what Erlang provides for you. Each connection is a light-weight process inside the VM. The VM then schedules these Erlang processes against native threads. The difference is Erlang has perfected and proven that it can do this reliably over 20 years of development. You would be implementing this by hand, and guaranteed to screw up because its a very hard problem and you are not the smartest person in the world.

Hybrid solutions with Evented I/O and Multi-threading end up being the solution, Erlang is a hybrid out of the box.

This combined with the recently rolled out SSL termination in the Elastic Load Balancer product (http://aws.typepad.com/aws/2010/10/elastic-load-balancer-sup...) makes supporting custom domains a cinch.

"It doesn't have a library for efficient in-process access"

https://github.com/mojombo/grit

If you are concerned for speed, you want to go with one of the "big boys" to get a cert that is closer to the root the browser trusts. The more intermediate certificates you have to supply, the more the client has to download to complete hand-shake, and you should strive to keep it under 4k to avoid overflowing the initial TCP window (which would then require another round-trip).

Can someone explain this statement: "remember that there's no point using AES-256 with a 1024-bit public key"

Why not?

Does the extra 1K added by OSCP stapling put enough pressure to make your payload too big for the initial TCP window? It seems like it is impossible to use a 2048 bit key, include an intermediate certificate and turn on OSCP stapling while staying under 4k.

The FileAPI has even less support than XMLHttpRequest 2. Specifically, you are linking to a spec that was updated on tuesday of this week: "W3C Working Draft 26 October 2010". It will be excellent once we can do chunked uploads but this is still a vastly better experience then <file> fields!

Ruby JavaScript Objective C (Mac) C# (Windows) Perl

50,000 ft overview:

Rspec: Behavior Driven Development Framework. It is essentially a different approach to testing than the test/unit (which Rails uses by default). In Rspec you are more interested in testing the side effects of your code, i.e. its behavior, you are less concerned with the internals. This doesn't mean you should write huge methods, and in the end your specs and tests will look pretty similar. My company uses Rspec on our main project.

http://gist.github.com/649417

People will argue the value of the different styles until they're blue in the face. I liked Rspec's syntax more so thats where I started, but in the end I know both and think they each have their own merits and its probably a total wash. Recently with things like shoulda and other tools both approaches are rapidly converging on the same feature set.

Cucumber: Integration framework. This tests your whole stack end-to-end. Depending on what you are building this may be the only way to test it, and for a lot of people they are just doing Unit + Integration tests and not writing any controller tests. You write in Gherkin (http://github.com/aslakhellesoy/cucumber/wiki/gherkin) which is a special subset of English. You can also use Steak (http://jeffkreeftmeijer.com/2010/steak-because-cucumber-is-f...) which lets you write your story in pure Ruby. Either way, this story is broken out in to steps and then some driver follows those steps, either driving or emulating a web browser. The original driver was Webrat, which you can think of as a web browser in Ruby. Webrat has been replaced by Capybara which is more complete and has pluggable backends, including Selenium. If you aren't using much JavaScript you can stay in pure Ruby and your tests will be parsing the HTML with something like Nokogiri, this is also pretty fast. If you have complex JS you can actually drive Selenium which in turn will drive a real browser (you can even drive flock of different browsers). Depending on how complex you get this can be a total PITA, so I would start simple with just getting it running in pure Ruby and maybe testing your sign-up form.

Story -> Cucumber -> Capybara -> Selenium -> Firefox... its a lot of layers and as a result can be suuuuuuper slow.

Factories: Instead of pre-loading a database with stuff (fixtures), factories let you write code that returns prepped objects for you. ActiveRecord takes a row from a table and converts it to an Object (Object Relational Mapper - ORM). Say a post from the posts table into a Post object. Factory Girl will just make you a Post object. I much prefer factories because you can actually get a stack trace to figure out where all the data came from instead of shifting between a SQL database, a YAML file, and a Ruby file to find your 'fixture fail'. There are some variations on preferred syntax and Factory Girl supports most of them.

Shoulda: Just some macros to save you typing. Most of them work in both Test/Unit and Rspec. Instead of writing a test like this to ensure there is a validation error if number in't a number:

http://gist.github.com/649419

Just saves you time and typing, at the expense of learning the helpers.

A good test is something that breaks when the code breaks. Start small, test a few 3 line methods and then build up successively higher tests. Read the tests of some projects on github to get a feel for what they're looking to test, and how they approach it. Then just ask a lot of questions.

I don't want SSL for Facebook. SSL is slow, and its only slower the worse your latency. Until SSL is fundamentally changed to be fast, I'm going to avoid it at all costs.

Currently on my production application it adds a minimum of 200ms per request.

This is yet another reason to use a tool like 1password.

It should be noted that even cookies marked 'Secure' will be sent over HTTP for versions of Rails prior to 2.3.10 and 3.0.2.

https://rails.lighthouseapp.com/projects/8994/tickets/5629-s...

And it has been further enhanced recently: http://github.com/rails/rails/commit/2d5a12a50bcd83fcc99865d...

Collectd + Visage (http://github.com/auxesis/visage) Monit + Monit Aggregator (http://github.com/mattfawcett/monit-aggregator)

I've hacked on both a bit, but they're great starts for small clusters.

This looks great, hopefully Splunk will get some competition. Its a great tool but its far-far-far too expensive for the typical startup team.

Off-loads SSL now.

This is a total micro-optimization at best. Nearly every client is going to support compressed content. The difference between minified then compressed and unminified and compressed is tiny.

You are right though the difference probably does matter on the scale of Google, MSN, and Yahoo, but I wouldn't focus on it for my site.

TCP Slow start plays a big role here. The fewer the packets required to carry the request, the faster the complete request can be addressed by the webserver, leading to a faster download.

http://en.wikipedia.org/wiki/Slow-start

Essentially your client waits for ACKs from the server when it sends its first packets. The greater the RTT the higher the penalty. This is part of why DC -> NJ didn't see much benefit but CA -> NJ saw a nice boost.

There was a great talk on this at Velocity Conf 2010: http://en.oreilly.com/velocity2010/public/schedule/detail/11... - I have not yet found video, but you can flip through the slides.

Checkout this visualization of the slow start and you can see how sending even one fewer green dots over a large distance could considerably change the overall time.

http://vimeo.com/14439742

I work for a small startup with retirement plan. I just move 10% of my monthly income into a Roth.

The harder question now is what to invest the Roth in? CDs are terrible, T-bills would require like a 5 year investment to see decent return... index funds? I'm stumped here and my old CDs are about to come up soon.

Facebook has some great notes on their use of Erlang in the Chat node.

http://www.facebook.com/note.php?note_id=51412338919

Perhaps they did not have a cool enough accent? 'EARRRRRLang'

Kidding - I would be very interested in more on why Scala failed as well. Both Scala and Erlang are implementations of the Actor model and should theoretically be very well suited to this.

I wouldn't necessarily put Clojure between JRuby and Scala (I hope I am not misinterpreting). I think it should be more along side of JRuby depending on the type of problem you are trying to tackle, it supports a totally different paradigm of programming.

Do it, and most importantly: don't "cheat." Make sure your machine is 100% described by your tool. The closer to 100% you are without being at 100% the more likely you are to forget that single tweak.

Chef vs Puppet is like Emacs vs Vi. I use Puppet because it was the only game in town when I started, but I know a bunch of the Chef guys (hi Adam!) and they know whats up. The tools have different approaches but are rapidly converging on the same feature set, pick a simple role (say a webserver) and do the entire config in both tools and you'll know almost instantly which one matches your mindset better. I like to think Chef is a bit closer to the shell, things happen in order and you can rely on that, whereas Puppet is a bit more abstract and doesn't require you to micro-manage it as much. The golden truth is somewhere in the middle of this approach, Puppet for example just added some features to make ordering more consistent since people have really struggled with that in the past.

Chef is pure Ruby, so if you know Ruby you'll have a nice head-start. Puppet has the Puppet DSL, which if you are a sys-admin jives well with config style syntaxes. Puppet just released a pure Ruby DSL as well but it doesn't have 100% feature parity with the Puppet Language.

Provisioning and Bootstrapping machines is still a black art. I use a ruby script that sets some environment variables then launches a first run of Puppet, after that Puppet takes over and manages. There is no silver bullet (yet) for getting a machine into your Puppet/Chef cluster, though there are a lot of innovative approaches that look very promising. Depending on your environment (EC2 vs say Slicehost) I'm sure you can find a blog post that will get you going in the right direction. Here is mine: http://blog.onehub.com/posts/coordinating-the-onehub-cloud . This is already a bit out of date, we're migrating from iClassify to the officially blessed Puppet Dashboard (http://www.puppetlabs.com/puppet/related-projects/dashboard/) we just need to put some more time in to finish.

Testing sucks. You will need to come up with some repeatable environment you can run your configuration against. I use VMWare and just continuously restore to a snapshot. There has been some good development here, especially with Vagrant (http://vagrantup.com/). This lets you write a shell script (or rake task in my case) that boots an instance, runs the config and then pauses for you to inspect. From here you can push another button and 'retry' the whole thing or destroy the VM and start over. It is annoying to get this going and you'll be tempted to just start on one of your machines but that is a bad idea. This tool is going to run as root, and after the first day it is going to run with minimal supervision. You need to be sure its doing what you expect.

heroku.com