13 items tagged “ryan-tomayko”
2010
Zero-downtime Redis upgrade discussion. GitHub have a short window of scheduled downtime in order to upgrade their Redis server. I asked in their comments if they’d considered trying to run the upgrade with no downtime at all using Redis replication, and Ryan Tomayko has posted some interesting replies.
Ryan Tomayko on Github’s development process. In the comments—a fascinating insight in to how GitHub’s “developers work on whatever is most interesting to them” process manages to achieve really good results.
2009
Python is Unix. Jacob ports Ryan Tomayko’s simple prefork network server to Python.
I like Unicorn because it’s Unix. Ryan Tomayko analyses Unicorn, a new, pre-forking Ruby HTTP server that makes extensive use of Unix syscalls and idioms, and asks why dynamic language programmers don’t take advantage of these more often.
2008
Minimal. James Bennett follows Ryan Tomayko’s example and experiments with the minimalist school of blog design.
Administrative Debris. Ryan Tomayko explains his exceptionally clean redesign, inspired by Edward Tufte’s critique of the iPhone.
PrinceXML is extremely impressive. I had a poke at Prince (a commercial package for generating high quality PDFs from HTML, XML, CSS and SVG) a few weeks ago and was similarly impressed.
Full Page Zoom Is For Sissies. Ryan points out that sizing everything in ems, while neat, imposes a pretty hefty maintenance cost and is rapidly becoming unnecessary thanks to the page zoom feature in IE 7, Opera and Firefox 3.0.
I've never heard anyone from the REST camp claim that building distributed systems was "easy". [...] The WS-* folks have historically been obsessed with making things easy, usually for an imaginary business analyst who is nowhere near as technically adept as they. The REST folks, on the other hand, seem much more interested in keeping the entire stack simple, and for everyone involved.
2007
The promise [of J2EE] was that of infinite scalability based on tooling, which assumes that designing scalable systems is a general case problem. I now firmly believe that this is flawed reasoning. Frameworks don't solve scalability problems, design solves scalability problems.
Rails and Scaling with Multiple Databases. Ryan Tomayko explains how his team spreads a high traffic Rails application across five separate PostgreSQL databases by giving each client their own schema—similar to how WordPress MU scales.
The server understood the request, but is refusing to fulfill it because you're coming from digg.com and the proprieter of this system is frankly terrified by you people.
2005
IBM poop heads say LAMP users need to “grow up”. Ryan blows away a ton of the myths surrounding LAMP.
Nope. We call bullshit. After wasting years of our lives trying to implement physical three tier architectures that "scale" and failing miserably time after time, we're going with something that actually works.