tektastic

Had an awesome time here for two days, listening to talks, hacking on some code, learning, networking, even managed to sign up for the UCSF gym and to take a swim. Very nice organization, excellent venue, and fantastic talks. Definitely coming back next year. For the price it's well worth it. Here are some highlights: Super useful resource for lookup up shell commands: http://shellhaters.heroku.com/posix Terminator plugin: start your dev environment as you like it. Gem install terminator http://github.com/rdy/fixture_builder Factory to Fixtures converter to speed up your tests. pprof profile Ruby interpreter. Rack-Profiler project, great profiling tool. Coffee Script - wrapper (ruby-esque) for javascript; rails 3.1 supports coffee script templates Machine Learning - great talk , and O'Reiley book , http://twitter.com/igrigorik minitest fastest testing framework, many mentions, very fast, supports RSpec and Test::Unit syntax Caching: using fr

Interesting statistics just came out on AlertSite blog post about performance and response time of various highly trafficked social networks. Unsurprisingly, Facebook is the fastest, and Twitter is the slowest. Facebook has so much more data to deal with, so much media, and so many more users, that it really is a shame for Twitter with it's 140 character data set to be in this unglorious last place. After continuous reports about migrating to Cassandra , Twitter still serves their tweets out of MemCaches that sit in front of MySQL . When those caches die, it takes a long time to refill them and the site yet again drops the very familiar Fail Whale. Perhaps Twitter's infrastructure group could use some new blood to work on scaling and up-time. I am guessing that adding experienced people who scaled Facebook, or other high traffic sites could really help in the long run. The problem is that hiring experienced contributors to work on this pain point may feel threatening to t

Our Rails3 (beta4) application had one route mapped in config/routes to a Sinatra app, by means of the following route: match '/foo', :to => EndPointApp, :as => :endpoint The route was being defined to run as a Sinatra Application require 'sinatra' class EndPointApp < Sinatra::Application post '/foo' do ... end end This was working mostly fine, but it was returning Set-Cookie header with the standard Rails sessions cookie, which in this case was preventing the client of this endpoint from successfully interpreting the result. As I could do nothing about the client side, I had to remove Set-Cookie from the headers, but only for this end-point and obviously not from the entire app. This proved to be somewhat more complicated than I had hoped, so let me share the solution here in hopes it might save someone else an hour or two. First, I ran "rake middleware" and observed the following Rack stack: use ActionDispatch::Static use Rack::Lo

I remember one of the early talks at the Canada On Rails in 2006 had a slide showing how many books one needs to read to be able to write web applications in Rails, versus Java. Of course Java side had about 10 books: Java SE, Java EE, Hibernate, Struts/Tiles/JSF, WebServices, Ant, Maven, Eclipse, JUnit, etc, etc. The Rails slide proudly showed the now hopelessly outdated "Agile Web Development With Ruby on Rails", 1st edition. Those were the times. Back then, during my work for Blurb.com myself and three other engineers managed to learn ruby, rails and build a fully functional e-commerce site in about 3 months. I was blown away by the productivity gains compared to Java, where months could be spent laying out the project, and creating all necessary infrastructure for builds, deployment, automated testing with or without the database, etc. Fast-forward to 2010. We are on a brink of Rails3 release, and oh boy, has the landscape changed since back then. I would argue

If you are just learning to use git, or you have been using it for a while without too much thinking, this introduction to Git principles provides a fantastic overview into the concepts behind git, using a very simple and natural examples. Do you need to switch to git from svn? My personal take on this is as follows: If you have several developers far away with bad internet connection, then YES. If you have more than several developers (say hundreds) then YES. If your developers often work on long multi-day features, where they want to commit often, but commits may result in instability of their branch, then YES. Git allows much easier branching than SVN. If you want to leverage GitHub's infrastructure for hosting your project privately or publicly, then YES. To balance this and not to appear as I am advocating everyone to switch, here is the reverse: If you have a small team who works locally and uses a local SVN server then NO. If your team does not need branching, or prefers