praktikantenblog

Because nobody mentioned them here before,

there is a long list of very old articles on Ruby and Rails at O'Reilly.

Though they are old, they are kind of worth a look for newbies:

 

The long list

Rolling with Ruby on Rails, January 20, 2005

Rolling with Ruby on Rails, Part 2, March 3, 2005

Rolling with Ruby on Rails Revisited, December 14, 2006

Rolling with Ruby on Rails Revisited, Part 2, January 5, 2007

Cookin' With Ruby on Rails, May 17, 2007

Cookin' with Ruby on Rails - Designing for Testability, June 28, 2007

Cookin' with Ruby on Rails - More Designing for Testability, July 28, 2007

Understanding ActiveRecord: A Gentle Introduction to the Heart of Rails (Part 1), April 19, 2007

Understanding ActiveRecord: A Gentle Introduction to the Heart of Rails (Part 2), May 10, 2007

Rails Testing: Not Just for the Paranoid, June 7, 2007

Ruby on Rails Meets Eclipse, April 26, 2007 (BAH!, use emacs!)

Bringing Ruby on Rails with FastCGI into Mac OS X Server, March 29, 2007 (sounds horrible)

Hacking Asterisk and Rails with RAGI, December 19, 2005 (interesting!)

What Is Ruby on Rails, October 13, 2005

Ruby on Rails: An Interview with David Heinemeier Hansson, August 30, 2005

Ajax on Rails, June 9, 2005

Behavior Driven Development Using Ruby (Part 1), August 9, 2007

Behavior Driven Development Using Ruby (Part 2), August 30, 2007

Behavior Driven Development Using Ruby (Part 3), September 20, 2007

How to Build Simple Console Apps with Ruby and ActiveRecord, June 21, 2007

Replacing AppleScript with Ruby, February 27, 2007

 

Ruby the Rival, November 16, 2005 ("What's wrong with Java")

Extending Ruby with C, November 18, 2004

An Introduction to RubyCocoa, Part 1, October 5, 2004

An Introduction to RubyCocoa, Part 2, October 12, 2004

Exploring E4X with Ruby, August 12, 2004

Ruby/Tk Primer: Creating a cron GUI Interface with Ruby/Tk, June 25, 2004

Ruby/Tk Primer, Part 2, July 23, 2004

 

Ruby/Tk Primer, Part 3, July 27, 2004

Ruby's Present and Future, December 18, 2003

Building Unix Tools with Ruby, September 18, 2003

Read iCal Data with Ruby, September 3, 2003

An Interview with the Creator of Ruby, November 29, 2001 (Matz)

An Introduction to Ruby, October 25, 2001

Twitter did discuss it's scalability quite publically, and i try to get an more exact overvie about what happend in what chronological order.
For now i want to start only with some collection of links, and later work on summarizing twitters efforts and struggles with Scalability of their original Ruby on Rails Project.

Obviously thats not a simple quesion if rails does scale, or not - and luckily all those debates came up with more and more clear statements, where problems with rails might appear, and how they can be solved.
Finally i'd like to map particular problems with potential (and already tested) solutions. I think it's also worth having a look at the developments of Rails 3, where the rails core team faced many of these problems mentioned together with rails and scalability.

 

Help in reproccessing these activities: very welcome :)

General Blog Articles and Background Information to Twitter and Scalability

* http://www.radicalbehavior.com/5-question-interview-with-twitter-developer-alex-payne/ (original interview with alex payne (twitter developer) complaining about rails scalability.

* http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster (with updates )
* http://www.broschart.net/twitter-on-rails/ (german blog)

* http://blog.evanweaver.com/articles/2009/03/13/qcon-presentation/ (improving running components on twitter)

 

Scala (for the backend)

* http://www.artima.com/scalazine/articles/twitter_on_scala.html (interview with twitter developers)
* http://www.scala-lang.org/

Twitter Developers Blogs

* http://blog.evanweaver.com/  (Manager of Infrastructure Team - his blog has the subtitle 'scaling rails')
* http://al3x.net/ (Twitter Api)

More wanted.. please help ;) see you soon!

You all know Rack, don't you?

Well if you don't, it boils down to this:

class HelloRack

def call(env)
  [200, { 'Content-Type' => 'text/html' }, ['<h1>', 'Hello World', '</h1>']]
end

end

That is a basic Rack application. It is passed the environment, which feels a lot like CGI 2.0, checkout the spec. To get it up and running, the easiest thing to do is using a rackup recipe:

run HelloRack.new

Put this in a file named "config.ru", fire up the app with "rackup" and hit http://localhost:9292/ with your browser.

That is pretty simple. Now the real power of rack comes with so called Middleware:

class GoodbyeMiddleware

def initialize(app)
  @app = app
end

def call(env)
  if env['PATH_INFO'] == '/bye'
    [200, { 'Content-Type' => 'text/html' }, ['<h1>', 'Goodbye Cruel World', '</h1>']]
  else
    @app.call
  end
end

end

To use it, modify your config.ru look like this:

use GoodbyeMiddleware run HelloRack.new

Restart rackup (CTRL+C to quit, then "rackup" again), then visit http://localhost:9292/ to see the same thing as before. Browsing to http://localhost:9292/bye however, will show you something else.

I hope you got it, if not, read any of the great tutorials and articles about rack.

This is very interesting! But, what do you actually do with it?

Essentially Rack is just a tiny interface between all kinds of ruby-aware webservers and ruby applications. The goal is similar to that of CGI, FastCGI, etc, etc. just... the "Ruby Way"(TM). And we all love ruby, don't we?

Now there are a whole number of things you can do with rack: If you are a Rails developer you can directly incorporate any middleware. Also, there is Rails Metal, which seems to be pretty useless, but nevertheless might be able to give your app a performance hit. If you're riding on Sinatra here are some slides for you.

But if you're (like I am) pretty much frustrated by the drawbacks (regarding performance, extensibility, debuggability...) and limitations (also (mistakenly) known as conventions) existing frameworks give you or just want to really fucking decide for yourself what your framework does and what it doesn't, then Rack can be a great way to roll your own. You focus only on what the framework does, the rest is done by rack.

And after all there are lots of ready-to-use middlewares out there that provide anything you need, right?

Well, so I thought!

If you take a look at the List of Middleware or just do a quick search on github, you'll find tons of apps & middlewares that do just about anything you might ever have thought of doing in a framework.

So, what do we want to do?

• Routing

  There are a lot of solutions for routing:
  

  • Rack Router Well, that looks very nice. It has a simple DSL and doesn't involve too much magic. Also, it looks like a middleware. But if you take a closer look, you'll see it actually isn't. Had to fix it.
  • Usher Which I haven't tried yet, but will, for a followup article.
• Authentication
  • Rack::OpenID Is really nice but refuses to work with passenger, which renders it unusable for production. Hint: mod_auth_openid is a great alternative!
  • Warden Is a powerful authentication framework, however it's OpenID Plugin is based on Rack::OpenID, hence suffers from the same drawbacks.
• Controller
  • rackable Is a simple module to ease the writing of RESTful applications. However, I felt the urge to patch it as well to suit my needs. (The author has a great excuse though: "...I thought it was useless...")

There is a lot more I could write about, but my time is rather limited and I want to save some stuff for a follow up.

Just a quick conclusion:

• Rack rocks!
• Don't believe all that is written in the description of the libs you use.
• Rack apps are easy to write, hence there's a lot of shit out there.
• Prepare to fork & patch anything you use.
• RTFC (read the fucking code)!

Lately I’ve been playing with a wide variety of different approaches to build convenient, desktop-like UIs using JavaScript, CSS & HTML only. Coming from the rails world my first steps where very much built upon the idea that code generation is going to save me a lot of time and complex helper methods soon were born. That seemed to work out pretty well. After only a few days I had working ajax trees, data grids with multiple selection, context menus, table filtering, searching and other nifty features. All with ~350 lines of code. There was only one problem: it was ruby code. How does one debug bugs in the JavaScript when the code itself is never written, but dynamically generated with all the data mixed in already?

I had to face it: code generation – at least my awkward ways of doing it – sucks. So, what else is out there? Flash of course, but no! Let me take that back. Yes, there’s JavaScript. I’ve heard about that. Doesn’t it have something to do with this peachy little peace of code in that “prototype.js” file? So, I had a chat with google and they came up with a few options: YUI, Closure and jQuery(UI). All seemed promising, but after a bit of playing around I decided to stick with jQuery for various reasons, including the fact that it wasn’t labeled by some big data mining conspiracy. Also a lot of smart people have come up with a lot of smart plugins (within the ocean of crap that’s undoubtably out there as well). Having said all that, I’d like to share my mental notes on what works, what is best for which goals and what one better doesn’t even try.

Going outside in, first comes the layout. Layouts are tricky. Masochistic as web developers seem to be, their main concept of art is to use a language designed for text markup plus some questionable feature called hyperlinking to reinvent the wheel when attempting to (more or less) mimic the style of the applications that “text” is eventually rendered in. There are a few different techniques, some CSS based (g r i d s), some JS based. As I was going to build a JS-driven UI anyway and also because of bad experience with the former (people tend to do pretty weird shit with CSS grids that make them virtually unmaintainable) I went with the latter. Having chosen a JS Framework already I thought my choice was already set, but I was mistaken.

mb.containerPlus is doing overlays optionally with the conventional hide / maximize / close controls, that may form a solid base for apps that require many floating windows. I fell for the futuristic Apple effect of jQueryTools, which is a pretty nice collection of tools. Be careful though when downloading it to deselect the tabs feature, which looks pretty nice at first, but fails miserably when trying to add tabs dynamically (for which the tabs plugin from stilbuero is much more suitable). The choice of the right layout solution was more challenging, but long story short: I ended up with UI.Layout which uses a border-layout approach and is capable of really complex, nested layouts which work surprisingly well with other jQuery magic, such as the forementioned tabs.

More later.

Stumbling over http://rubygame.org/ just after if finished my last blog-article, i first thought - oh know, is it another game to steal my precious time? (okay okay, rubywarrior is about precious ruby, not about my precious time, but…)

But, phew, it’s declaring itself as a library for writing games in ruby. Actually i don’t know if it focuses on any particular kind of games, but it surly is worth a look - maybe not only for writing games. From surfing through its rdoc i found a lot of methods like RubyGame::Events::MouseMoved or RubyGame::Events::KeyPressed.

If someone had a closer look, i’d love to be updated as well. I mean, there is useful stuff too that you can write as a game :)

Whoo, i actually did spent some hours this weekend playing rubywarrior, a game allowing you to write you’re own player-bot and send it through some kind of dungeons with sludges, wizards and archers longing to kill you.

Though i was doing what i do in my daily work - lurking around in my emacs, writing code, it felt quite a lot like this gaming spirit that i remember from the days when i used to play computers. Even some - usually when playing games quite reasonably - fear sneaked into my mind, telling me i could waste my time.

But actually I think, though i didn’t learn so much new ways of doing things, i think i learned a lot by simply combining ‘playing’ with ‘coding’, which actually is quite similar in its essence. But playing rubywarrior is less playing against my issue-tracker or a clients agenda, but more like playing against… erm, archers and sludges… well, okay, that could be considered quite similar as well… Anyhow - it has been a welcome change.

I will love to publish my - honestly clearly not completely well structured player, but not before some other players are done, allowing us to compare and learn from each other.

Sorry people, i don’t want to encourage you wasting your time - but probably it’s really not a waste. At least not if you play in your leisure :)

Oh, well - and i discovered this fork of rubywarrior - originally written by Ryan Bates, which we all do already now, e.g. from Railscasts.com - anyhow, looking at the forks github-page makes me belive there are new levels and functionality added. The voice in my head telling me not to waste my time, is still arguing. Anyhow, the fork can be found here.

Wish you a lot of fun!

Yeah, it works!

The Ruby ri tool is used to view the Ruby documentation off-line. Open a command window and invoke ri followed by the name of a Ruby class, module or method. ri will display documentation for you. You may specify a method name without a qualifying class or module name, but this will just show you a list of all methods by that name (unless the method is unique). Normally, you can separate a class or module name from a method name with a period. If a class defines a class method and an instance method by the same name, you must instead use :: to refer to a class method or # to refer to the instance method. Here are some example invocations of ri:

ri Array
ri Array.sort
ri Hash#each
ri Math::sqrt

via here

But I didn’t found out how to let it work with rails, ie Action Pack

Today i was once again annoyed, by having tests calling steps like...

Then I should see "Thank you for your Message"

This neccessarly causes the step to fail, whenever the locales for this message are changed, and thats definitely not what we want.

Well, so i thought about it for a minute, came up with the logical conclusion of modifying step definitions to process the localization, was to lazy to test it out, complained in my favourite irc channel, and someone sent me this link: http://www.railway.at/articles/2009/09/12/using-cucumber-to-test-a-multilingual-app/

As it was exactly what i wanted, i added those modified steps to a file i called localized_steps.rb.

Two problems coming up:

1. cucumber did not know wether to use the original step from web_steps.rb or the ones in localized_steps.rb

2. i did not yet change all steps to use localized strings, to they would all fail, and i'd prefer doing it step by step, as there is not the time for modifying all the tests now.

Solution: I explicitly choose wethere i use the step with localization or with a plain string.

    # localized_steps.rb


    When /^I press localized "([^\"]*)"$/ do |key|

      click_button(I18n.t(key))

    end

    

    When /^(?:|I )follow localized "([^\"]*)"$/ do |key|

      click_link(I18n.t(key))

    end

    

    When /^(?:|I )follow localized "([^\"]*)" within "([^\"]*)"$/ do |key, parent|

      click_link_within(parent, I18n.t(key))

    end

    

    Then /^I should see localized "([^\"]*)"$/ do |key|

      response.should contain(I18n.t(key))

    end