Piotr Sarnacki

Ruby debug

2012-03-25T00:00:00-07:00

Debugger to bardzo ciekawe narzędzie. Bywa niezwykle pomocny przy różnego rodzaju problemach ciężkich do rozwiązania manualnie, ale stosunkowo niewiele osób go używa. I nawet jeżeli ktoś wie o jego istnieniu i wie jak z niego korzystać, to bez takiego nawyku, wiedza ta na niewiele się zdaje. Wyobraźmy sobie taką sytuację. Próbuję poprawić buga znalezionego w kodzie, więc piszę padający test i zaczynam wprowadzanie poprawki. Nie widzę żadnej anomalii patrząc w kod, więc zaczynam przyglądać mu się bliżej. I wbrew temu co mogą niektórzy powiedzieć, ten kod wcale nie musi być skomplikowany. Ruby jest językiem dynamicznie typowanym, więc bardzo często błędy w kodzie biorą się stąd, że dostajemy nie to co chcieliśmy. W takim wypadku, nawet przy bardzo prostym kodzie, możemy siedzieć nad rozwiązaniem dłuższą chwilę, bo umysł podświadomie omija problematyczne miejsce zakładając, że dostajemy oczekiwaną wartość. Wracając do poprawki, zaczynam wstawiać w różne miejsca w kodzie metody, które wyświetlą dane pomocne przy debugowaniu, najczęściej robię to w taki sposób:

def method_with_bug(value)

p [:value, value]

# ....
end

Dzięki użyciu metody p wyświetlona wartość będzie jeszcze potraktowana inspect. Jeżeli kilka takich linijek załatwi sprawę, to jesteśmy w domu, ale jeżeli nie? Najprawdopodobniej po każdym kolejnym dodanym p trzeba będzie uruchomić jeszcze raz test i być może okaże się, że będziemy musieli sprawdzić kilkanaście różnych rzeczy.

Debugger ma nad tego typu podejściem dość dużą przewagę - kiedy idziemy przez kod wykonując kolejne kroki, łatwiej jest zauważyć, że coś jest nie tak. Wyświetlając część danych na ekran, nie wiemy tak naprawdę gdzie siedzi błąd, więc trochę strzelamy. I nie chcę przez to powiedzieć, że przy każdym błędzie opłaca się odpalać debuggera, Warto po prostu mieć nawyk jego używania. Ja z reguły zaczynam od wyświetlenia kilku wartości, które są najbardziej podejrzane i mogą mi pokazać gdzie leży błąd i jeżeli to nic nie daje, to używam debuggera. Nawyk jest tutaj bardzo ważny, bo bez niego najczęściej skończy się na dodawaniu kolejnych puts, za każdym razem poprzedzonych myślą: "Ok, już wiem o co chodzi, tylko jeszcze wyświetlę ten obiekt, nie ma sensu włączać ruby-debug".

Jeżeli chodzi o przeciwników debuggera, to jednym z głównych zarzutów jest: "Używając debuggera można uniknąć dyscypliny, która powinna towarzyszyć nam przy programowaniu i tym samym ominąć kroki, które bez debuggera trzeba by wykonać: pisanie testów, refactoring, dodanie dokumentacji". Zgadzam się z tym, że w przypadku kiedy kod jest marnej jakości, nie ma do niego testów i dokumentacji, to użycie debuggera bez poprawy sytuacji jest błędem. Problem w tym, że sytuacja nie zawsze tak wygląda i debugger wcale nie oznacza porzucenia testów (o czym będzie jeszcze za chwilę). Jeżeli chodzi o refaktoryzację, to też jestem zwolennikiem jak najczęstszego jej stosowania, ale to nie zawsze jest możliwe. Czasami ze względu na czas, czasami ze względu na dużą ilość kodu, czasami ze względu na małą wiedzę o kodzie (np. stara aplikacja, którą musimy utrzymywać). Ale żeby nie przedłużać zostawię tego typu rozważania i przejdę do sedna.

Do czegu używam debuggera?

Użycie debuggera wygląda z reguły w ten sposób, że w momencie kiedy chcemy poprawić jakiś problem w aplikacji, to wstawiamy tam debugger, odpalamy aplikację (albo w przypadku aplikacji np. w railsach odświeżamy stronę w przeglądarce) i sprawdzamy co się dzieje. Ja prawie nigdy nie robię tego w ten sposób. Najczęściej używam debuggera przy okazji uruchamiania testów. Po znalezieniu problemu piszę padający test i wtedy jeżeli mam problem z poprawieniem kodu, uciekam się do użycia debuggera.

Kolejny dość ciekawy przypadek, przy którym może się przydać debugger, to sprawdzenie co właściwie robi jakaś metoda z biblioteki, której używamy. Czasami kod zewnętrznych bibliotek nie jest zbyt dobry i wtedy szybko kapituluję, ale bardzo często już na samym początku sprawdzane są różnego rodzaju opcje, co daje dość dużą wiedzę o tym co można do niej przekazać. Jest to też bardzo przydatne przy rozszerzaniu jakiegoś API. Railsy 3 mają na przykład bardzo fajne API w kontrolerach i jeżeli wiemy co tam się dzieje, to można stosunkowo łatwo rozszerzyć dany kontroler. Przydaje się więc możliwość prześledzenia co właściwie dzieje się np. po wykonaniu metody render

Ostatnią rzeczą, przy której często używam debuggera, jest prototypowanie i wszelkiego rodzaju "szybkie" skrypty. Przypuśćmy na przykład, że chcemy sparsować jakąś stronę w nokogiri i wyciągnąć z niej jakieś informacje. Najczęściej bardzo przydaje się przy takich zadaniach interaktywna konsola, w której możemy wypróbować wyciąganie różnych elementów. Problem w tym, że jeżeli zaczniemy od irba, to musimy tam przekleić część używanego skryptu, który otwiera stronę, tworzy dokument nokogiri i ewentualnie inne kawałki, które są nam potrzebne. Z kolei metoda debugowania polegająca na wyświetlaniu wszystkiego na ekran jest dość uciążliwa, szczególnie po dwudziestym wykonaniu tego samego skryptu. Debugger łączy zalety obu podejść. Możemy skorzystać z przygotowanego kodu i zacząć w miejscu, w którym wszystko jest już ustawione i w tym samym czasie użyć interaktywnej konsoli.

Jak używać debuggera?

Na początku musimy debugger załadować, tzn. dodajć linijkę require 'ruby-debug' gdzieś przed miejscem, które chcemy sprawdzić. Następnie w dowolnym miejscu w kodzie możemy wstawić metodę debugger. Po uruchomieniu programu, w momencie kiedy interpreter dojdzie do tego miejsca, uruchomiona zostanie konsola, w której możemy sprawdzać aktualny stan procesu i poruszać się wykonując kolejne linijki kodu.

Przed rozpoczęciem pracy polecam stworzyć plik ~/.rdebugrc, w którym można umieścić domyślny config, ja używam:

set autolist # automatyczne wyświetlenie kodu po każdej komendzie
set autoeval # automatyczne wykonanie wpisanego kodu rubiego,
             # bez tego można używać tylko metody `p` i jako
             # argument podawać kod rubiego

Jeżeli używasz rubiego w wersji 1.9.3, to na końcu tego posta są instrukcje uruchomić ruby-debug pod tą wersją.

Najczęściej używane komendy

Komendy mają z reguły skrócone wersje, dlatego będę tutaj używał wersji skróconych, a rozszerzenie podawał w nawiasie kwadratowym, np. n[ext]. Jeżeli dana komenda przyjmuje jakieś argumenty, to będą one umieszczone po nazwie metody, nawias kwadratowy oznacza, że są opcjonalne.

n[ext] — wykonanie bieżącej linii przechodząc do następnej, bez wchodzenia głębiej
s[tep] — wejście w metodę znajdującą się w bieżącej linii. Nie jest to zawsze możliwe, gdyż nie możemy zbadać wnętrza metod biblioteki standardowej napisanych w C.
c[continue] [nnn] — wznów wykonywanie programu aż do jego końca, napotkania breakpointa albo dojścia do linii nnn
b[reak] — ustawienie breakpointa (tzn. punktu, w którym wykonanie programu zostanie przerwane po wykonaniu instrukcji continue), break może również przyjmować różne argumenty:
- b[reak] [file:]line [if expr] — możemy jako argument podać linię, w której ma się ustawić breakpoint, domyślnie dotyczy to aktualnie wykonywanego pliku, ale można też użyć innego, np.: break other_file.rb:12. Można również podać opcjonalny warunek, np. break 12 if i == 1
- b[reak] class(.|#)method [if expr] — zatrzymanie na wykonaniu wybranej metody na wybranej klasie (wtedy używamy kropki, np. Thread.current) lub instancji (wtedy używamy #, np. Foo#foo)
info — wyświetla różnego rodzaju informacje, najczęściej używane jest do wyświetlania breakpointów: info b
d[elete][ nnn ] — usuwa wskazany breakpoint (jeżeli jest podany numer nnn) lub wszystkie jeżeli wywołane bez żadnych argumentów
backtrace — nazwa mówi sama za siebie ;)

Pełna lista komend jest dostępna po wykonaniu help, dokładniejszy opis każdej metody jest dostępny po wywołaniu help nazwa-instrukcji

To by było na tyle jeżeli chodzi o teorię, teraz przejdźmy do praktyki. Ze względu na to, że opisywanie tego jest lekko uciążliwe i pewnie średnio czytelne, wreszcie miałem okazję, żeby nagrać screencasta. Przejdę w nim przez kilka podstawowych przypadków, które napotkamy przy debugowaniu. Jeżeli będę miał trochę wolnego czasu, to dorzucę jeszcze drugą część, w której pokażę kilka scenariuszy wymienionych powyżej.

Ruby 1.9.3

Niestety gemy, które są wymagane do działania ruby-debug nie są cały czas publicznie wypuszczone, więc nie możemy ich prosto wylistować w Gemfile. Dlatego hostuję mały serwer rubygems, na którym je umieściłem. Jeżeli używasz rubiego w wersji 1.9.3, to używając bundlera można dopisać do Gemfile taki kod:

# source dla rubygems też powinno zostać
source 'http://gems.developers.stoliczku.pl'

group :development, :test do
  gem 'linecache19', '0.5.13'
  gem 'ruby-debug-base19', '0.11.26'
  gem 'ruby-debug19', :require => 'ruby-debug'
end

Dodakowo, jeżeli używamy RVM, to trzeba podać bundlerowi ścieżkę do źródeł:

bundle config build.linecache19 --with-ruby-include="${MY_RUBY_HOME/rubies/src}"
bundle config build.ruby-debug-base19 --with-ruby-include="${MY_RUBY_HOME/rubies/src}"

Trochę tego niestety jest, ale po wykonaniu tych kroków wszystko działa bardzo dobrze.

Mountable apps tutorial

2010-12-21T00:00:00-08:00

I finished my work on RubySOC a few months ago and I wanted to write this post quickly after that, but life, as usual, verified my plans. Unfortunately, attending a few great conferences left me with no money, so I needed some time of hard work to pay all the debts (nevertheless, all those trips were really worth it, especially rubyconf – I really felt in love with New Orleans!). I want to apologize to everyone who really waited for that, especially those who heard that this blog post will be written “very soon” ;) Now… let’s cut the emo talk and get to serious business!

I’ll start with a short introduction for those, who aren’t familiar with the concept of mountable apps in Rails 3 (edge) yet. The goal for implementing mountable apps was to allow running 2 rails applications in one process. Unfortunately, that goal was not achieved and we settled on a simpler approach. If you want to create a mountable application, you can use rails engines, which will be much more powerful in Rails 3.1. For the list of major changes, please check my last post on that topic.

Although almost all of the changes made to engines were usable shortly after summer, the process of setting up a new engine, suitable for mounting, was really rough. Of course, there is a great gem, enginex, by José, but at that time it only generated bare structure for any kind of rails extension and there were no things specific to mountable apps (as mountable apps haven’t existed during the time of writing enginex). That’s why I ported enginex to rails, with some changes that were needed to merge it to the core, to make that task simpler.

Let’s start with the tutorial. First things first. As the new APIs work only on rails edge, you need to get rails from github:

git clone https://github.com/rails/rails.git
cd rails
bundle install

To generate any rails extension in rails 3.1 you can use rails plugin new command. It generates a directory with lib directory, gemspec, tests and dummy application for testing. There are 2 really important things here:

gemspec is automatically generated, unless you use --skip-gemspec option – I hope that this will help to move more people to gem plugins
dummy application, which by default lives in test/dummy – this is standard rails application that you can test your plugin

To generate a mountable engine, we can use:

bundle exec ./bin/rails plugin new ../blog --edge --mountable
cd ../blog
bundle install

We need to add --dev or --edge option to ensure that Gemfile will point to rails edge version, either from local clone or github. I used edge here, cause it’s better for most of you – you can get newest rails version with simple bundle update. Mountable option will add files that will come in handy for developing a mountable engine, such as: integration tests, Blog::ApplicationController, config/routes.rb and so on.

Let’s see how the key files look like.

Probably the most important file is lib/blog/engine.rb, which keeps definition of the engine:

module Blog
  class Engine < Rails::Engine
    isolate_namespace Blog
  end
end

The thing that differs from what we could see in Rails 3.0 engine, is isolate_namespace which makes engine isolated from host application. If you don’t remember how it works exactly, please check the documentation or my last post.

Next important thing is config/routes.rb file:

Blog::Engine.routes.draw do
end

These are empty routes, but as you can see, they belong to the engine, not to the host application.

The last thing that you may not be familiar with is the dummy application located in test/dummy. This is a standard rails application that will be used to test engine, both with automated tests and manually during development. The nice thing about the new plugin generator is that with --mountable option, it automatically mounts engine in test/dummy/config/routes.rb

Rails.application.routes.draw do
  mount Blog::Engine => "/blog"
end

Ok, let’s write some code! Or… actually don’t write code, I’m too lazy, I’m gonna use scaffold generator:

rails g scaffold post title:string body:text

While the scaffold should behave exactly the same as the one generated in regular app, there are some differences. Notice that migration for that is called create_blog_posts instead of create_posts. Also almost all of the files are places in blog/ subdirectory. When you open app/models/blog/post.rb, you will see:

module Blog
  class Post < ActiveRecord::Base
  end
end

Everything is namespaced for a good reason: we want to avoid conflicts between engine and host application.

Ok, now we can migrate our database (sqlite3 by default):

rake db:migrate

Engine’s Rakefile includes all the tasks that are needed to manage database. Migrations are run from both engine’s and dummy’s application directories to make development and testing easier. Finally, it’s time to check it!

rails s

Now point your browser to http://localhost:3000/blog/posts. You should see the standard rails scaffold working – the only difference is that it’s namespaced with /blog path. It was easy, wasn’t it?

As you can see, creating a mountable application using engines is pretty straightforward. I haven’t shown any way to better integrate a mountable application with the host application (e.g. using User model from the host application or adding some configuration options to the engine). It’s on purpose ;) I haven’t got time to develop anything good yet. You can start playing with it yourself! Be sure to let me know if you come up with some good patterns.

Lightweight controllers with rails 3

2010-12-12T00:00:00-08:00

Some time ago I showed you, how easily you can reuse rails 3 modules. Today I want to present lightweight controllers, which is also really really easy in rails 3.

Why would you want controller to be more lightweight? Speed of course. We all know that rails can’t scale and ruby is slow, let’s make it a little bit faster ;)

Let’s start with getting familiar with new controller architecture. The base for all the controllers in rails is AbstractController::Base. If you want to build controllers without support for handling requests, you can start with that as a base. What if we want to create something looking more like standard rails controllers? We can check how does implementation of ActionController::Base look like: ActionController::Base

As you can see, it inherits from ActionController::Metal and includes bunch of modules. Looks like Metal will be a good start for our purpose. Let’s say that we want to render a simple JSON response generated from a model:

# app/controllers/api_controller.rb
class ApiController < ActionController::Metal
  include ActionController::Rendering

  def index
    render :text => "Good morning!"
  end
end

As you can see I created controller that inherits from ActionController::Metal and included ActionController::Rendering. To render simple JSON response, we will not need anything more.

How fast is it comparing to ActionController::Base? For comparison I’ve created controller with exactly the same action:

# app/controllers/home_controller.rb
class HomeController < ActionController::Base
  def index
    render :text => "Good morning!"
  end
end

I’ve done a few benchmarks, but don’t take it too seriously, these are not scientific, I just wanted to show you how approximately can it differ. Here are ab results: https://gist.github.com/738168. As you can see, ActionController::Metal is almost 40% faster. This can of course vary, depending on version of ruby, concurrency (I used 1) and other factors, but clearly it can give you nice boost.

Of course trained eye can easily spot an issue here. Do you think that someone will actually return a response like that? Hardcoded string?Srsly? I guess not. But there certainly are situations, when you can profit from using that kind of controllers. If all you need to do, is to return text response, that most of the time is fetched from cache and is hit frequently, this should work pretty well. Some of you may also ask, ~~why can’t we use Rails Metal, which is available for quite some time now~~ rack middleware (rails metal was removed in rails 3). We could, but then we loose possibility to use router and include other modules to ActionController::Metal (like ActionController::Helpers or other useful things).

I hope that this post will help you to experiment with new Rails 3 cool features! If you want more of that stuff, in better form and with much better explanation and depth, I highly recommend reading José Valim’s book Crafting Rails Applications!

Mountable engines - RSoC Wrap Up

2010-09-14T00:00:00-07:00

As some of you probably know, during the summer I was working on “Rails mountable applications” project thanks to Ruby Summer of Code. It was great experience, I learned a lot new things and I hope that I delivered something useful for the community. I tweeted that the other day, but I must emphasize: it would not be possible without great support from my mentors: Carl Lerche, Yehuda Katz and José Valim! They helped me a lot with both ideas and implementation. The biggest internet hug should go to José, who spent enormous amount of his time on discussions, reviewing my commits and helping me to set the goals. I also want to thank all the sponsors and people that helped to organize Ruby Summer of Code.

Getting back to my work. My main task was to extend capabilities of rails engines. Although at first I wanted to get straight to mountable full rails applications, after discussions with Carl and José, I knew that starting with the smaller target will be more sane way to go. The biggest problem with implementing mountable applications (that is running more than one rails application in same process) is configuration and application initialization in general. Right now config values are shared between all the railties classes, because they’re kept in class variables. The other problem with mountable apps is that they’re pretty new concept in rails community and we will need some time to settle standards. With those problems in mind, it is much better to test the concept with engines and implement truly mountable applications later, based on results and feedback. Right now, engines are almost as powerful as applications. The main difference is that engine can’t be run without an application. The best thing about such strategy is that API for using more than one application is already here, so if it is needed, converting engine to application will be as easy as changing a bunch of configuration files.

In that post, I would like to briefly describe my changes.

Extending engines

First thing needed to allow build entire applications on engines, was to add some of the application’s features to engines. That’s why engines got:

its own middleware stack
routes
plugins support
config/environment.rb

With all the capabilities that engines had before, engine is now almost as powerful as application.

Mounting engine

Since engine is now a rack app, you can simply mount it in your application’s routes:

Rails.application.routes.draw do
  mount Blog::Engine => "/blog"
end

This will mount Blog::Engine at /blog path. There are 2 huge benefits of such method:

you can change the engine’s path, which was much harder before
you can use all of the routes magic

Want to mount your engine with dynamic scope? No problem:

scope "/:username", :username => "default" do
  mount Blog::Engine => "/blog"
end

You can also use devise to force authentication for the engine:

authenticate :admin do
  mount Tolk::Engine => "/tolk"
end

It’s easy, isn’t it?

Cross applications routes API

Since you can mount engine with its own router inside application, there is a possibility of having more than one router in your app. To handle all the routers easily, there are new helpers providing access for each router. Application’s router is always available as main_app. That said, you can call any application route from engine just like that:

main_app.logout_path
main_app.root_path

Helpers for other routers are available after mounting an engine:

mount Blog::Engine => "/blog"

# default helper for such engine is "blog":
blog.posts_path
blog.root_path

If you need to change the helper name, just pass the :as attribute:

mount Blog::Engine => "/blog", :as => "my_blog"

# now helper is called my_blog:
my_blog.posts_path
my_blog.root_path

You can also use those helpers in polymorphic url (which is used, among the other places, in form_for):

polymorphic_url([blog, @post])
form_for([blog, @post])

Note that you have to explicitly add those helpers to polymorphic_url only when you need to call an engine route from your application or from another engine.

Namespacing

Having more than one source of controllers, models and helpers can cause conflicts. Imagine you have Post model in your application and you would like to install blog engine having model with the same name. To avoid that, you can put your engine inside the namespace. Although it will help you with conflicts, it’s not enough level of separation for some engines. There are basically two possible scenarios here. One of them is shared engine, when you want to share helpers between engine and application. A good example of such engine is Devise. The other use case is when you want to make isolated engine, which will not likely share anything. It could be an engine that provides tools for application like Tolk or the other app like blog or CMS.

Engines are shared by default, therefore you must explicitly mark it as isolated with isolate_namespace method:

module Blog
  class Engine < ::Rails::Engine
    isolate_namespace Blog
  end
end

With such engine definition, only the engine’s helpers and routes will be included inside engine’s controllers and views.

Migrations

If you are one of NoSQL (or rather schema less) database users, you can probably skip that point. In other cases you will probably need migrations. We decided that the easiest way to handle engine’s migrations is to copy them to application’s db/migrate directory and change their timestamps for not breaking the migrations timeline. It can be done by simply calling rake task:

rake railties:copy_migrations
# or to copy only selected engines
rake railties:copy_migrations RAILTIES=foo,bar

The nice side effect of copying migrations is that you can easily review them before applying.

Assets

The chances are that you will have some assets in your engine’s public directory. The default way of serving assets in development mode in Rails is ActionDispatch::Static middleware. If you have mounted any engine, it will automagically serve their assets. In production you have 2 options:

stay with ActionDispatch::Static by turning it on with: config.serve_static_assets = true in your environment.rb
create symlinks to engine’s public directories

You can automatically create symlinks with a rake task:

rake ralties:create_symlinks

If you want to change the default asset path, you can set it in Engine definition:

module Blog
  class Engine < ::Rails::Engine
    config.asset_path = "/my_blog_assets%s" # note %s at the end
  end
end

This will change both ActionDispatch::Static’s and create_symlinks rake behavior.

Why does it matter?

Although engines are available since Rails 2.3 and even ealier as a plugin, building isolated applications using them can be hard. With new API, building entire apps (like forum, blog or CMS) that can be reused, will be much easier. But hey, big components are evil, right? I would say that it depends on your needs. There is huge space for engines as tools to help develop your application. If you use i18n, there is Tolk. Most of applications could probably benefit from Rails Admin (it’s also one of the RSoC projects). Also the new Carlhuda’s ;-) work on Rails 3.1 assets is based on engines.

Another topic are applications. You can argue that making flexible application that would suit needs of many developers will be hard and inefficient… and you are probably right. However there are many situations when you need to quickly add some CMS or small forum to your application and you pretty much do not care about features. It’s not your core product, you just need something simple. Of course you can always do it by yourself, but what are the benefits? If you’re not trying to revolutionize CMS systems and just want an easy way to add a few articles to your site, you can use something generic. If it’s really needed, you can always write your own better suited engine later on and replace the previous one.

What’s next?

My work is already merged to rails master and most of the things are finished, but there are still some places that need more work. If you have any suggestions on engines, feel free to comment, add a ticket on lighthouse or send a pull request with changes.

There is also need for engines creators that will battle test the new API and new concepts. If you have any questions feel free to contact me on twitter, github or by email. I will also prepare a guide shortly, so stay tuned!

Mountable engines

2010-09-09T00:00:00-07:00

Jak prawdopodobnie niektórzy wiedzą, podczas wakacji pracowałem nad projektem “Rails mountable apps” w ramach Ruby Summer of Code. Projekt zakładał umożliwienie montowania aplikacji napisanych w Railsach w innych aplikacjach Railsowych. W tym momencie nie jest to jeszcze niestety możliwe, ale istnieją już solidne podwaliny w postaci “mountable engines”. Wspólnie z osobami z rails core team zdecydowaliśmy, że najlepiej będzie na razie przetestować w boju montowalne engine’y i zobaczyć w jaki sposób programiści ich używają, a później popracować na montowalnymi aplikacjami.

Czym są montowalne engine’y? Po co właściwie przez większą część wakacji siedziałem przy kodzie railsów skoro engine’y już istnieją w railsach 2.x i stosunkowo łatwo można napisać plugin z kontrolerami, modelami i widokami? Implementacja engine’ów w railsach 2.x ma kilka sporych wad. Pierwszą z nich jest zarządzanie routesami. Użytkownik nie ma żadnego wyboru w kwestii tego pod jakim urlem engine będzie się znajdował. Jeżeli twórca engine’u użyje routesów, to jedynym prostym sposobem na zmianę zachowania jest sforkowanie i ręczna zmiana kodu. Następnym problemem jest enkapsulacja. Kontrolery w obecnej wersji engine’ów zachowują się tak, jakby po prostu przekopiować je ręcznie do aplikacji. Oznacza to, że każdy kontroler dostaje automatycznie wszystkie helpery z aplikacji. W niektórych przypadkach może to być pożądane zachowanie, ale przy użyciu engine’ów napisanych przez innych, wiąże się to z ryzykiem kolizji nazw. Kolejne ograniczenie to rack middlewares. Nie można w prosty sposób dodać middleware’ów, które będą podpięte tylko do engine’u. Jedyny sposób to ręczne sprawdzanie ścieżki (np. env["PATH_INFO"] =~ /^\/tolk/, niezbyt wygodne). W railsach 3.0 można co prawda używać aplikacji racka w kontrolerach, ale jest to dość ograniczone, tzn. wpinamy się już po przejściu przez router i cały middleware stack. Ostatnią rzeczą, o której chciałbym wspomnieć, jest wygoda. Ze względu na konflikty nazw, najbezpieczniej jest umieścić wszystkie modele, kontrolery i helpery w module. Pociąga to za sobą jednak kilka niedogodności. Np. w tym momencie wszystkie helpery generujące urle trzeba prefixować, np. blog_posts_path. Tak samo jest z modelami, domyślna nazwa wygenerowana przez ActiveModel::Naming, to blog_post dla klasy Blog::Post.

Podczas pracy w RSoC próbowałem poprawić te problemy. W efekcie zaszło dość dużo zmian w zachowaniu engine’ów:

engine jest teraz aplikacją rack
posiada własny middleware stack
posiada własne routesy
pliki z katalogu public mogą być serwowane z użyciem ActionDispatch::Static
może posiadać swoje własne pluginy
w prosty sposób można umieścić modele i kontrolery w module

Co się zmieniło?

Izolowany lub współdzielony engine

Do tej pory pliki z katalogu ‘app’, znajdującego się w katalogu z engine’em, zachowywały się mniej więcej tak, jakby wkleić je do katalogu app w aplikacji. Skutek tego był taki, że dostawały wszystkie helpery (w tym także helpery do routesów) z aplikacji. Dla niektórych engine’ów jest to pożądane zachowanie (np. Devise), ale istnieje wiele przypadków, w których nie działa to zbyt dobrze. W przypadku użycia jakiegoś dużego engine’u, takiego jak np. forum, istnieje duża szansa wystąpienia konfliktów (np. takie same nazwy metod w helperach). Dlatego od railsów 3.1 wprowadzona zostanie możliwość oznaczenia, że Engine jest izolowany używając metody isolate_namespace:

module Blog
  class Engine < ::Rails::Engine
    isolate_namespace Blog
  end
end

Przy takiej konfiguracji kontrolery znajdujące się w module Blog, dostaną tylko i wyłącznie helpery i routesy znajdujące się w tym samym namespace.

Montowanie engine’u

Engine można zamontować w aplikacji tak jak każdą aplikację Rack, używając metody mount:

mount Blog::Engine => "/blog", :as => "blog"

Przy takiej definicji engine będzie dostępny w /blog.

Routes

Z powodu tego, że Engine może teraz posiadać swoje własne routes’y, czasami zajdzie potrzeba odwołania się do routesów engine’u z aplikacji i na odwrót. Dlatego stworzone zostały helpery, ktore to umożliwiają. Helper main_app służy do odwołania się do routesów aplikacji, a helpery dla zamontowanych engine’ów zależą od opcji :as użytej w powyższym przykładzie. Np. dla powyższego przykładu, helper do engine’u Blog::Engine będzie nazywał się blog. Dzięki temu można napisać np.:

blog.posts_path
blog.root_path

main_app.login_path

Oczywiście takie helpery muszą być użyte tylko przy odwoływaniu się do innych routesów, np. kiedy chcemy wygenerować ścieżkę do routesów bloga z kontrolera aplikacji.

Namespacing

Żeby uniknąć konfliktów, montowalny engine musi być zamknięty w namespace. W normalnych warunkach skutkuje to tym, że wszędzie trzeba dodawać prefix (np. nazwa dla modelu Blog::Post, to w normalnych warunkach blog_post, route to blog_posts_path itp.

Tego typu prefixy w zwykłym enginie są używane w celu uniknięcia konfliktów. W izolowanym enginie najczęściej nie ma takiego problemu. Np. nie opłaca się w środku engine’u pisać blog_posts_path zamiast posts_path. Tak samo podczas wysyłania parametrów z formularza, nie opłaca się używać params[:blog_post] zamiast params[:post]. Engine oznaczony jako izolowany pozwala na ominięcie tych prefixów w większości miejsc.

Migracje

Jeżeli używacie w swojej aplikacji ActiveRecorda, to przydadzą się też migracje. Obecne podejście do migracji engine’ów, to kopiowanie migracji do katalogu aplikacji z przepisaniem timestampów. Dla przykładu mamy w enginie Blog::Engine migrację 20091212_create_posts.rb. Po wykonaniu w dniu 2010-10-10 komendy:

rake railties:copy_migrations

zostanie ona przekopiowana do katalogu aplikacji z nazwą 20101010_create_posts.blog.rb. Wybraliśmy ten sposób z kilku powodów:

przed wykonaniem migracji warto na nią spojrzeć, co po przekopiowaniu do katalogu aplikacji jest dużo łatwiejsze
tego typu format jest zgodny z dotychczasowym, więc nie trzeba było zmieniać tabeli schema_migrations
dzięki przepisywaniu timestampów nie wystąpi sytuacja, w której po przekopiowaniu migracji, będą one wykonywane przed migracjami aplikacji (ma to znaczenie kiedy w czasie rozwijania aplikacji dodamy jakieś pole do tabeli z engine’u)

Pliki statyczne

Ostatni problem jaki trzeba było rozwiązać, to serwowanie statycznych plików. Są na to obecnie 2 sposoby:

utworzenie symlinków do katalogów public w enginach, służy do tego task rake railties:create_symlinks
wykorzystanie ActionDispatch::Static (middleware, który serwuje pliki statyczne)

Tutorial

Najłatwiej pokazać wszystkie zmiany w praktyce, więc pokuszę się o napisanie prostego engine’u. Do wygenerowania tego engine’u użyjemy enginex napisanego przez José Valima. Niech nie zmyli was nazwa. Enginex został co prawda stworzony w celu prostego generowania engine’ów, ale z powodzeniem można go używać do wygenerowania szkieletu dla dowolnego gema, który będzie miał za zadanie działać z railsami 3. Na początek zainsalujmy enginex:

gem install enginex

Po wykonaniu komendy enginex --help pokażą się dostępne opcje. W chwili obecnej można ustawić jedynie test framework (rspec lub test unit). Zacznijmy z domyślnym test unit:

enginex blog

Enginex powinien stworzyć w tym momencie katalog blog, w którym będą znajdować się pliki z reguły pojawiające się w gemach (lib, test, README itp) oraz coś nowego – aplikacja railsów w katalogu test/dummy. Po co nam aplikacja railsów? Ze względu na to, że engine (czy też inny rodzaj gemu) będzie pracował z railsami i najłatwiej testować go w realnym środowisku railsów.

Pierwsze co trzeba będzie zmienić, to plik Gemfile. Obecna wersja enginex zakłada, że użyte będą railsy 3.0. Całkiem słuszne założenie dla większości projektów, ale żeby korzystać z dobrodziejstw najnowszej wersji engine’ów, trzeba będzie użyć wersji z githuba. Co więcej, trzeba będzie użyć wersji z mojego forka railsów na githubie. Co prawda większość rzeczy, nad którymi pracowałem, jest już w oficjalnym repozytorium railsów, ale cały czas poprawiam różne rzeczy i ze względu na to, że nie mam możliwości commitowania, trzeba czasami poczekać trochę na akceptację i dorzucenie do oficjalnej wersji.

Dlatego zmieniam Gemfile, żeby wyglądało w ten sposób (przy okazji dorzuciłem też factory_girl_rails, przyda się później):

source "http://rubygems.org"

gem "rails", :git => "git://github.com/drogus/rails.git", :branch => "engines"
gem "arel", :git => "git://github.com/rails/arel.git"

gem "factory_girl"
gem "capybara", ">= 0.3.9"
gem "sqlite3-ruby", :require => "sqlite3"

if RUBY_VERSION < '1.9'
  gem "ruby-debug", ">= 0.10.3"
end

Teraz tylko bundle install w konsoli i można zacząć pracować. Dla pewności, że środowisko się poprawnie wczytuje, można jeszcze odpalić testy: rake test

Jeżeli testy przechodzą, to można się zabrać za pisanie kodu. Od czego zacząć? Od testów oczywiście ;-) Po przejrzeniu katalogu test, łatwo zauważyć, że znajduje się tam katalog integration. Wygenerowane przez enginex testy korzystają z Capybary, dzięki czemu można łatwo pisać testy integracyjne. Zacznijmy od wyświetlania postów na blogu. Stwórzmy plik test/integration/posts_integration_test.rb:

require 'test_helper'

class PostsIntegrationTest < ActiveSupport::IntegrationCase
  test "I can see blog posts on blog's root page" do
    Factory.create(:post, :title => "Awesome!", :body => "All work and no fun makes Jack a dull boy")

    visit blog.root_path
    assert page.has_content?("Awesome!")
    assert page.has_content?("All work and no fun makes Jack a dull boy")
  end
end

Po uruhomieniu rake test zobaczymy: ArgumentError: No such factory: post. Brakuje nam wpisu post w factories. Dodajmy go więc:

# test/factories.rb

Factory.define :post, :class => "Blog::Post" do |f|
  f.title "My post"
  f.body "It's just a post, man..."
end

Do pliku test/test_helper.rb dodajemy również require "factories".

Tym razem po uruchomieniu testów, błąd powinien wyglądać mniej więcej tak: NameError: uninitialized constant Blog::Post. Nic dziwnego, nie ma jeszcze w kodzie żadnego modelu. Model jest oczywiście namespace’owany i dlatego używamy Blog::Post zamiast normalnego Post. Nie pozostaje nic innego jak dodać taki model:

# app/models/blog/post.rb
module Blog
  class Post < ::ActiveRecord::Base
  end
end

Musimy dodać także migrację i sprawić, żeby była uruchamiana przy każdym odpaleniu testów (między innymi przez takie problemy uważam, że mongodb, to przyszłość modularnych aplikacji ;-). Powstają tutaj dwa problemy. Pierwszym z nich są generatory. W tej chwili niestety generatory nie działają w katalogu engine’u. Drugi problem jest związany z uruchamianiem migracji, nie ma obecnie żadnego mechanizmu, który automatyzuje wykonywanie migracji dla engine’u w testach. Ale co to dla nas?

Stwórzmy migrację:

# db/migrate/20100631120813_create_blog_posts.rb
class CreateBlogPosts < ActiveRecord::Migration
  def self.up
    create_table :blog_posts do |t|
      t.string :title
      t.text :body

      t.timestamps
    end
  end

  def self.down
    drop_table :blog_posts
  end
end

Teraz wystarczy stworzyć plik test_helper i wkleić pod komentarzem “#Run any available migrations” poniższy kod:

# Run any available migrations
FileUtils.rm(Dir[File.expand_path("../dummy/db/test.sqlite3", __FILE__)])
FileUtils.rm(Dir[File.expand_path("../dummy/db/migrate/*.blog.rb", __FILE__)])
FileUtils.mkdir_p(File.expand_path("../dummy/db/migrate/", __FILE__))
ActiveRecord::Migration.copy File.expand_path("../dummy/db/migrate/", __FILE__), { :blog => File.expand_path("../../db/migrate/", __FILE__) }
ActiveRecord::Migrator.migrate File.expand_path("../dummy/db/migrate/", __FILE__)

Kod ten usuwa wszystkie wcześniej skopiowane migracje i bazę sqlite3, po czym kopiuje aktualne migracje z katalogu db/migrate i je uruchamia.

Ok… Uruchamiany testy i: NameError: uninitialized constant Blog::Post. Pomimo tego, że model jest już stworzony, w testach dalej go nie widać. Dlaczego tak się dzieje? Nigdzie nie powiedzieliśmy, że aplikacja ma wczytać nasz Engine… a właściwie nawet nie mamy jeszcze engine’u! Po sprawdzeniu pliku lib/blog.rb można zauważyć, że jest tam jedynie:

module Blog
end

Enginex nie robi żadnych założeń co do tego jakiego rodzaju gem chcemy zrobić. Trzeba to skorygować, w pliku lib/blog/engine.rb wstawmy kod engine’u:

module Blog
  class Engine < ::Rails::Engine
    namespace Blog
  end
end

a w lib/blog.rb załadujmy powyższy kod:

require 'blog/engine'

Pojawia się tutaj opisywana wcześniej metoda namespace, która sprawia, że Engine jest izolowany.

Tym razem po uruchomieniu testów dostaniemy taki błąd: NameError: undefined local variable or method `blog' for #<PostsIntegrationTest:0x000001041136e0>. Chodzi o linijkę blog.root_path w teście. Brakuje nam helperow do routesów zamontowanych engine’ów. W przyszłości takie helpery będą prawdopododbnie automatycznie dołączane do testów, ale w tym momencie niestety trzeba będzie zrobić to samemu. W pliku test/support/integration_case.rb w ciele klasy ActiveSuppoer::IntegrationCase należy wkleić:

include Rails.application.routes.mounted_helpers

W tym momencie helpery powinny już być dostępne, ale po uruchomieniu testów dalej dostaniemy ten sam błąd. Dlaczego? Jak już pisałem są to helpery do wszystkich zamontowanych engine’ów. A tak się składa, że Blog::Engine nie jest jeszcze nigdzie zamontowany. Poprawmy to montując engine w aplikacji w pliku test/dummy/config/routes.rb:

mount Blog::Engine => "/blog", :as => "blog"

Po uruchomieniu testów powyższy błąd powinien zniknąć, ale za to dostajemy kolejny związany z routesami: NoMethodError: undefined method `root_path' for #<ActionDispatch::Routing::RoutesProxy:0x00000101e9bd10>. Wynika to z faktu, że nie zdefiniowaliśmy jeszcze żadnych routesów w enginie. Aby to zrobić wystarczy wkleić taki oto kod w pliku config/routes.rb:

Blog::Engine.routes.draw do
  root :to => "posts#index"
end

Routesy powinny już działać poprawnie, ale testy podpowiadają nam, że brakuje kontrolera: ActionController::RoutingError: uninitialized constant Blog::PostsController. Kontroler powinien wyglądać mniej więcej tak:

module Blog
  class PostsController < ActionController::Base
    def index
      @posts = Post.all
    end
  end
end

i znajdować się w pliku app/controllers/blog/posts_controller.rb. Ciekawe w tym kodzie jest to, że nie musimy używać Blog::Post, wystarczy samo Post, ponieważ już jesteśmy w odpowiednim namespace. Dlatego właśnie używam dłuższej formy: module Foo; class Bar; end; end. Przy zastosowaniu skróconego zapisu nie dałoby się tak zrobić:

class Blog::PostsController < ActionController::Base
  def index
    @posts = Post.all #=> ArgumentError: Blog is not missing constant Post!
  end
end

A wracając do samego engine’u… Jak pewnie niektórzy się domyślą, tym razem testy będą krzyczeć o braku template’u. Stwórzmy więc app/views/blog/posts/index.html.erb, a w nim wyświetlmy pobrane w kontrolerze posty:

<h2>Posts</h2>

<% @posts.each do |post| %>
  <h3><%= post.title %></h3>
  <div class="post">
    <%= post.body %>
  </div>
<% end %>

W tym momencie testy powinny przechodzić! Aplikacja już działa, ale przydałby się jakiś layout. Do pliku app/views/layouts/blog.html.erb skopiujcie poniższy kod:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Blog</title>
</head>
    <header>
      <h1>Blog</h1>
    </header>

    <div id="main">
      <%= yield %>
    </div>

    <footer>
    </footer>
  </div>
</body>
</html>

Teraz trzeba ten layout ustawić w kontrolerze. Z reguły robi się to w ApplicationController i żeby pozostać DRY, w enginie też można tak zrobić (z tą różnicą, że tutaj będzie to Blog::ApplicationController, który będzie wyglądał tak:

module Blog
  class ApplicationController < ActionController::Base
    layout "blog"
  end
end
end

Wystarczy jeszcze tylko zmienić Blog::PostsController, żeby dziedziczył z ApplicationController i layout powinien poprawnie się wyświetlać:

class PostsController < ApplicationController

Ok, super, ale nie można przecież rozwijać aplikacji opierając się tylko na testach. Tutaj również możemy skorzystać z testowej aplikacji. Wejdźcie do katalogu test/dummy, wykonajcie migracje rake db:migrate, włączcie konsolę script/rails c, a w konsoli stwórzcie jakieś posty:

Blog::Post.create(:title => "First post", :body => "This is awesome!")
Blog::Post.create(:title => "Missed missy", :body => "Missy needs your help... :(")

Teraz można już włączyć serwer, zobaczyć jak to wygląda i dodać style. Wystarczy uruchomić serwer (script/rails s) i wejść na http://localhost:3000/blog. Powinniście zobaczyć tam dodane przed chwilą posty. W layoucie blog.html.erb można teraz wstawić link do cssów:

  <%= stylesheet_link_tag "style" %>

a w pliku public/stylesheets/style.css (w katalogu engine’u, nie aplikacji) na przykład:

header h1 {
  color: #A80000;
}

Po uruchomieniu serwera tytuł bloga powinien zmienić kolor na czerwony. Serwowanie plików statycznych działa bez wprowadzania żadnych zmian, ponieważ w trybie development domyślnie uruchamiany jest ActionDispatch::Static. W środowisku production, trzeba ustawić config.serve_static_assets na true, lub wykonać rake railties:create_symlinks w celu stworzenia symlinków do katalogów public w engine’ach.

Na tym chciałbym zakończyć ten tutorial. W razie czego aplikację umieściłem na W kolejnych odsłonach napiszę trochę więcej o tym jak dalej obchodzić się z tego typu engine’ami. Dla podsumowania, po przeczytaniu tej notki powinniście wiedzieć jakie są różnice pomiędzy starszą wersją engine’ów, a tym co obecnie siedzi w rails/master oraz umieć stworzyć prosty montowalny engine.

RSoC status: Namespacing engines

2010-09-06T00:00:00-07:00

It’s been a while since my last post. After finalizing my work on routes and few other things I went to Croatia for 2 weeks, to rest from the computer and programming. But fear not, I will not count that 2 weeks into RSoC time and I will work for 2 weeks longer to not shorten actual development time.

The big news is: my work has been merged to rails official repository recently! That means that you can start using the things that I described right away (you just need to use edge version of rails).

The next thing that needed to be done to allow mounting engines easily is namespacing. Namespacing is crucial to avoid conflicts between engines and application itself. Imagine that you have application with Article and Comment models and you want to mount blog engine into it. The chances are, blog engine will also have Comment model and corresponding controller and helper. Without namespacing such configuration would end up with conflicts. To avoid that, we can put all of the things in an engine into namespace:

# ENGINE/app/models/blog/comment.rb
module Blog
  class Comment < ActiveRecord::Base
  end
end

# ENGINE/app/controllers/blog/comments_controller.rb
module Blog
  # note that ApplicationController here is in fact Blog::ApplicationController
  class CommentsController < ApplicationController
  end
end

At first, it may seem that this will not require any changes to Rails, it’s standard Ruby technique, right? To some degree it’s true, but there are some places that made it hard to use namespaced engines before.

Let’s look at controllers as an example. In rails 3.0, when you create any class that inherits from ActionController::Base, it will get all of the application helpers. It’s default behavior and it’s perfectly ok when you have only one application. Problems appear when you want to mount engine with its own controllers and helpers. With Rails 3.0 it will be a bit hard. Even if you namespace your controllers and helpers, you will get all application’s helpers instead of engine’s ones. The simple solution would be to load only helpers within current namespace, but that would break some of the existing engines.

There are basically 2 types of engines. Some of the engines are considered to be a part of application, they provide helpers and controllers that will be used within application and there is no need to isolate them (take Devise as example of such engine). I will call it “shared engine”. The second use case is engine that should not share anything, like blog engine. I will call such constructs “isolated engines”.

The problem with having shared and isolated engines is the fact that in both situations you can namespace stuff inside, but the behavior should be slightly different. While you would probably like to share helpers from shared engine, even if they’re namespaced, you would not want that in case of isolated engine. To distinguish this situations you need to explicitly say that engine is isolated. Otherwise it will be shared. To make engine isolated, just use isolate_namespace() method in Engine definition:

module Blog
  class Engine < Rails::Engine
    isolate_namespace(Blog)
  end
end

With such code, all of the stuff namespaced with Blog will be isolated. There are quite a few effects of that. As I mentioned before, one of the problems are controllers. With engine explicitly marked as namesapaced, controllers will include only helpers from within the same namespace and they will include only an engine’s routes.

The next thing is router itself. When you have every controller inside the module, normally you would have to reflect that in routes:

Blog::Engine.routes.draw do
  scope(:module => :blog) do
    resources :posts
  end
end

This code will ensure that posts resource points to Blog::PostsController. With isolated engine this is not needed at all. You can ommit that scope, cause it will be applied automagically behind the scene. With engine marked as isolated you can just do:

Blog::Engine.routes.draw do
  # everything here is namespaced with :blog namespace
  resources :posts
end

The next thing to change was ActiveModel::Naming. It is used in many places in rails and by default it leaves namespace, e.g. it would convert Blog::Post to blog_post. While in some places it’s ok, it can be a major PITA in other ones. The first pain point is polymorphic_url, which is used among the other things in form_for. Let’s consider example of Blog::Post model:

# @post = Blog::Post.new

<%= form_for(@post) do |f|%>
  <%= f.text_field :title %>
  <%= f.submit %>
<% end %>

Without any changes in ActiveModel::Naming, such code would try to use blog_posts_path helper. Using namespace here is not needed at all, as you can’t have a conflict with helpers from other routers. That’s why in isolated engine form_for(@post) will use posts_path and thanks to that, we didn’t need to add that prefix to all the routes.

The next thing connected with forms and model name are param names. Normally, the last piece of code would generate field <input type="text" name="blog_post[title]" id="blog_post_title" />. That kind of prefixes are also not needed as it’s highly improbable that you would need params[:post] for some other thing (and even if it is the case for you, you can use :as => :some_other_name to change the default). The blog_ is also omitted here and in isolated engine the field would look just like that: <input type="text" name="post[title]" id="post_title"/>.

All of the other places where ActiveModel::Naming is used, like partials, generating dom elements or i18n, take the namespace into account.

As you can see, there was quite a few changes in Rails code to handle namespaces, but in the end they’re pretty transparent to for the developer.

Rails3 modularity

2010-07-31T00:00:00-07:00

Since I spend a lot more time with Rails 3 codebase, I am more and more amazed by its modularity. Rails 3 is much more extensible than I would have ever thought. As a part of my rubysoc project I wanted to port merb-parts to Rails 3. Some of you may never heard of merb parts and ask what the hell are parts? Do I need it? Parts are a bit like controllers, but much more lightweight and without overhead of handling requests. I like to think about parts as powerful partials. If you have a partial and you would like to add a bit more logic to it or fetch something from database, you could probably benefit from using parts. Let’s go with a simple example:

# app/parts/articles_part.rb
class ArticlesPart < Parts::Base
  def index
    @articles = Article.limit(params[:limit] || 10).order("created_at DESC")
  end
end

# app/parts/views/articles_part/index.html.erb
<ul>
  <% @articles.each do |article| %>
    <li><%= article.title %></li>
  <% end %>
</ul>

This simple part will fetch last params[:limit] articles or 10 if limit is not provided. Let’s use it in our view:

  <%= part(ArticlesPart => :index, :limit => 5) %>

Such call will render list of last 5 articles.

The question is: how much lines of code does it take to implement something like that with ability to render views, layouts, :inline, use helpers, filters and much more? Over 100 lines of code including part() helper and a railtie (railtie is used to plug it into rails) – if you don’t believe me grab the repo and check it yourself.

How is it possible? Let’s look at the implementation of Parts::Base:

require 'parts/default_layout'

module Parts
  class Base < AbstractController::Base
    attr_reader :params

    include AbstractController::Layouts
    include AbstractController::Translation
    include ActionController::Helpers
    include AbstractController::Rendering
    include ActionController::ImplicitRender
    include DefaultLayout
    include AbstractController::Callbacks

    def initialize(controller, params)
      @params = controller.params.dup
      @params.merge!(params) unless params.empty?
      self.formats = controller.formats
    end

    def self.inherited(klass)
      super
      klass.helper :all
    end
  end
end

That’s all… ? Yes!

As you cans see Parts::Base inherits from AbstractController::Base, which gives it really basic functionality. Additionaly a few helpers are included to add a bit more behavior. The only mixin that I needed to create myself is Parts::DefaultLayouts which ensures that layout with the name of the part is rendered by default, unless :layout => false or there is no such layout in layouts directory.

Ok, that all is nice and dandy, but how does it work internally?

The implementation of such pattern can be demonstrated with such code:

class Foo
  def foo
    puts 'foo'
  end
end

module Bar
  def foo
    puts 'bar'
    super
  end
end

module Baz
  def foo
    puts 'baz'
    super
  end
end

class Omg < Foo
  include Bar
  include Baz

  def foo
    puts 'omg'
    super
  end
end

Omg.new.foo #=> omg
            #   baz
            #   bar
            #   foo

There are 2 modules (Bar and Baz) and 2 classes (Foo and Omg) implementing foo method here. Omg class inherits from Foo and additionaly modules Bar and Baz are included in Omg. This code takes advantage of ruby object model. How does it work?

When you instantinate Omg object with Omg.new and call method foo on it, it looks for foo method in current class and its superclasses. So first method that will be actually called is Omg#foo. This method is calling super, so ruby will look for method foo also in Omg’s superclass. At first you could think that it’s Foo, but internally Ruby treats modules as superclasses. That said, the next superclass will be the last included module, which is Baz. After that Bar’s and Foo’s methods will be invoked.

This one of the best patterns I have seen in Ruby so far. Not only it allows to extend objects easily, but also to reuse small chunks of code making the whole thing more modular. If Rails would stop at standard inheritance that we know from Java and other similar OO languages, creating something like parts would be much harder. In Parts::Base I used a few modules from AbstractController, but also a module from ActionController. With implementation without mixins, I would need to take all or nothing approach.

If you’re a Ruby developer, please think about that pattern while writing your next library. It can really help to make your code easier to extend and reuse. I was amazed how easy it was to implement all that stuff and I love the way that Rails is going!

RSoC status: routes (a.k.a OMG it's hard)

2010-07-20T00:00:00-07:00

In my last post I briefly described some of the RSoC changes and plans. One of the things that I left is router. The topic is much harder and I think it deserves separate blog post.

Basically, the problem with engines and routes is that now you can have more than one router. That leads to many issues that need to be solved. As with my last post, things described here are not in Rails core yet, so you will have to wait a bit to actually use it.

For the good start, let’s identify things to consider:

recognition
generation
named routes from more than one router (for example posts_path)

Recognition

At the beginning I would like to explain how does recognition work. Here is a simple example of engine mounted in application:

# APP/config/routes.rb
Foo::Application.routes.draw do
  resources :users
  mount Blog::Engine => "/blog"
end

# ENGINE/config/routes.rb
Blog::Engine.routes.draw do
  resources :posts
end

As you can see engine provides :posts resource and it’s mounted at /blog path. Let’s study simple request to our blog:

GET /blog/posts

Application’s router will match the first part of the path, which is /blog, with /blog mount point and pass the request to rack app mounted there (which in that case is Blog::Engine). To allow engine recognizing path properly it needs to pass /posts as a path. The /blog (which I will call prefix later on) is not a part of mounted engine, but we don’t want to loose that information by simply removing it from PATH. In that case /blog prefix is attached to env["SCRIPT_NAME"] (SCRIPT_NAME is part of rack’s spec). That way, engine will get only /posts part as PATH, which will allow to properly recognize it.

The only one problem with recognition is connected with rack middlewares. Consider such example:

# APP/config/routes.rb
Foo::Application.routes.draw do
  mount Blog::Engine => "/blog"
  match "/blog/omg" => "omg#index"
end

# APP/app/controllers/omg_controller.rb
class OmgController < ApplicationController
  use SomeMiddleware
end

# ENGINE/lib/blog/engine.rb
class Blog::Engine < Rails::Engine
  config.use SomeMiddleware
end

What will happen when you will request /blog/omg path? It will call the Blog::Engine first, as it has higher priority than /blog/omg. Request will pass through the Engine’s middleware stack firing SomeMiddleware and hit the Engine’s router. If /omg is not a valid route for Blog::Engine it will return 404 and Application’s router will try next route, that is /blog/omg pointing to OmgController. Middleware stack for that controller also includes SomeMiddleware so it will be fired again, which is probably not something that we want.

The solution is to mount apps with lower priority than other routes.

Generation

The problem with generation is related to mount point, the place where engine is mounted. Consider such example:

# APP/config/routes.rb
MyRailsApp::Application.routes.draw do
  match "/" => "users#index"

  scope "/:user", :user => "drogus" do
    mount Blog::Engine => "/blog"
  end
end

# ENGINE/lib/blog/engine.rb
class Blog::Engine < Rails::Engine
end

# ENGINE/config/routes.rb
Blog::Engine.routes.draw do
  resources :posts
end

Blog::Engine is mounted at "/:user/blog" (let’s just suppose that blog implements multi user setup) and it provides posts resources. As you can remember from recognition part, /:user/blog part is engine’s prefix. Additionally, default user is set to “drogus”, so when :user is not specified it will be set to drogus. Imagine that you need to generate path to posts. Something that you would normally achieve by calling posts_path method. With more than one router the situation is not so simple. We can’t simply use named url helpers (like posts_path) inapplication’s controllers, so we need some other way to handle that (if you’re wondering why can’t we just use posts_path, it’s explained in named routes section of this post).

First problem connected with that is API. Jeremy Kemper came up with helper that will allow using mounted engine’s url helpers by simply calling some_engine.posts_path. The name of that helper is taken from Engine’s name or from :as option used in mount method. Because :as option is not provided in my example, helper’s name will be blog_engine (based on Blog::Engine). Using that helper we can generate paths for Engine:

blog_engine.posts_path
blog_engine.url_for @post
blog_engine.polymorphic_path @post
blog_engine.url_for :controller => "posts", :action => "index"

We can also generate application’s urls with app helper:

app.root_url

The next problem to solve is behavior of such helpers. At first, it seems that it’s fairly easy, but in reality there is quite a few cases to handle. The thing that is most important while considering url generation is context. We can generate urls in application’s controllers, engine’s controller’s, ActionMailer or regular classes not related to Rails itself. Let’s go through each case.

Generating engine’s url inside application’s controller

# APP/app/controllers/foo_controller.rb
class FooController < ApplicationController
  def index
    blog_engine.posts_path #=> "/drogus/blog/posts"
  end
end

Generating posts path inside one of application controllers (and consequently views and helpers) should generate prefix according to mount point. In that particular situation, default user will be inserted in place of :user, so the url will be "/drogus/blog/posts". You could also do blog_engine.posts_path(:user => "john"), which would generate "/john/blog/posts".

Generating engine’s url inside engine’s controller

# ENGINE/app/controllers/posts_controller.rb
class PostsController < ActionController::Base
  include Blog::Engine.routes.url_helpers

  def index
    posts_path #=> ??
  end
end

This situation is a bit different. The first thing you will probably notice is that I used posts_path instead of blog_engine.posts_path. This is possible because I included url_helpers from engine’s routes. From various reasons it can’t be included automagically for engine’s controllers, but the plan is to make it work without any explicit includes. Why can’t we just use blog_engine.posts_path? In that example it would work, but note that engine can be mounted with different :as option. With mount looking like:

mount Blog::Engine => "/blog", :as => "blog"

you would have to use blog.posts_path instead of blog_engine.posts_path. Basically engine should not need to know how it’s mounted. That said, we don’t have any information about options used to mount it, all that we know is what’s the request that was used to reach the engine.

But what about the generated path? Someone could say that it should also generate prefix, but that would not work as expected. Imagine that someone requested one of your users blog with path "/dhh/blog/posts/1". When you click on link with url generated by posts_path, you should stay in the same scope, so url should depend on you current path. This is achieved by using env["SCRIPT_NAME"] value. In request to "/dhh/blog/posts/1", the script name would be set to "/dhh/blog", as this is the part of path that does not belong to engine. It should be clear now, that example above will generate "/dhh/blog/posts" path for such request.

The next thing that is worth mentioning is _routes method. When you call posts_path directly, it must use routes object. This object is available through _routes method. This method is defined when you include url_helpers, so it points to application’s routes by default. When Blog::Engine.routes.url_helpers are included in PostsController, _routes is changed to use engine’s routes, and because of that we can use posts_path safely.

Generating application’s url inside engine’s controller

# ENGINE/app/controllers/posts_controller.rb
class PostsController < ActionController::Base
  def index
    app.root_path
  end
end

We would like to generate root_path from our application’s router. Obviously it should generate "/" path, without Engine’s prefix. The only exception is situation when app is hosted in a sub path (eg /myapp). This can be done with Phusion Passenger, using RailsBaseURI option. /myapp part would be passed as SCRIPT_NAME in such case. Nothing complicated, we already know how to use SCRIPT_NAME, right? Not really (wouldn’t it be to simple? ;-). The problem is, SCRIPT_NAME is kept as a string. Let’s see how the request to "/myapp/user/blog/posts" looks like.

At first it hits the application. SCRIPT_NAME is set to /myapp by Passenger and the path is /user/blog/posts. Now, application’s router recognizes that this request should get to engine, so Blog::Engine is called. As engine needs only /posts as path, the prefix (/user/blog) will be attached to env["SCRIPT_NAME"] resulting in /myapp/user/blog. As this is one string and we need to get just application’s script name, solution is not obvious. How do we get the original script name? Right now our approach is to use whatever is set in Rails.application.routes.default_url_options[:script_name], so it should be set to “/myapp” in that case.

Generating engine’s url in any other class (including ActionMailer)

In that case, url should be generated with prefix (which would be /user/blog in my example). In ActionMailer we are not inside request, so script_name is not available and with that in mind we need to generate the full path with "/user/blog/" at the beginning.

Solution

Although it may look complicated to handle all those use cases, solution is relatively easy. The first thing to do is to assume that prefix should be always generated. This gets all cases with prefix out of our way. What’s not so obvious, it also makes generating application’s url in engine work. As application’s routes are not mounted, prefix is nil, so we can safely add it to “generate prefix” case. What’s left? Generating engine’s url inside engine. We need to use env["SCRIPT_NAME"] here. How to check if we should attach script name? We need to check if routes used to generate url are the same as routes connected with current request.

Right now, to make it possible, router object is passed via env["action_dispatch.routes"]. When application is called, it sets it to Rails.application.routes and then when engine is called, it sets its own router there. That way, we always now in which controller are we. If _routes method points to the same routes as the env["action_dispatch.routes"] it means that we try to generate engine’s url inside engine and we should use the SCRIPT_NAME.

Named routes

The initial idea was to allow using named routes from 2 routers in one scope, just like that:

# APP/app/controllers/foo_controller.rb
class FooController < ActionController::Base
  # Rails.application.routes_url_helpers are included by default
  include Blog::Engine.routes.url_helpers

  def index
    posts_path #=> "/blog/posts" - path from engine's router
    root_path #=> "/" - path from application's router
  end
end

Although it would be handy if you will have to use paths from mounted engine a lot, it is the cause of many issues:

named route method must know the router that it was generated by, as now we could have multiple routers
there is a collision problem if 2 routers have the same helpers (situations when both routers will have for example posts_path is not so common, but problem will exist for root_path for sure)
currently, after including url_helpers twice _routes method will point to second routes (Blog::Engine.routes in last example), which will cause problems with using url helpers directly

There are some solutions for all of those problems, but as they’re all a bit hacky and complicated, we decided to leave that topic and not allow to use helpers from 2 routers in one scope. It means that you will have to explicitly say that you want to use router other then the default one (for example by using blog_engine.posts_path helper). It also means that including url_helpers from engine will overwrite current routes, so in case above, you can’t directly use application routes any more. In such case you should use app helper.

I hope that this post is good introduction to current status of router usage in mountable apps. As usual: if you have any ideas, feature requests, critique or any other thoughts that could help bringing mountable apps to life, you’re more than welcome ;-)

RSoC status: bringing engines closer to application

2010-07-06T00:00:00-07:00

I’ve been working for Ruby Summer of Code for last 2 weeks and so far it’s great! In this post I will try to sum up the work on engines and outline a couple of problems that are still not solved.

The first idea for RSoC was to bring Rails::Engine closer to Rails::Application. One of the long term targets is to allow to run more than one Application instance in one process. As I described in my last post, application is a bit more specialized engine, so while moving most of the functionalities from Application to Engine, I could identify and solve most of the problems with running several apps in one process.

First things first. What can Engine do right now and where is it used in Rails? When you drop anything in vendor/plugins directory, it will implicitly be declared as Engine. The features of engine are:

everything in app/* works as in application
it can load config/routes.rb
config/locales/* are automatically picked by I18n
config/initializers works as in application
engines also have initializers blocks inside the Rails::Engine class to customize rails booting
you can customize paths like in application (for example change where controllers are)
it can define custom generators
rake tasks are loaded from lib/tasks

All these features are great, but we can take it even further. Here is the plan for bringing Rails::Engine closer to Rails::Application. Rails::Engine should:

be a Rack app
have a middleware stack
have its own routes
allow to store assets in public/
be able to run its own migrations
be able to load plugins
allow to do more configuration
allow to namespace models and controller without problems

A few things from that list are already finished (not in rails master yet, on my fork for now). I will describe my changes, but beware, this is code that’s not currently a part of rails and it can be changed before merging it to rails. Its here for getting feedback mainly.

Engine can be now a rack application by providing rack endpoint:

class Blog::Engine < Rails::Engine
  endpoint AnyRackApp
end

That code would create engine with AnyRackApp as endpoint. Now you can mount it with:

MyRailsApp::Application.routes.draw do
  mount Blog::Engine => "/blog"
end

Mount method will tell application router that Blog::Engine is located at “/blog” path. Let’s investigate a request to “/blog/posts”. At first, it will hit the application and it will be passed through entire application’s middleware stack. The last middleware in application is the router. Router will recognize that “/blog” should point to Blog::Engine app, so it will pass the request to Blog::Engine. Then it will be passed through Engine’s middleware stack and finally it will hit Engine’s rack endpoint.

What’s the point of providing rack app inside engine? Probably this will not be a common scenario, but it allows you to add all functionalities provided by Engines, like initializers, generators, to your rack app. Besides, Engine has its own middleware stack now, so you can easily add some specific middlewares that will be fired only on requests for engine:

class Blog::Engine < Rails::Engine
  middleware.use Rack::Subdomain
end

By default endpoint is set to routes, probably a more common scenario.

Currently if you want to add your own routes, you have to hardcode it in application’s routes. It’s a bit limited, as you cannot easily change the place where the engine is mounted. With Engine being able to use its own router, you can mount it anywhere you want, even using dynamic scopes.

# APP/config/routes.rb
MyRailsApp::Application.routes.draw do
  mount Blog::Engine => "/blog"
end

# ENGINE/lib/blog/engine.rb
class Blog::Engine < Rails::Engine
end

# ENGINE/config/routes.rb
Blog::Engine.routes.draw do
  resources :posts
end

With such setup, Blog::Engine is mounted at “/blog”. A request to “/blog/posts” will fire posts controller inside the engine. It’s simple as that! However, as we are going to see in another blog post, if you want to mount an engine using a dynamic route, as “/:company/blog”, we need to consider different scenarios on URL Recognition and Generation. Currently if you use posts_path, it will generate /posts. The problem is, if you’re in application you should prepend prefix for mounted app, so it would be “/company/blog/posts”.

Next important thing for engines working as full rails apps is public folder. Currently you can for example symlink engine’s public folder in your application. It’s ok, but there is much cleaner way to do it: use ActionDispatch::Static, which will serve static files from given directory. At first when I heard that idea, I thought that it will much slower than serving those files with web server, but according to Yehuda Katz, it should be really fast in practice and many server setups could actually cache it (for example with Varnish). If it’s still not fast enough you can just not enable serving static files, make a symlink and serve it with webserver.

In addition to all that features, engines can load its own set of plugins now. Right now, it’s really simple implementation without any check for duplicating plugins, but I think we will consider such thing. Personally I hope that more and more people will just start using gem plugins with its own dependencies, but there are still many apps with vendor/plugins full of plugins.

One of the things that has not been implemented yet is migration support. There is quite long discussion on it on lighthouse and a blog post with a few solutions described, but there is sill no consensus on that one. If you have any thoughts on that topic, you can add a comment on lighthouseapp.

The last problem that I will talk about (but certainly not last problem that will appear) is namespacing. For better encapsulation all of the controllers, helpers and models should be namespaced. The problem is, currently if you would namespace a controller or model it will not work as intended. Given:

class Blog::PostsController < Blog::ApplicationController
end

it will affect application in many places. Using that controller in routes will also require namespacing it with: “blog/posts#index”, which is probably not something that we want for all the routes. In case of models, most of ORMs will name table for class Blog::Post as “blog_posts”. It could be actually ok, as it will help to avoid name conflicts, but it’s not always desired behavior.

I will appreciate any ideas and thoughts on that topic. Anything, like API ideas, feature requests or solutions to some problems will be welcome and will help me with delivering better mountable apps. Stay tuned for the next post on RSoC status: routes. I promise you will not have to wait for it for the next 2 weeks ;-)

Rails internals: Railties

2010-06-18T00:00:00-07:00

I’m going to start my RSoC work next week, but I as a preparation for real work I started reading through Rails codebase. I will try to document my findings on this blog, I hope it will be helpful for people that would like to know Rails internals.

One of the first findings of reading Rails 3 code is that it’s really simple compared to previous Rails versions. Boot process doesn’t need rubygems magic anymore. Ruby features are used to make Rails flexible without need of some crazy hacks. alias_method_chain is not used anymore, which makes it much easier to understand code. These are really great news for all Rails devs, especially plugins maintainers. But hey, enough already known facts, let’s get to the point!

The core class of Rails is Railtie. If you are a plugin developer, you will probably want to take a closer look at that. Although Railtie is not required in every plugin, it’s handy if you want to hook into Rails boot process, create intializers or add a rake tasks. For more information you can read about Railtie in docs So what’s Railtie? It’s a simple class that is capable of loading generators, tasks, middlewares and adding subscribers. One of the things that I’ve noticed in Railtie (and almost any other class in Rails) is usage of autoload method. I’ve never heard of autoload before and it seems that’s very handy method. From rubydocs:

Registers filename to be loaded (using Kernel::require) the first time that module (which may be a String or a symbol) is accessed.

  autoload(module, filename) => nil
  autoload(:MyModule, "/usr/local/lib/modules/my_module.rb")

The great thing in autoload is its laziness. It will not load given file, if module is not accessed. How does Rails use autoload in Railtie? It autoloads Configurable and Configuration modules. As Railtie doesn’t need configuration on its own, it includes it in classes that inherit from Railtie (code). That way, those 2 files will not be loaded unless Railtie subclass is created. Someone could argue that Railtie will not be probably used alone, without any subclasses, as Railtie is much more like abstract class, but it’s really good pattern and it’s consistently used across other classes in Rails.

I need to rectify one thing. Although autoload is very nice, it’s also known to be thread unsafe and according to Carl Lerche it will be removed from Rails. Use with consideration ;-)

Getting back to Rails itself. The next class in hierarchy is Engine. Engine is much closer to full stack Rails app. In fact application is a bit more specialized Engine. That makes sharing an application as easy as converting it to engine. So, what’s Engine? Basically it’s Railtie with ability to set load paths for views, controllers, helpers, locales etc. That’s it? Nothing more? That simple? Yep, that’s right.

Now it’s time for Application. Application is a subclass of Engine and it’s capable of booting the Rails app. As you can read in the docs, Application is singletone and that’s why 2 Rails apps can’t be run in a single process. So what does exactly Rails application do?

it loads default middleware stack (it’s amazing how much things can be handled by rack middlewares, allowing to keep Rails code simpler)
it loads plugins
it sets bunch of other things: database, logging, sessions, environment config, cache
it loads activesupport (interesting thing, you can set config.active_support.bare to not load ‘active_support/all’)

It’s also interesting how does Rails use OO model to make things simpler. After generating Rails 3 apps you can notice that frameworks are loaded by just requiring their railties:

require "action_mailer/railtie"
require "active_resource/railtie"

The same goes for engines. Ok… but how will Rails know all the railties and engines loaded? As railties and engines are subclasses of Rails::Railtie and Rails::Engine, it’s as easy as getting their subclasses: ::Rails::Railtie.subclasses or ::Rails::Engine.subclasses. Quick note on subclasses: it’s not ruby method, subclasses are gathered using inherited method (code).

Now let’s look how is that all used to boot rails application. As you can see in Rails 3 application, config.ru file looks like:

require ::File.expand_path('../config/environment',  __FILE__)
run MyApplication::Application

As you probably know, object passed to “run” method must respond to :call. Application class does not have “call” method defined, though. How does it work? When you send “call” message to MyApplication::Application, method_missing will be fired and message will be send to application instance. In fact all of the missing methods on MyApplication::Application are delegated to instance:

def method_missing(*args, &block)
  instance.send(*args, &block)
end

What is instance? As Application is singleton, call to instance method returns instantinated application or instantinates it and then returns the instance. Application instance is built on initialization, such behavior is triggered in Finisher

The next question is: how does request’s path look like? call() method runs call() on @app object, which is basically the middleware stack. Then, request goes through all the middlewares up to ActionDispatch::Routing::RouteSet, which is responsible for routing request to one of the controllers or other rack apps.

After reading this blog post you should have a pretty good overview of core classes of Rails. I strongly encourage you to dive into Rails code yourself, it’s a good way to learn new things about design, object oriented programming in ruby and to pick some cool patterns.

If anyone is interested, I plan to continue Rails internals posts with action pack and routing system. Feedback highly appreciated! Please let me know if you find this kind of information useful or if you think that I missed something or should give more details on any of the parts.

Sprostowanie

2010-05-16T00:00:00-07:00

Ze względu na dziwne właściwości google readera w ostatnich godzinach zrobiło się niezłe zamieszanie z postami w RSSie. Zmieniłem adres bloga i naiwnie pomyślałem, że jeżeli podmienię w feedburnerze adres do starego feeda, to google reader zupdate’uje po prostu treść. Nic bardziej mylnego. Okazuje się, że google reader nie kasuje z cache’a żadnych postów. Dodatkowo nic go nie obchodzą daty, które są ustawione w RSSie, posty układa tak jak mu się podoba, a nie tak jak mu mówi atrybut ‘published’ w XMLu. Z tego powodu jakieś stare posty sprzed 3 lat pojawiły się na samej górze w czytniku. Pech sprawił, że wśród kilkudziesięciu postów na drugim miejscu był post sprzed 3 lat, w którym pisałem o rzuceniu pracy i studiów. Pragnę wyjaśnić, że jest to już daleka przeszłość i moje obecne studia i praca mają się niezwykle dobrze. Przepraszam za zamieszanie, od teraz będę miał na uwadze, że cache google readera jest nieugięty i choćbyście nawet bardzo chcieli, to nie uda się usunąć postów, które się w nim znajdują.

Jeżeli ktoś natrafi na ten problem, to od razu mogę podrzucić rozwiązanie. W googlu można znaleźć w ciągu kilku sekund przynajmniej kilkanaście tematów na forach i postów dotyczących tego problemu. W supporcie googla w jednym z tematów tego typu odpowiada nawet pracownik googla, który twierdzi, że jeżeli post już dodał się do cache’u, to “niezwykle trudno go stamtąd usunąć”. Prawdopodobnie jestem za cienki w łokciach, żeby się wypowiadać negatywnie o inżynierach googla, ale trochę mnie dziwi fakt, że bez problemu można w google web developer tools usunąć cache całej strony, która ma kilkadziesiąt tysięcy zaindeksowanych plików, ale nie można co jakiś czas odświeżyć cache’a RSSów. Przechodząc do samego rozwiązania. Posty nie mogą zostać usunięte, ale za to można zmienić ich treść. Dlatego jeżeli zachowane zostanie id posta, to google weźmie to za update. W ten sposób można podmienić zawartość niechcianych postów na coś w stylu “treść usunięta”. Życzę powodzenia w nierównej walce z cache’em googla!

Zmiana adresu

2010-05-16T00:00:00-07:00

Od dłuższego czasu nie pisałem nic na blogu. Było to częściowo spowodowane tym, że chciałem zmienić jego adres i połączyć z drugim blogiem (polski blog miał adres blog.drogomir.com, angielski drogomir.com/blog, kto w ogóle wymyśla taką dziwną konfigurację? nawet ja się najczęściej gubiłem pod którym adresem jest który blog). Ilekroć siadałem do edytora, żeby napisać coś sensownego, do głowy przychodziła mi myśl: przenieś w końcu te blogi! Zamykałem edytor, otwierałem internety, żeby zobaczyć na co zmigrować oba blogi i… po 10 minutach dawałem sobie spokój. W ostatnich dniach zebrałem się wreszcie, żeby przenieść oba blogi na nowy adres. Jak łatwo możecie zauważyć nowy adres to piotrsarnacki.com. Posty w języku polskim są dostępne pod adresem piotrsarnacki.com/pl. Nowe adresy dla RSSów to odpowiednio:

feeds.feedburner.com/piotrsarnacki-all – wszystkie posty
feeds.feedburner.com/piotrsarnacki – posty angielskie
feeds.feedburner.com/piotrsarnacki-pl – posty polskie

Posty powinny być też dostępne pod obecnym adresem RSS, ale zachęcam do zmiany na nowy adres :)

Od strony technicznej: blog jest hostowany na githubie z pomocą jekylla. Na początku miałem wątpliwości czy będzie to dobry pomysł. Jekyll jest niezwykle prosty w użyciu i ma przy tym spore możliwości, ale przy okazji traci się trochę elastyczności na rzecz wygenerowanego statycznego HTMLa. Tylko… tak naprawdę, po co mi coś więcej? Całego bloga trzymam w repozytorium gita, więc łatwo jest śledzić historię zmian. Mam darmowy hosting na githubie, więc nie muszę się już martwić o utrzymanie dla blogów jakiegokolwiek serwera. Posty mogę łatwo dodawać i edytować będąc offline. Wspaniała sprawa. :)

Layout bloga jest w tym momencie skopiowany ze strony Toma Preston-Werner (tak, to ten od githuba ;-) ze względu na to, że wszystko oprócz postów jest na licencji MIT, a dzięki temu mogłem praktycznie w 10 minut postawić bloga (więcej czasu zajęło przeniesienie postów z typo i mephisto, ale dzięki skryptom przygotowanym specjalnie dla jekylla, także ta operacja była prawie bezbolesna). Część postów poszło do kosza ze wzgłedu na ich przedawnienie (przez te kilka lat zmieniło się w railsach całkiem dużo i nikogo już pewnie nie obchodzi, że właśnie wyszły railsy w wersji 1.2-rc2), część postaram się oznaczyć jako deprecated (swoją drogą zrobienie prostego mechanizmu do oznaczania w ten sposób postów jest w jekyllu banalnie proste, skrobnę później o tym posta).

Na koniec muszę się jeszcze pochwalić. Prawdodpodobnie większość z was wie o tegorocznym Ruby Summer of Code. Dla tych którzy nie wiedzą: w tym roku żadne projekty związane bezpośrednio z Ruby nie dostały się na Google Summer of Code, więc społeczność (mocno wspierana przez Engine Yard, który z tego co pamiętam jest inicjatorem pomysłu) zorganizowała sobie własne Summer of Code. W 3 dni zebrano 100 tysięcy dolarów, co pozwoli sfinansować 20 projektów. Wśród owych 20 projektów znalazło się miejsce dla 2 Polaków:

Marcin Raczkowski – będzie pracował nad Identity Map dla ActiveRecord
Piotr Sarnacki (czyli skromny autor tego oto blogusia ;-) – będę pracował nad mountable apps i panelem admin do Railsów 3 (w zasadzie sytuacja jest trochę bardziej skomplikowana, ponieważ moje zgłoszenia zostały połączone ze zgłoszeniami Bogdana Gazy i pracujemy w jednym projekcie, przy czym ja jestem bardziej odpowiedzialny za część dotyczącą mountable apps, a Bogdan za rails-admin)

Pracę nad projektem zacznę prawdopodobnie w połowie czerwca i na blogu postaram się informować na bieżąco o postępach.

New address

2010-05-15T00:00:00-07:00

I haven’t written anything here for a while now. It was partially caused by a little mess in my blogs. I had 2 blogs with addresses blog.drogomir.com (for Polish blog) and drogomir.com/blog (for English blog)… I didn’t quite like addresses (hey? which one is in which language?) and keeping them on separate engines (typo and mephisto). Each time I wanted to start new post, I felt that I should change that right away. The problem is, I never had that much will to actually do something and after few minutes of checking solutions I usually stopped without any effects.

Finally I’ve merged my blogs and moved it to current address: piotrsarnacki.com.

The blog is hosted on github with help of jekyll. Jekyll is great so far. Its simplicity is impressive and I don’t have to worry about any server related issues. Layout is borrowed from Tom Preston-Werner’s site (layout is MIT licensed). It helped me start within a few minutes, but I will try to change it in a few days.

Although old RSS feed still works, I recommend to use new one: feeds.feedburner.com/piotrsarnacki. All the feeds available for this blog are:

feeds.feedburner.com/piotrsarnacki – English content
feeds.feedburner.com/piotrsarnacki-pl – Polish content (available on piotrsarnacki.com/pl)
feeds.feedburner.com/piotrsarnacki-all – All posts

I deleted some of the posts and marked some as deprecated. I try to not abandon that blog this time and post some new stuff.

On the side note. I have managed to be one of 20 students working on Ruby Summer of Code projects. I will work in the team with Bogdan Gaza on Rails 3 mountable apps and Rails admin panel (I will focus more on mountable apps part and Bogdan will work on rails admin panel). Carl Lerche and Erik Michaels-Ober will be our primary mentors.

I will try to post progress updates on this blog. Stay tuned!

Google chce przyśpieszyć internet

2009-06-26T00:00:00-07:00

Nie od dziś wiadomo, że prędkość ładowania strony ma wpływ na akcje użytkowników. Badania prowadzone miedzy innymi przez Yahoo, Google i Amazon wskazały, że zmniejszenie czasu ładowania strony ma bezpośredni wpływ na ilość akcji wykonanych przez użytkowników (wyszukiwań lub w wypadku Amazona zakupionych przedmiotów).

Google odpalił niedawno stronę, na której zachęca i uczy jak przyśpieszyć działanie naszych stron i serwisów

Dodatkowo Google wypuścił narzędzie Page Speed, które jest rozszerzeniem do Firebuga i podobnie jak YSlow pomaga zbadać stronę pod kątem prędkości ładowania się poszczególnych komponentów. Oba te narzędzia dostarczają od razu praktycznych porad i opisów pomagających zrozumieć jak zoptymalizować stronę. Dla mnie są to niezbędne narzędzia przy pracy z serwisami internetowymi. Do tej pory używałem głównie YSlow, ale przy następnych optymalizacjach na pewno skorzystam z Page Speed.

Jeżeli jeszcze nie znacie tych narzędzi, gorąco polecam zapoznanie się z nimi.

YUI 3 beta

2009-06-25T00:00:00-07:00

We wczorajszym poście na blogu YUI ogłoszono wersję beta YUI3.

YUI (Yahoo User Interface) jest frameworkiem javascript rozwijanym przez YAHOO, który dostarcza nie tylko niskopoziomowe funkcje pomagające przy pisaniu kodu javascript, ale też zestaw komponentów (takich jak różnego rodzaju okienka dialog, color picker, czy nawet bardzo dobry edytor WYSIWYG). YUI jest dojrzałą biblioteką używaną na stronach YAHOO, co zapewnia bardzo dobrą jakość. Sam team YUI to jedni z najlepszych specjalistów od frontendu – zachęcam do czytania wpisów na ich blogu

To co najbardziej przekonywało mnie do używania YUI, to fakt dostarczenia całego zestawu narzędzi do budowania interfejsów użytkownika w javascripcie. W przypadku np. jQuery lekko może denerwować bardzo duże rozstrzelenie poszczególnych bibliotek. Są oczywiście takie projekty jak jqueryUI, ale większość pluginów trzeba ściągnąć z innych źródeł, a ich kod często pozostawia wiele do życzenia. W przypadku YUI mamy zwarty zestaw komponentów, łatwy do rozszerzania i rozwijany przez specjalistów w celu wykorzystania na stronach odwiedzanych codziennie przez miliony internautów.

Z drugiej strony to co było banalne w jQuery często było ciężkie do uzyskania w YUI. A jak wszyscy wiedzą jeżeli chodzi o zabawę z DOM, animacjami i ajaxem z jQuery jest ciężko wygrać. Dlatego gdy używałem komponentów YUI w jednym z projektów, w którym przy okazji używałem jQuery, to do manipulacji elementów DOM używałem jQuery, a z YUI wybierałem tylko komponenty.

Wersja trzecia YUI może to zmienić. Zespół z Yahoo postanowił przepisać bibliotekę zupełnie od nowa z naciskiem na lekkość i szybkość. Najważniejsze zmiany

zmienione API do manipulacji DOM, czyli “jQueryzacja” – łańcuchy komend, proste funkcje typu addClass, remove, append itp.
ułatwiona praca z eventami
modularyzacja biblioteki

Najbardziej obiecująco wygląda ostatni punkt. Do tej pory poszczególne komponenty nie były modularne, co prowadziło do powtarzającego się kodu w różnych komponentach. Dodatkowo jeżeli ktoś chciał stworzyć Tooltip dziedziczący po Overlay, to musiał wykorzystać wszystkie elementy, które Overlay zawiera. Jest to oczywiście zbędne wykorzystywanie pamięci i Tooltip, który jest obecnie dostępny w YUI właśnie z tego powodu nie jest najlepszą możliwą implementacją.

W YUI3 poszczególne funkcjonalności są rozbite do modułów. Dlatego, żeby zbudować wspomniany wyżej tooltip nie trzeba dziedziczyć po Overlay, tylko zmiksować (czy to nie brzmi znajomo?) na przykład: moduł pozycjonowania i moduł animacji. Dodatkowo można wmiksować poszczególne moduły nie tylko do klas, ale także instancji poszczególnych obiektów. Jeżeli będzie to rzeczywiście działało tak fajnie jak mówią programiści z YUI (polecam obejrzeć video ze zlinkowanego wcześniej posta), to YUI3 na pewno zagości w moich projektach.

To co najbardziej denerwuje mnie obecnie w różnego rodzaju bibliotekach do jQuery czy prototype, to całkowite oderwanie poszczególnych bibliotek od siebie. Używam na przykład jqueryUI i żeby użyć tooltipa, muszę ściągnąć zupełnie inną bibliotekę, która jest napisana zupełnie inaczej i nie dzieli żadnego kodu z innymi bibliotekami (tutaj też wychodzi swoboda javascriptu, jeżeli ktoś próbował porównywać implementacje różnych bibliotek, to na pewno wie na ile różnych sposobów można zaimplementować te same funkcje). Jeszcze gorzej jest gdy trzeba napisać własne komponenty – lekkość jQuery i brak oficjalnych bibliotek pomagających w takich wypadkach jest dość dużą przeszkodą.

W tym momencie YUI team zachęca programistów do używania YUI3 w nowych projektach, szczególnie tych, które nie planują wykorzystywać dużej ilości widgetów obecnych w YUI2. Oficjalna wersja ma być dostępna w 3 kwartale tego roku. Rozwój można biblioteki śledzić tutaj

Cucumber and Celerity - testing unobtrusive javascript

2009-06-16T00:00:00-07:00

In the world of javascript and ajax web apps I often find that writing applications supporting both javascript enabled and disabled is hard. For the sake of simplicity and due to deadlines I often write only javascript version of some of the features. But there are many situations where both scenarios should be supported.

The most important parts of app, especially the ones that must be crawled by google, should be written with unobtrusive style. And here comes the problem… I rarely see javascript testing and till today I haven’t done it myself. Celerity and cucumber (with help of culerity) can solve this problem. Here is short guide introducing this technique.

I will use Cucumber, celerity (which is HtmlUnit wrapper with API compatible with watir) and culerity. Culerity is a proxy between celerity and your app. Celerity requires JRuby and probably your app need MRI or REE – culerity resolves this problem.

Let’s get started.

You need to install JRuby in order to run celerity. After installing and adding jruby to your PATH install celerity gem (probably as a root):

jruby -S gem install celerity

Now you can create rails app and configure the environment:

rails culerity-example
sudo gem install cucumber rspec rspec-rails haml
# add config.gem "haml" to environment.rb
gem install langalex-culerity --source http://gems.github.com
cd culerity-example
./script/generate cucumber
./script/generate rspec
# now edit database.yml and set database options
rake db:migrate
rake features
rm features/step_definitions/webrat_steps.rb # cause we will be using celerity

At this point you should have cucumber configured and you should be able to run “rake features” with output similar to:

0 scenarios
0 steps
0m0.000s

Let’s add some tests! You will need step definitions and hooks. Culerity provides some basic step definitions and hooks which you can generate with “./script/generate culerity” but I’ve changed them a bit for my needs, so you can find them on this example repository.

Copy those files to your app.

The first file is just rewrite of webrat steps and the second file adds hooks for firing celerity server and browser. Let me explain the hooks.rb file:

require 'culerity'
`mongrel_rails start -e cucumber -p 3001 -d`

Before do
  $server ||= Culerity::run_server
  $browser = Culerity::RemoteBrowserProxy.new $server, {:browser => :firefox}
  $browser.webclient.setJavaScriptEnabled(false) 
  @host = 'http://localhost:3001'
end

Before("@js") do |scenario|
  $browser.webclient.setJavaScriptEnabled(true)
end

at_exit do
  $browser.exit
  $server.close
  `mongrel_rails stop`
end

‘Before’ hooks are run before each scenerio. In first ‘before’ hook server and browser are set up and host is set to “http://localhost:3001” (change it if you want to run app on other address or port). Notice the line: $browser.webclient.setJavaScriptEnabled(false) – it disables javascript by default.

Second Before hook is fired only for scenarios tagged with @js tag. It will be useful for explicitly saying which scenarios should be tested with javascript.

I’ve also added lines to start mongrel before the tests and stop it at exit. It’s handy if you don’t want to run and restart mongrel manually

Now it is time to write some scenarios. File features/javascript.feature

Feature: Javascript
  In order to test javascript
  As a developer
  I need a way to run test scenarios with javascript enabled or disabled

  @js
  Scenario: With javascript
    Given I am on the homepage
    And I follow "Click me!"
    Then I should see "Javascript rocks!"

  Scenario: Without javascript
    Given I am on the homepage
    And I follow "Click me!"
    Then I should see "I am also working without javascript!"

Both scenerios rely on “Click me!” link but have different expectations. ~~To run those tests start mongrel (or any other web server):~~

mongrel_rails start -e cucumber -p 3001 -d

~~This will fire mongrel in background on port 3001.~~
It is not necessary as mongrel control commands are in hooks.rb file

It’s best to operate on 2 console tabs while using celerity. One of the big drawbacks of using it, is lack of displaying rails exceptions. Because of that I run cucumber on one tab and “tail -f log/cucumber.log” on the other – I can see errors in the log without opening the browser.

Let’s run tests:

rake features

Of course both tests should fail with

Unable to locate Link, using :text and /Click me!/

and rails error in log file:

ActionController::RoutingError (No route matches “/” with {:method=>:get}):

Now we can fix it. We need some controller to show the link:

script/generate rspec_controller home

Add

map.root :action => “show”, :controller => “home”

to routes file.
Next copy app/views/layouts/main.html.haml (it just yields action and includes jquery.js and application.js) and jquery.js

You need to also set layout for home controller:

layout ‘main’

And here comes html and javascript.
app/views/home/show.html.haml

= link_to "Click me!", "?clicked=1", :id => "click_me"

#text
  - if params[:clicked]
    I am also working without javascript!

It displays a link and a text if params[:clicked] is present. So after clicking on that link page will be reloaded with parameter clicked=1 and the text will be displayed.

Let’s check if it’s passing:

mongrel_rails restart; rake features

We need to restart mongrel before “rake features” in order to load changes because of “cache_classes = true”. It’s one of the drawbacks of using this method, but I’m sure that someone will find out better way to do that.

If you did everything properly the second scenario should pass now. We’re green! :D

Add javascript code to your application in order to make the second scenario pass:

jQuery(function() {
  $("#click_me").click(function() {
    $("#text").html("Javascript rocks!");
    return false;
  });
})

Now both scenarios should pass.

To sum up, now you should be able to:

configure rails app with cucumber and celerity
specify how your tests should be run by placing @js tag on top of javascript scenarios
test unobtrusive javascript with ease

TODOs:

~~figure out better way to reload rails app while testing~~
provide better error explanations in cucumber with celurity to test without tailing logs

Cheers!

Additional resources

Celerity ajax examples by Alvin Schur

Fixing safe_erb with memcached improved

2009-05-12T00:00:00-07:00

Ruby has many structures that are weird and dangerous to some programmers that works with Java or other more “traditional” OO languages. For me it’s great and metaprogramming capabilities makes ruby killer in case of DSLs, nice looking APIs and avoiding repeating yourself.

But many problems that are solved with alias_method_chain or method_missing can be solved easier without the code smell. I sometimes find myself designing some weird complex solutions and then, after looking at it saying: “Hey! Why not just use OO features!”. I encourage everybody to look critically at every piece of your code that seems to be overkill and can be replaced with standard OO design.

One of examples is fixing memcached and safe_erb duet with alias_method_chain I don’t know if this solution worked in older versions of rails, but in 2.3 I got stack level too deep error. After some thinking I’ve just created subclass of MemCacheStore:

And then you can simply set it as cache store: config.cache_store = :my_mem_cache_store

And that’s it, no alias method chain :)

Co nowego w Rails3?

2009-05-03T00:00:00-07:00

Ponad 4 miesiące temu światem Ruby’iego zatrzęsła wiadomość o połączeniu się 2 popularnych frameworków – Ruby on Rails i Merba. Dzisiaj, tylko kilka dni dzieli nas od ujrzenia pierwszych aplikacji, które będą napisane w Rails 3. Carl Lerche (twórca między innymi routera do merba) oraz Yehuda Katz na tegorocznym RailsConf będą mówić o Rails3 i mountable apps.

Na stabilną wersję będzie trzeba jeszcze trochę poczekać, ale trzymam kciuki, żeby na RailsConf rzeczywiście udało im się pokazać działającą aplikację.

W tym poście chciałbym krótko opisać to co ma się znaleźć w Rails 3. Z niemałą niecierpliwością śledzę newsy i doniesienia o nowych railsach i nie mogę się już doczekać niektórych usprawnień.

ActionORM (wcześniej ActiveORM)

Zwolennicy Merba bardzo podkreślają w swoim frameworku niezależność od konkretnych technologii. Było to reklamowane głównie jako “ORM agnosticism” czyli możliwość podpięcia do Merba jednego z wielu “ORMów” (DataMapper, ActiveRecord, Sequel) w porównaniu do Railsowej monolityczności w postaci jednego słusznego ActiveRecorda.

Jaki właściwie jest problem w używaniu innego ORMa w naszej aplikacji? Na poziomie modeli i kontrolerów nie ma to z reguły większego znaczenia. Przecież Railsów nie obchodzi czy klasa w katalogu app/models dziedziczy po ActiveRecord::Base, czy dołącza moduł: include DataMapper::Resource

Kłopot zaczyna się kiedy chce się korzystać z wielu helperów, które jako argument przyjmują obiekt ActiveRecord. Najprostszy przykład:

<% form_for @article do |f| %>
  <%= f.text_field :title %>
<% end %>

Jeżeli @article nie jest obiektem AR, to poprawność działania tej metody zależy tylko od tego czy interfejs danego ORMa tutaj używany jest taki sam. W tym akurat przypadku problemem może być sprawdzanie błędów w walidacji. Railsy domyślnie dodają wrapper do pól z błędami, więc jeżeli ORM ma inny interfejs do pobrania informacji o błędach, to metoda po prostu nie zadziała.

W tym momencie jest to w Railsach zrobione z użyciem alias_method_chain i jeżeli obiekt nie ma zaimplementowanej metody errors, to tag pozostaje niezmieniony, więc można samemu dołączyć swoją własną implementację lub dodać potrzebne metody do modelu. Jednak wszyscy chyba się zgodzą, że nie jest to najbardziej elegancki sposób.

Jeżeli chodzi o Merba, to sprawa wygląda tylko trochę lepiej niż w railsach. Jest co prawda wsparcie dla 3 najpopularniejszych ORMów, ale implementacja nie pozwala na łatwe dodanie kolejnych ORMów bez grzebania w kodzie. Jeżeli ORM, którego chcesz używać ma interfejs zgodny z DataMapperem, Sequelem lub ActiveRecordem, to wszystko jest ok, ale jeżeli jest to coś innego, to masz problem.

Odpowiedzią na to ma być ActionORM. Czym jest ActionORM? Jest to proste proxy dla obiektów. ActionORM udostępnia API takie jak ActiveRecord (dzięki temu w kodzie railsów nie będzie trzeba wiele zmieniać). W prostych słowach ActionORM ma sprawić, że obiekty innych ORMów będą wyglądały jak obiekty ActiveRecord (czyli klasyczne wykorzystanie duck typing)

Tutaj jest przykład proxy dla Datamappera

Różnice są jak widać niewielkie, ale podejrzewam, że będzie można dodać więcej metod, które się różnią pomiędzy implementacjami (oczywiście w granicach rozsądku, sprowadzanie całego interfejsu do jednego przypadku było by pozbawione sensu, chodzi o proste operacje, które każdy ORM ma rozwiązane podobnie, ale różni się API).

Rack Middleware

Railsy od jakiegoś czasu wykorzystują w pełni dobrodziejstwa Rack. Co więcej, różne części frameworka są zaimplementowane jako rack middlewares. Kontroler, router, obsługa sesji i wiele innych rzeczy to teraz po prostu kolejne middlewares (przepraszam za te anglojęzyczne wstawki, ale naprawdę nie mam pojęcia jak to ładnie przetłumaczyć). Dzięki temu i dodaniu Rails metal aplikacje są coraz bardziej modularne.

Programiści railsów dążą w tej chwili do jeszcze szerszego wykorzystania racka. Wszystko to idzie w stronę jak najłatwiejszego połączenia komponentów różnego typu. Na przykład możliwość podłączenia do routera kontrolerów railsowych, aplikacji sintatry i aplikacji merba (jako jedną aplikację oczywiście).

Optymalizacja i refaktoryzacja

Największą i najlepszą według mnie zmianą w railsach jest refaktoryzacja kodu ActionPack. Na czym ona polega? W bardzo prostych słowach: stworzony jest AbstractController, z którego dziedziczyć będą inne kontrolery, a w samym kodzie jest zastosowana dużo większa enkapsulacja. Jakie to ma znaczenie dla użytkowników railsów? Będzie istniał jeden interfejs dla wszystkich kontrolerów, dzięki czemu na przykład ActionController i ActionMailer będą mogły współdzielić funkcjonalność (żeby nie iść daleko, dopiero niedawno do mailera dodana została obsługa layoutów). Bardzo łatwe będzie też dodanie Parts znanych z merba (PartsController również dziedziczy w Merbie z AbstractControllera).

W chwili obecnej podobną funkcjonalność do Merb Parts udostępniają Rails Cells, ale nie jest to rozwiązanie idealne (implementacja jest zagmatwana, w cellach widoczne są zmienne instancji z kontrolerów i innych celli, podejrzewam, że jest to wolniejsze niż parts).

Co jeszcze? Yehuda Katz wziął się między innymi za optymalizację callbacków, czy bloku respond_to. Polecam również inne artykuły na temat refaktoryzacji na jego blogu.

Na pewno szybszy będzie też router. W chwili obecnej największym problemem jest to, że router generuje bardzo dużo metod (wszystkie metody _url i path), co w rezultacie przyczynia się do bardzo wolnego startu aplikacji. W czasach mongreli nie miało to dużego znaczenia, bo aplikacje były odpalane raz i tylko sporadycznie restartowane. Teraz kiedy na wielu serwerach zainstalowany jest modpassenger, czas startu aplikacji jest dużo ważniejszy – instancje, które nie dostają requestów przez 5 minut (domyślne ustawienie) są wyłączane dzięki czemu nie zajmują zasobów.

Nowy router można przetestować już teraz. Po więcej odsyłam na the merbist

Mountable apps

Jest to jedna z tych rzeczy, na które czekam w Railsach 3 najbardziej. Dosłownie liczę godziny do rails conf i prezentacji na ich temat (mam nadzieję, że będą nagrywane, bo niestety nie miałem wolnych kilku tysięcy złotych, żeby się pojawić osobiście na konferencji ;-).

Jakieś namiastki mountable apps są już dostępne w postaci Rails Engines i Merb Slices. Jest to jakieś rozwiązanie, ale na pewno dalekie od idealnego. Żeby skorzystać z którejś z tych opcji trzeba napisać specyficzny rodzaj aplikacji, a każde z tych rozwiązań jest w niektórych miejscach niedopracowane. Celem mountable apps będzie możliwość łatwego połączenia 2 aplikacji bez żadnych zmian w kodzie.

API dla pluginów

Jedną z rzeczy, którą wypromował Merb jest publiczne i prywatne api. Dzięki temu pisanie pluginów nie wiąże się tam z używaniem alias_method_chain i ogólnie pojętym monkey patchingiem na każdym kroku. A jeżeli czegoś nie da się zrobić używając tylko publicznego api, to jest to bug. Jest to chyba jedna z trudniejszych rzeczy w całej refaktoryzacji. Nie wiadomo dokładnie czego będą potrzebować twórcy pluginów, niektóre metody trzeba będzie dopiero stworzyć.

Ogromnym plusem takiego podejścia jest to, że twórcy frameworka nie muszą się martwić o prywatne metody, ważne żeby publiczne API się nie zmieniało. Dzięki temu pluginy napisane zgodnie z wytycznymi, czyli nie używając prywatnego API nie będą się wysypywały na każdej kolejnej wersji (co bardzo często można zaobserwować w tym momencie), a jeżeli coś się zmieni w publicznym API przy okazji większych zmian, to twórcy pluginów będą mogli się o tym łatwo dowiedzieć bez śledzenia commitów na githubie.

Podsumowanie

Jestem zdania, że połączenie merba i railsów to jedna z najlepszych rzeczy, która mogła się przytrafić programistom webowym. Railsy będą szybsze, bardziej modularne i łatwiejsze w rozszerzaniu. Tylko czekać na wyniki refaktoryzacji :)

Postaram się w najbliższych tygodniach pisać o tym co dzieje się z Railsami3, jak idą prace i co jeszcze ciekawego będzie można zobaczyć.

My git workflow

2009-04-26T00:00:00-07:00

I know that this post may be obvious for experienced git users, but it may be useful for some of you.

Github has added default branch picking recently. It’s great, as you don’t have to use master branch as your main branch. I usually have three “main” branches in my repo – production, staging and development.

The main point of it is to have separate branch for each environment (sometimes I skip staging, but it’s often wise to have some point between development and production). My main problem with git (or maybe rather with my lack of knowledge about git) in the very beginning of using git was to learn how to use branches efficiently. After some time with git I’ve noticed that it’s best to keep each fix or idea in separate branch.

One crucial thing is to inherit from production when it’s possible. Let’s say you have those main branches I mentioned before. There is a bug #345 in bug tracker and you want to fix it and merge into production after showing results to the client. The best way is to begin with production:


git checkout -b bug345 production

It will create new branch bug345 with production as a parent branch. Now:


# fix the bug
git commit -m "Fixed the nasty bug #345"

Sometimes client doesn’t need reviewing the changes but when he does you should have ability to show it and merge it to the production branch later.


git checkout staging
git merge bug345
# deploy staging

After the client approval of your solution you can merge the bugfix to the production branch:


git checkout production
git merge bug345
# deploy production
# you can remove bug345 branch now
git branch -d bug345

The most important thing in this process is to always inherit from production branch, unless you need changes from other branches. Otherwise you could merge some needless junk from other branches or have to cherry-pick individual commits. With above solution everything is clean and you are sure that that you will merge only what you need.

Hope it will help :)

JSON-P support for Apache upload progress

2009-02-10T00:00:00-08:00

Just a quick note about new feature added to apache upload progress and jquery upload progress libs.

Ron Evans aka deadprogrammer has added support for JSON-P in this commit. What does it mean? Cross domain requests are now possible, so if you need such a functionality pull the newest changes.

Here is Ron’s description from README:

- JSON-P Support

You can also request progress updates by using JSON-P, if you are uploading the file from a different domain or subdomain than the web server that is handling your original request. Adding a “callback=yourCallbackFunction” parameter to your request to the progress server will activate this functionality.

For example, a request like:
http://uploads.yourdomain.com/progress?callback=jsonp123&X-Progress-ID=1234

Would return the JSON-P function:
jsonp123(new Object({ ‘state’ : ‘uploading’, ‘received’ : 35587, ‘size’ : 716595, ‘speed’ : 35587 }));

The normal JSON request:
http://www.yourdomain.com/progress?X-Progress-ID=1234

Would return the JSON data:
new Object({ ‘state’ : ‘uploading’, ‘received’ : 35587, ‘size’ : 716595, ‘speed’ : 35587 })

Remember to update jquery upload progress also, to use jsonp.

Enjoy :)

Refaktoryzacja Railsów

2009-01-03T00:00:00-08:00

Niestety nie będzie to wpis o tym jak refaktoryzować swoją aplikację, ale raczej post o refaktoryzacji samego frameworka w ramach przygotowań do Rails 3.

Railsy pożarły mózg Merba i posiądą jego tajemne moce (zachęcam do wysłuchania tego podcastu, chłopaki od railsenvy genialnie mówią o tym co się dzieje w świecie railsów) – o tym już każdy na pewno wie. Czy to dobrze? Oczywiście, że tak :)

Jeżeli ktoś dalej ma problemy z tą decyzją (podejrzewam, że może tak być w wypadku fanów merba), polecam prezentacją Living with legacy software wygłoszoną przez Davida Heinemeiera Hanssona – nie jest w żaden sposób bezpośrednio związana z połączeniem, ale zmienia podejście do aplikacji i ich kodu.

Ale nie o to, nie o to, nie o to

Yehuda Katz ostro wziął się do pracy jeszcze podczas świąt i co jakiś czas wrzuca na bloga informacje o tym jak refaktoryzuje i jakie ma plany wobec Railsów. Informacje traktujące o projektowaniu, refaktoryzacji i architekturze ciężko jest znaleźć w sieci, więc gorąco polecam śledzenie tego co pisze Yehuda – do tej pory można przeczytać między innymi o enkapsulacji ActionView i ActionController czy o optymalizacji respond_to. Dodajcie sobie tego bloga do czytnika, naprawdę warto.

Co najlepsze, wiele z tych zmian dotyka tylko wewnętrznej implementacji railsów, więc można liczyć, że będą one dostępne dla ruby on rails 2.3.0.

To self or not to self?

2008-11-15T00:00:00-08:00

Czasami przeglądając kod różnych aplikacji można zauważyć kawałki wyglądające mniej więcej tak:

  attr_accessor :price

  def total_price
    p = items.inject(0) {|sum, item| sum + item.price }
    # więcej kodu
    p
  end

W prawdziwej aplikacji można to zobaczyć na przykład w Spree (użycie tot zamiast total)

p oznacza tutaj zapewne price, ale autor kodu intuicyjnie stwierdził, że pisząc “price =”, zamiast stworzenia nowej zmiennej przypisze wartość na atrybut price.

Rzeczywiście jest to intuicyjne i całkiem bezpieczne, ale zupełnie niepotrzebne. Spokojnie i bez żadnego problemu można użyć price. Dlaczego?

W rubim można opuścić słowo self jeżeli chodzi o odczytanie wartości metody. Jeżeli więc bez zadeklarowania zmiennej price ktoś napisałby puts(price), to ruby zinterpretowałby to jako chęć wyświetlenia self.price. Inaczej jest z zapisywaniem. Jeżeli wywołana jest metoda price=, to ruby stworzy nową zmienną.

Na przykład taki kod:

  class Product
    attr_accessor :price

    def initialize(price)
      self.price = price
    end

    def do_something_with_price
      price = 10
      puts price
      puts self.price
    end
  end

  p = Product.new(20)
  p.do_something_with_price

Wypisze:

10
20

Na koniec napiszę tylko, że mam mieszane uczucia co do korzystania z tych właściwości języka. Z jednej strony nie lubię jak w kodzie pałętają się skrótowe nazwy zmiennych, ale z drugiej strony taki zapis pokazuje, że chodzi nam o coś innego niż self.costam.

Ja z reguły staram się nie skracać nazw w takich wypadkach. Jakie jest wasze zdanie?

Named scope

2008-10-03T00:00:00-07:00

W railsach od jakiegoś czasu można używać named_scope. Jest to bardzo fajny mechanizm umożliwiający łatwiejsze skonstruowanie zapytania używając wcześniej zdefiniowanych metod. Wcześniej był dostępny jako plugin has_finder.

Wygląda to mniej więcej tak:

  named_scope :active, :conditions => { :active => true }
  named_scope :paid, :conditions => { :paid => true }
  named_scope :recent, lambda { { :conditions => ['created_at >= ?', 1.week.ago] } }

Po zdefiniowaniu takich sope’ów (macie pomysł jak to spolszczyć?) można ich używać w ten sposób (zakładam, że scope’y zostały zadeklarowane w modelu Product):

  Product.active.paid.recent

Jak można łatwo zauważyć, scope’y można łączyć w łańcuchy. Dzięki takiej konstrukcji otrzymujemy prosty i treściwy kod, który łatwo zrozumieć. Teraz coś lekko trudniejszego:

  named_scope :in_category, lambda { |category| { :conditions => { :category_id => category } } }
  
  # i użycie
  Product.active.recent.in_category(category)

O co chodzi? Jako 2 argument można przekazać lambdę, która zostanie wywołana przy użyciu scope’a i powinna zwrócić Hash.

Ale to nie są jedyne zastosowania scope’ów. Można do nich przekazać też inne parametry, które może przyjąć metoda find.

Na przykład order, offset i limit:

  named_scope :order, lambda { |*args| { :order => args.first || "created_at DESC" } } 
  named_scope :offset lambda { |offset| { :offset => offset } } 
  named_scope :limit, lambda { |*args| { :limit => args.first || 10 } } 
  
  # i użycie:
  Product.active.order("id DESC").offset(10).limit

W pierwszym i trzecim scope’ie zastosowałem trick, który pozwala na użycie zdefiniowanej wartości domyślnej w razie gdy żadna nie zostanie podana. `*args` pakuje argumenty do tablicy. Jeżeli args.first zwróci nil, to znaczy, że tablica jest pusta, czyli nie zostały podane żadne argumenty i trzeba zaaplikować wartość domyślną.

Coś jeszcze? Fajnie by było, żeby można było sortować nie tylko po wartościach z jednej tablicy… a do tego wypadałoby użyć joins/include. Nic prostszego.

  named_scope :joins, lambda { |joins| { :joins => joins } } 
  
  # a teraz można tak:
  Product.active.joins(:user).order('users.email')

How cool is that?

No i na koniec coś co ostatecznie przekonało mnie, że named_scope jest genialnym wynalazkiem. Jeżeli ktoś robił kiedyś formularze, w których można wybrać kilka opcji i na ich podstawie trzeba zbudować zapytanie, zapewne wie, że jest to nieco upierdliwe. Używając `named_scopes` można to zrobić bardzo łatwo.

Ryan Bates napisał plugin scope_builder, dzięki któremu można to zrobić jeszcze łatwiej. Przypuśćmy, że mamy formę, w której można zaznaczyć kilka pól i po ich wysłaniu należy na ich podstawie pobrać odpowiednie rekordy z bazy.

  # przygotowujemy listę parametrów, które użytkownik może ustawić
  parameters = [:active, :paid, :recent, :title]
  # Tworzymy scope
  @products = Product.scope_builder
  # teraz można sprawdzić, które pola zostały zazanczone
  parameters.each do |param|
    @products.send(param) if params[param]
  end
  # na koniec można na przykład dodać paginację
  @products = @products.paginate(:per_page => 10, :page => params[:id])

Dla mnie genialne. :) Można dzięki temu łatwiej tworzyć zaawansowane wyszukiwanie, sortowanie i inne tego typu rzeczy.

Oczywiście najlepiej jest zamknąć taki kawałek kodu jako metodę modelu, zgodnie ze skinny controller, fat model, ale to pozostawię jako ćwiczenie ;-)

Po dłuższej przerwie

2008-09-30T00:00:00-07:00

Przez jakiś czas nie pisałem nic na blogu. Długo zbierałem się do napisania czegokolwiek, od dawien dawna miałem przetłumaczyć wpisy na moim angielskojęzycznym blogusiu. Tak bardzo mi się nie chciało, że jak tylko siadałem do kompa z zamiarem przetłumaczenia czy napisania czegoś podobnego coś mnie odrzucało.

Dlatego, żeby więcej się nie męczyć podsumuję ten temat i podam linki – większość ludzi, którzy tutaj trafią i tak na pewno zna angielski.

Napisałem apache upload progress module do apacha. Moduł, dzięki któremu można pobrać dane o wysyłanych plikach. Format odpowiedzi oparłem o moduły tego typu dla nginxa i lighttpd dlatego jeżeli wcześniej ktoś używał któregoś z nich, przesiadka będzie całkowicie bezbolesna. Sam używałem wcześniej nginx upload progress (głównie dlatego napisałem moduł do apacha) i po przerzuceniu aplikacji na apacha z nowym modułem nie trzea było zmieniać ani jednej linijki. Na angielskim blogu zamieściłem opis instalacji i konfiguracji modułu.

Żeby można było w miarę łatwo używać modułu napisałem także pluginy do "prototype’a"http://github.com/drogus/prototype-upload-progress/tree/master i jquery, które obsługują pasek postępu. Przykłady są w repozytoriach, umieściłem je także na serwerze dla obczajenia w akcji. Popełniłem także tekst o tym jak hackowałem plugin, żeby działał w safari – safari w tym momencie nie było wcale lepsze od IE… nawet powiedziałbym, że gorsze. Swoją drogą plugin nie działa w najnowszej operze (działał w 9.5 zdaje się), więc jeżeli ktoś ma chwile czasu i mógłby sprawdzić dlaczego i co można zrobić, żeby działał, to może wnieść swój wkład w rozwój (dodam, że nie jest to ta sama kwestia co dla safari, bo to już sprawdziłem) – nie sądzę żebym miał teraz czas sam na tym siedzieć.

Dodatkowo napisałem jeszcze tekst o tym jak można fajnie uatrakcyjnić aplikację używając jQuery. Część pierwsza. Część druga będzie jak będę miał więcej czasu, czyli pewnie niezbyt szybko.

Pozdrowienia ze słonecznego Wrocławia, gdzie mam zamiar mieszkać przez najbliższy rok (miła odmiana od Pruszkowa :).

Tweaking Rails app with jQuery, part I

2008-07-03T00:00:00-07:00

Quick links:

completed demo (demo is reseted every few hours)
sources of application on github (or download tarball)

I’m in the train from Zgorzelec to Warsaw returning from my girlfriend’s place. Polish trains are like turtles, so I will have pretty much time for writing ;-)

I’ve wrote (or maybe it’s better to say copy&paste) little rails app like in Mike Clark’s tutorial for attachment_fu. A few months ago there was Mugshots exhibition in Yours Gallery in Warsaw based on work of Peter Doyle. I saw it with Kathleene, she took some pictures. Great! I have material to fill my new app, what else could I possibly dream of?! (yeah… macbook, but it’s obvious ;-).

Now you can admire my hard work: mugshots.drogomir.com/js/no-javascript/mugshots/

But wait… It’s not so cool… where are all those shiny javascript effects? Don’t worry. I will show you how to spice this dish.

We will need:

I’ve pushed application to github, so you can see entire code. Clone it or grab the tarball

There is one thing that is not straight forward. @main_js variable in app/views/layouts/main.rhtml:


<%= javascript_include_tag @main_js %>

It’s there for changing javascript file loaded. When url is app.com/js/some_javascript_file/mugshots, @main_js should be “some_javascript_file.js”. I’ve done this to have possibility to show you app with different javascript files without changing the code. See routes and mugshots_controller.rb to find out how it was done (or run “rake routes” in app dir to see routes).

Lets begin.

What to do first? It’s all about uploading files, so I would add upload progress bar to form in mugshots.drogomir.com/mugshots/new. To implement it you will need some kind of server module:

You have to install and enable one of the above modules to make progress bar work.

Then add some javascript to applications.js. This example is using “LightBoxFu”: – little script that I wrote to show progress bar as an overlay. It’s based on Riddle’s work – all positioning is in CSS (except expressions for IE) so it’s really light and fast. Ideal for such a task. If you don’t like lightBoxFu you can use any other form of displaying message (you can use some other lightbox with displaying code function or even blockUI plugin).


// handy trick, if we can't use $ beaceuse jQuery.noConflict
// was used, jQuery is passed as argument in document ready
// so we can name it $
jQuery(function($) {
  // add upload progress to our form
  $('form.progress').uploadProgress({
    start:function(){
      // after starting upload open lightBoxFu with our bar as html
      $.lightBoxFu.open({
        html: '<div id="uploading"><span id="received"></span><span id="size"></span><br/><div id="progress" class="bar"><div id="progressbar">&nbsp;</div></div><span id="percent"></span></div>',
        width: "250px",
        closeOnClick: false
      });
      jQuery('#received').html("Upload starting.");
      jQuery('#percent').html("0%");
    },
    uploading: function(upload) {
      // update upload info on each /progress response
      jQuery('#received').html("Uploading: "+parseInt(upload.received/1024)+"/");
      jQuery('#size').html(parseInt(upload.size/1024)+" kB");
      jQuery('#percent').html(upload.percents+"%");
    },
    interval: 2000,
    /* if we are using images it's good to preload them, safari has problems with
       downloading anything after hitting submit button. these are images for lightBoxFu
       and progress bar */
    preloadImages: ["/images/overlay.png", "/images/ajax-loader.gif"]
  });
});

And some styling for progress bar:


  #progress {
  margin: 8px;
  width: 220px;
  height: 19px;
}
#progressbar {

  background: url(‘/images/ajax-loader.gif’) no-repeat;

  width: 0px;

  height: 19px;

}

That’s it, just add “progress” class to your form and progress bar is working:


<% form_for(:mugshot, :url => mugshots_path, 
                      :html => { :multipart => true, :class => "progress" }) do |f| -%>

Uploading files looks much better right now, check it here: http://mugshots.drogomir.com/js/progress/mugshots/new

So what now? I find the “add photo, click New mugshot, add photo” scenerio annoying. We could add more than one file on each submit. For that we will use jquery.MultiFile.js. This one is a bit tricky, cause we will need to tweak code handling uploads also.

Javascript enabling mutlifile:


jQuery(function($) {
  $('.multi-file').each(function() {
    // change name of element before applying MultiFile
    // so array of files can be send to server with mugshot[uploaded_data][]
    $(this).attr('name', $(this).attr('name') + '[]');
  }).MultiFile();
});

We must also add “multi-file” class to file field:


<%= f.file_field :uploaded_data, :class => 'multi-file' %>

From javascript point of view that’s all. Let’s see how uploaded photos are handled by rails app:


@mugshot = Mugshot.new(params[:mugshot])

So mugshot.uploaded_data is filled with data from params[:mugshot][:uploaded_data]. Good for one file. But with array of files we should create Mugshot for each file. I would add a method in model:


  def self.handle_upload(mugshot_params)
    # array for not saved mugshots
    mugshots = []
    if mugshot_params[:uploaded_data].kind_of?(Array)
      mugshot_params[:uploaded_data].each do |p| 
        unless p.blank?
          mugshot = Mugshot.new(:uploaded_data => p)
          mugshots << mugshot unless mugshot.save
        end
      end
    else
      mugshot = Mugshot.new(mugshot_params)
      mugshots << mugshot unless mugshot.save
    end
    mugshots
  end

and slightly change controller code:


  def create
    @mugshots = Mugshot.handle_upload(params[:mugshot])
      
    # if @mugshots is empty there are no errors
    if @mugshots.blank?
      flash[:notice] = 'Mugshot was successfully created.'
      redirect_to mugshots_url
    else
      render :action => :new
    end
  end

Only one problem left. Validation.

Easiest way is to change error_messages_for:


<%= error_messages_for :object => @mugshots %>

It works. But suppose you are uploading 3 files and 2 of them are too big. You will end with:

Size is not included in the list
Size is not included in the list

Which one was added? Some lottery here…

I would tweak attachment_fu error messages a bit. By default it uses validates_as_attachment method which simply adds:


  validates_presence_of :size, :content_type, :filename
  validate  :attachment_attributes_valid?

Instead validates_as_attachment we can isert our new code:


  validates_presence_of :size, :content_type, :filename, :message => Proc.new { |mugshot| "can't be blank (#{mugshot.filename})" }
  validate  :attachment_attributes_valid?
  
  def attachment_attributes_valid?
    [:size, :content_type].each do |attr_name|
      enum = attachment_options[attr_name]
      errors.add attr_name, "#{ActiveRecord::Errors.default_error_messages[:inclusion]} (#{self.filename})" unless enum.nil? || enum.include?(send(attr_name))
    end
  end

Now it’s a lot more readable:

Size is not included in the list (filename.jpg)
Size is not included in the list (filename1.jpg)

Submit form looks better now, but viewing files is still ugly. Maybe we could add some lightbox? No problem:


$('#mugshots li a').lightBox();

I used that lightbox cause I had it configured for my previous rails apps, but pick your favourite one, as there are gazilions of them.

This is first step of tweaking our app. Javascript is in step1.js file: mugshots.drogomir.com/js/step1/mugshots/new

What now? User can upload many files at one submit and see progress bar. What else do we need? Ajax! My preciousssss…

As all children know, XMLHttpRequest can’t upload files. What a shame… our new tweaked mugshots app is all about uploading files. Although you can’t do it with XHR, there is a way to imitate it. It is obtained by creating an iframe and uploading files to it.

Luckily Mike Malsup has done hard work for us writing jQuery form plugin.

First, we need our form. I would place it instead “New mugshot” link. Link has id=“new_mugshot_link”, so this piece of code will replace it with form:


  /* create upload form with multifile instead of new mugshot link */
  var form = $('<form method="post" enctype="multipart/form-data" class="progress ajax" action="/mugshots">');
  var label = $('<p><label for="mugshot_uploaded_data">Upload mugshot: </label></p>');
  var input = $('<input type="file" class="multi-file" id="mugshot_uploaded_data" size="30" name="mugshot[uploaded_data]"/>');
  label.append(input).appendTo(form);
  form.append('<p><input type="submit" value="Create" name="commit"/></p>');
  if (typeof(AUTH_TOKEN) != "undefined") form.append('<input type="hidden" value="'+AUTH_TOKEN+'" name="authenticity_token"/>'); 
  $('#new_mugshot_link').replaceWith(form);

Our form has to be send to an iframe, so we have to apply ajaxForm to it. After replacing link with form we can’t figure out when form is actually appended to DOM. To be sure that form is there, we can use livequery. It will fire callback function when ‘form.ajax’ will be available:


  $('form.ajax').livequery(function() {
    $(this).ajaxForm({iframe: true, success: function (responseText, statusText, form) {
      var url = $(form).attr('action');
      /* get new files */
      $.ajax({
          url: url,
          dataType: "script",
          beforeSend: function(xhr) {xhr.setRequestHeader("Accept", "text/javascript");},
	  /* we need to update lightbox array to include new files */
          complete: function() { $('#mugshots li a').lightBox(); }
      });
    }});
  });

When new form tag with class “ajax” will be available callback function will be run. iframe option tells form plugin to add hidden iframe (it will handle file upload).

The above code has ajax call to “/mugshots” url which will run index.js.erb (RJS), so we will need one:

app/views/mugshots/index.js.erb


  jQuery('#mugshots').html(<%= js render(:partial => 'mugshot', :collection => @mugshots) %>);

to handle it we need to use respond_to:


  respond_to do |format|
    format.html
    # layout => false is here beaceuse without it rails are looking
    # for layouts/index.js.erb
    format.js { render :layout => false }
  end

Normally I try not to use RJS to keep all my javascript (and ajax) logic in javascript files, but in case of images it isn’t so esay. I will write about it and about javascript templating systems in one of the next posts.

Take a look at: mugshots.drogomir.com/js/step2/mugshots Doesn’t it look nice?

There is only one problem :) No ajax validation. After submitting files, javascript can’t get any info about errors or uploaded files beaceuse it is treated like normal html request and response is loaded in an iframe. How to fix it? I’ll write about it in the next post. :)

Upload progress script with safari support

2008-06-30T00:00:00-07:00

Quick links:

Source on github for jquery version: http://github.com/drogus/jquery-upload-progress
Source on github for prototype version: http://github.com/drogus/prototype-upload-progress
jQuery demo: http://drogomir.com/files/blog/jquery-upload-progress/example
Prototype demo: http://drogomir.com/files/blog/prototype-upload-progress/example
Installing apache upload progress

Recently I’ve wrote about apache upload progress module. I work mainly on linux and I haven’t check my scripts on safari. It was working even on IE, what possibly could be harder to obtain? ;-) Some people reported that demo is not working on safari and Michele resolved the problem (thanks Michele :).

Solved! The only thing to do was to open WinXP on VirtualBox and check it on Safari 3. Michele’s solution worked well, but to make it work there must be html page with given structure and javascript. I like “one file” easy to use scripts without any issues with static files :) So what? Create an iframe dynamically, load scripts dynamically, one file, the only thing that user will have to set is path to scripts.

With Safari? No, not really. I’ve wrote it in a few minuttes and checked in firefox. It worked, great, now safari. Nope….

Although Safari have great CSS support, it is really terrible with Javascript. WYSIWYG, javascript history, ajax issues, now the upload progress and iframes. In edge case libraries I often see hacks for IE and safari mainly.

Luckily Apple released Windows version of safari and I can check my scripts and pages on safari. Good… developer tools don’t work, though… I had to do some alert-like IE style debugging ;-) After many hours of trying new more and more insane ways to create iframe and load scripts into it, code with document.write() worked!

Check the commit on github. Lines 18-22 especially. And 28-line issue with safari not waiting to load previous script.

It’s really sad that after working on firefox with firebug or opera with developer tools I have to fight with Safari which is supposed to be modern browser. I know that on Mac developing scripts for safari is easier, thanks to working debug tools, but hey! I work on Linux. Why do I have to run Safari on Wine or VirtualBox, lacking debug tools? It’s a pain. I feel like I’m working on explorer…

~~I will add prototype version~~ and possibly some usage page shortly (for know look at the demo code).

Upload progress bar with mod_passenger and apache

2008-06-18T00:00:00-07:00

UPDATE: I found 2 bugs in upload progress module. If you have already installed. update to at least 0.1 version: http://github.com/drogus/apache-upload-progress-module/commits/0.1

I’ve installed mod passenger on my server recently. It’s really great software. Now I don’t have to worry about monitoring, nginx proxy, load balancing, big file uploads… and it’s fast! With Ruby Enterprise Edition it’s even faster.

Personally I don’t care about people saying that phusion wants to promote themselves on REE as long as it gives faster ruby with lower memory use (but yes, I know, REE is not best choice for a name :).

After installing I’ve realised that my shiny upload progress bar (thanks to Upload Progress Module for nginx) was not working. Oh gods! What a tragedy!

But fear not. I’ve written apache upload progress module to have my lovely progress bar back again. As a lazy developer I’ve implemented reports in the same way as in nginx upload progress, so my applications are working without changing any signle line of code. If you were using nginx upload progress just drop the module, change your config and you’re good to go :)

I’m testing it in one of my production servers, but be carefull – it’s not well tested in other enviroments (i have gentoo with apache 2.2.8). Any feedback will be helpfull. Give me a note in comments if you encounter any problems.

So you want to be cool and have your own sexy progress bar in your app? Keep reading ;)

To install module you must download it using git:

git clone git://github.com/drogus/apache-upload-progress-module.git

or get the package: http://github.com/drogus/apache-upload-progress-module/tarball/master

To compile/install/activate you have to use apxs2:

apxs2 -c -i -a mod_upload_progress.c

-c is for compiling
-i is for installing (copy mod_upload_progress.so to apache library dir)
-a is for activating (add LoadModule option into your apache conf file)

If you want to install and activate run this command as a root. Otherwise you can just compile and add LoadModule to apache conf:

LoadModule upload_progress_module path/to/apache-upload-progress-module/.libs/mod_upload_progress.so

Currently there is only one global option:

UploadProgressSharedMemorySize 1024000

This sets shared memory size to 1M. By default it’s 100kB.

To add tracking and reporting upload for a virtual host in apache you will need to add:

<Location />
    # enable tracking uploads in /
    TrackUploads On
</Location>

<Location /progress>
    # enable upload progress reports in /progress
    ReportUploads On
</Location>

Now all uploads will be tracked and reports are under /progress

Format of the report is JSON. From nginx wiki:

The returned document is a JSON text with the possible 4 results:

the upload request hasn’t been registered yet or is unknown:

new Object({ ‘state’ : ‘starting’ })

the upload request has ended:

new Object({ ‘state’ : ‘done’ })

the upload request generated an HTTP error:

new Object({ ‘state’ : ‘error’, ‘status’ : })

One error code that is interesting to track for clients is HTTP error 413 (Request entity too large)

the upload request is in progress:

new Object({ ‘state’ : ‘uploading’, ‘received’ : , ‘size’ : })

The HTTP request to this location must have either an X-Progress-ID parameter or X-Progress-ID HTTP header containing the unique identifier as specified in your upload/POST request to the relevant tracked zone. If you are using the X-Progress-ID as a query-string parameter, ensure it is the LAST argument in the URL.

Now the last thing to do is to implement progress bar. I don’t like repeating others and there is great tutorial on setting up upload progress bar with nginx and merb

UPDATE: I released jquery upload progress library with Safari 3 support. More info here.
UPDATE2: I’ve upgraded prototype version to work in Safari.

It’s for merb and nginx but if you drop the scripts in your rails app and with apache-upload-progress-module it will work. :) Basically if you have your own code handling uploads (for example using attachment_fu) you can just add javascript and css – it’s unobtrusive.

If you’re using prototype I’ve rewritten script and made a demo. You can also grab files

I hope you enjoy this article. Progress bar is in my opinion one of the most useful technics – there is nothing more annoying than large file uploading without any info on state of an upload.

2 przydatne rzeczy w gicie

2008-06-03T00:00:00-07:00

Usuwanie gałęzi ze zdalnego repozytorium:

git push {repository} :heads/{your_branch_here}

Usuwanie pliku z indexu bez usuwania go z systemu plików (przydatne gdy dodamy do .gitignore plik, który już istnieje):

git-update-index --force-remove sciezka/do/pliku

Taki szybki pościk ;-)

Git

2008-04-08T00:00:00-07:00

Jeżeli ktoś jeszcze nie zauważył społeczność frameworków Ruby on Rails i Merb przesiada się powoli na rozproszony system kontroli wersji Git. Na gita przechodzą Railsy, przeszedł już Merb, Rspec, sporo koderów wypuszczających popularne pluginy. Jednym słowem coś w tym musi być.

I rzeczywiście coś w tym jest.

O co chodzi? Jarosław Zabiełło na swoim blogu przedstawił kilka rozproszonych systemów kontroli wersji.

Jakie są zalety gita?

każdy posiadający kopię aplikacji posiada też całe repozytorium. Coś się rozwaliło? Trzeba zmienić serwer? Serwis,a na którym hostowałeś SVN’a padł? Smuteczek. Ale nie z gitem – repozytorium, które masz na dysku wystarczy.
Git jest dużo szybszy od SVNa
“Mobilność” – bardzo ważna dla mnie kwestia. Często wyjeżdżam i zdarza mi się pracować bez dostępu do netu. W przypadku SVNa musiałem wrzucić jeden mega commit z pierdylionem zmian. W przypadku gita commity lecą do repozytorium na dysku i później można je ewentualnie pchnąć (push) do publicznego repo.
Bardzo łatwa obsługa gałęzi. Pracując z gitem najlepiej wyrobić sobie nawyk tworzenia gałęzi przy każdej zmianie, lub grupie połączonych ze sobą zmian. Dzięki temu można pracować równolegle nad wieloma rzeczami nie zaśmiecając aplikacji. Później tylko łączymy gałęzie, które rzeczywiście są potrzebne, jeżeli coś nie wyjdzie można po prostu daną gałąź wyrzucić i po krzyku
dużo łatwiejsze wrzucanie zmian do projektów open source’owych, szczególnie z pomocą githuba (ale o tym za chwilę).

Ale kod leżący cały czas na dysku będzie mało przydatny. Dlatego można założyć sobie publiczne repozytorium. Stwierdziłem jakiś czas temu, że w trosce o swój czas, którego zawsze za mało, będę musiał ograniczyć wszelkie prace, których mogę stosunkowo łatwo uniknąć. Dlatego nie bawiłem się nawet w tworzenie swojego własnego publicznego repozytorium. Wygodniej skorzystać pracy innych ludzi ;-)

Obecnie najbardziej popularne (jedyne?) serwisy oferujące hosting repozytoriów gita to: GitHub i Gitorius. Gitorius jest w pełni darmowy, ale nie można na nim trzymać prywatnych repozytoriów. Na githubie za darmo można trzymać publiczne repozytoria (ogranicza nas 100mb – jeżeli chodzi o gita to bardzo dużo), za prywatne trzeba będzie zapłacić. Na razie można jeszcze korzystać za darmo, bo serwis jest w fazie beta.

Zarejestrowałem się na Githubie kilka dni temu i przeniosłem tam 2 ze swoich projektów. Github to bardzo fajny pomysł na stworzenie społeczności koderów (napisany oczywiście w railsach). Co daje taki serwis?

dostęp do rss’ów poszczególnych użytkowników, projektów, feed z wiadomościami z obserwowanych projektów
można jednym kliknięciem zrobić kopię aplikacji (fork) – jakie są tego korzyści opisał na blogu jeden z developerów merba Michael Ivey :Contributing to merb
można wysłać znajomym “pull request” – czyli prośbę o uaktualnienie, na przykład po ważnej aktualizacji

Dodatkowo dostajemy wszystkie zalety gita.

No to co? Przesiadka na jasną stronę mocy, z tego fuj fuj obleśnego i niefajnego SVNa, który tak chwaliłem kiedy się z nim zapoznałem ;-)

HotRuby

2008-04-05T00:00:00-07:00

Jakiś czas temu pojawiły się wzmianki o hotruby (tylko wtedy nie miałem czasu o tym napisać). Krótko mówiąc jest to “implementacja rubiego w javascripcie”. Możemy używać rubiego w przeglądarce i we flashu.

Kod rubiego jest wysyłany do skompilowania przez skrypt cgi, skrypt cgi kompiluje go do bytecodu, po czym javascript wykonuje ów bytecode.

Na stronie HotRuby jest wzmianka o tym, że składnia języka jest w większości zaimplementowana (na pewno nie ma wyjątków), ale jak na razie większość funkcji i bibliotek nie. Na razie nie wiem do czego mogłoby mi się takie połączenie przydać, ale patrząc na dema łatwo można zauważyć, że całkiem fajne rzeczy da się stworzyć z pomocą hotrubiego. Oby tak dalej.

Rails 2.0 i js.erb

2008-01-15T00:00:00-08:00

Niedawno pisałem o nieinwazyjnym kodzie javascript w railsach. Wspomniałem tam o pluginie MinusMor, który dodaje pliki ejs. Czyli kod javascript parsowany erbem. Zainstalowałem plugin w mojej aplikacji przeniesionej na rails 2.0. Kod pluginu nie działa… zacząłem przeglądać kod railsów, żeby poprawić minusmor (w internecie nie mogłem znaleźć poprawki). Po chwili przemyślenia sprawdziłem co dzieje się gdy wyrzucę plik rjs. Komunikat o błędzie:

Missing template pages/index.js.erb in view path

Git! W railsach 2.0 możemy przecież wskazać jakiego parsera mają użyć.

Tworzymy plik index.js.erb. I jeszcze mała zmiana, ustawiamy brak layoutu, żeby renderował się sam template:

respond_to do |format|
  render.html
  render.js { render :layout => false }
end

I to wszystko! Po prostu działa.

Nawet lepiej. Można zdefiniować layout, na przykład:

render.js { render :layout => 'jquery' }

a w nim można na przykład napisać:

(function ($) {
  <%= yield %>
})(jQuery);

I można używać w template’ach js.erb $ pomimo tego, że wcześniej użyło się jQuery.noConflict.

Przeszukałem później jeszcze net w poszukiwaniu informacji na ten temat i znalazłem artykuł na mad.ly o dodaniu helperów z MinusMor

Web3.0 - boję się!

2008-01-13T00:00:00-08:00

Pan Urbanowicz, znawca internetu, napisał tekst o (uwaga uwaga, fanfary) Web3.0! A w nim przestraszył mnie nieźle:

Ale Web 3.0 niesie ze sobą również wiele zagrożeń: naruszanie swobód obywatelskich, kradzież danych, stopniową dehumanizację czy czipy biometryczne, będące w stanie śledzić wszystkie nasze ruchy. Jak w „Raporcie mniejszości", każdy nasz krok będzie rejestrowany przez kamery, które będą komunikować z komputerami, a te porozumiewać się z serwisami identyfikującymi twarze. Kto wie, jak daleko może posunąć się inwigilacja ze strony agencji rządowych?

Oba światy: wirtualny i rzeczywisty będę się wzajemnie przenikały, automatycznie wzrośnie ilość spamu, wirusów i hakerów. Będzie więcej dezinformacji, więcej manipulacji i więcej cenzury. Web 3.0 nie będzie nas chronił bardziej niż Web 2.0, wprost przeciwnie, będziemy jeszcze bardziej narażeni na niebezpieczeństwa. Tworzymy świat, który trudno nam zrozumieć, a co dopiero mówić o jego kontroli.

Szkoda, że nie ma nic o głodzie, wojnach, najeźdźcach z kosmosu i pani Czesi spod piątki, która awanturuje się o każdą rzecz.

Boże, miej nas w swojej opiece! Albowiem Armagedon 3.0 nadchodzi!

Przyjazne adresy w Ruby on Rails

2008-01-12T00:00:00-08:00

W dzisiejszych czasach, kiedy SEO dla niektórych jest ważniejsze od treści przyjazne adresy można zobaczyć na większości stron. Dlaczego nie wrzucić ich do naszej aplikacji? Nawet jeżeli komuś nie zależy na SEO, przyjazne adresy są… przyjazne! Użytkownik dostający linka http://foo.com/article/kolejny-artykul-o-naszej-klasie będzie miał szansę zastanowić się sekundę i nie kliknąć (nie to żebym miał coś do naszej klasy, ale boję się ostatnio lodówkę otworzyć, jeszcze szynka zacznie nawijać kogo dodała do znajomych). Same korzyści!

Dodanie przyjaznych adresów jest w aplikacji railsowej bardzo proste jeżeli trzymamy się kilku zasad. Jak to działa? ActiveRecord::Base, po którym dziedziczą udostępnia metodę to_param, która jest wykorzystywana przy generowaniu adresów.

W praktyce wygląda to tak, że jeżeli napiszemy:
<pre> link_to @article.name, articles_path(@article) #albo link_to @article.name, :controller => "articles", :action => "show", :id => @article </pre>

wywołana zostanie metoda to_param i @article zostanie zamieniony na jego id. Można to wykorzysta do naszych niecnych celów.

Można nadpisać to_param
<pre> def to_param "#{id}-#{name.gsub(/[^a-z0-9]+/i, '-')}" end </pre>

Od teraz zamiast id będzie generował się string zawierający name, na przykład: “11-tytuł-artykułu”. Hamerykanie mają mniejszy problem, bo nie mają znaków diakrytycznych i mogą to tak zostawić. gsub zamieni wszystkie znaki nie wchodzące w skład alfabetu na myślnik. U nas jest gorzej, bo nie chcemy mieć adresu: “11-tytu-artyku-u”. I weź teraz zgaduj gdzie dorzucić ogonki. Z pomocą przychodzi Obie Fernandez, który napisał najfajniejszą jaką do tej pory widziałem metodą zamieniającą znaki diakrytyczne na odpowiadające im litery alfabetu
Wrzuciłem na serwer wersję z polskimi znakami diakrytycznymi. Taki plik wystarczy wrzucić do folderu initializers dla Railsów 2.0.x, albo do katalogu lib dla 1.2.x (w tym wypadku trzeba też w environment.rb dodać linijkę require ‘ascii’). Zrobiłem jeszcze jedną modyfikację – to_url_format powinien moim zdaniem w miejsce spacji i innych znaków wrzucać myślniki. Lepiej wygląda “tytul-artykulu” niż “tytulartykulu”.

Dzięki temu String udostępnia 2 nowe metody: `to_url_format` i `to_ascii`:
<pre> "zażółć gęślą jaźń".to_ascii #=> "zazolc gesla jazn"

“zażółć gęślą jaźń”.to_url_format #=> “zazolc-gesla-jazn”

Teraz wystarczy zmodyfikować lekko to_param:
<pre> def to_param "#{id}-#{name.to_url_format}" end </pre>

Dzięki temu urle będą miały upragnioną formę: “12-tytul-artykulu”.

Tylko po co to id na początku? Dzięki temu obędzie się bez żadnych zmian w kontrolerach. Taki string zostanie przed wrzuceniem do bazy automatycznie skonwertowany na liczbę całkowitą. Czyli kolejna rzecz, która “po prostu działa” automagicznie. Jeżeli id będzie potrzebne w jakimś innym miejscu, w którym nie nastąpi konwersja można to zrobić ręcznie: params[:id].to_i, bo:
<pre> "11-jakis-napis".to_i #=> 11 </pre>

Jaki jest minus takiej metody? Adresy mają w sobie id i tylko na podstawie tego id jest pobierany artykuł, więc czy wpiszemy /articles/11-tytul-artykulu, czy /articles/11-tralalala pobierze się ten sam artykuł.

Żeby temu zapobiec najlepiej zrobić dodatkową kolumnę, na przykład “permalink” i wpisywać do niej przekształcony adres. Np. article.permalink = article.name.to_url_format . I zamiast po id szukać po kolumnie permalink: Article.find_by_permalink(params[:id]). Oczywiście z metody to_param też trzeba usunąć id :)

Nie każdemu to drugie podejście będzie potrzebne. Dla mnie wersja z id jest o tyle lepsza, że jak nawet ktoś nie skopiuje całego adresu, albo pomyli się przy wpisywaniu (tak, czasami zdarza się, że ktoś dyktuje jakiś adres), to jest duża szansa, że dotrze na dobrą stronę. Poza tym istnieje wtedy możliwość wklejenia adresu bez dalszej części, która może być dość długa – może nie trzeba będzie korzystać z serwisów typu tinyurl.

Wrzuciłem nową wersję skryptu działającą z nowszymi wersjami Ruby on Rails

Otwarte klasy w Rubim i ich praktyczne wykorzystanie

2008-01-08T00:00:00-08:00

Ruby posiada bardzo fajną właściwość nazwaną otwartymi klasami. Znaczy to tyle, że jeżeli nikt nie zamroził danej klasy/metody, można w dowolnym miejscu w kodzie nadpisać ją klasę, metodą, dodać nowe metody. Można tak nadpisać nawet klasy wbudowane w język!

Na przykład taki kod (och jak ja lubię ten przykład):

class Fixnum
  alias old_plus +

  def +(other)
    (self.old_plus other) % 7
  end
end

4+4 #=> 1

4+4=1 ? nie tego się spodziewaliśmy. A właściwie nie tego się spodziewali ludzie, którzy nie rozumieją jeszcze powyższego przykładu (celowo dodałem słowo jeszcze, będę na tyle cywilizowanym i miłym człowiekiem, że spróbuję wytłumaczyć o co chodzi).

Liczby całkowite są klasy Fixnum. Powyższy kod modyfikuje tą klasę. Najpierw tworzony jest alias dla metody +, żeby można było jej później używać, a następnie owa metoda zostaje nadpisana w taki sposób, żeby zwracała wynik dodawania modulo7

Do napisania tego artykułu natchnął mnie Daniel Owsiański pisząc o zjawisku roboczo nazwanym version lock-in. Daniel ma oczywiście dużo racji i moja paranoja, o której pisałem u niego w komentarzach jest objawem przewrażliwienia mojej mózgoczaszki w pewnych kwestiach. Są jednak wypadki, w których naprawdę warto zachować zgodność z nowymi wersjami. Pomaga tutaj powyższa właściwość języka Ruby. Pisał o tym kiedyś autor bloga Err the Blog w kontekście rozszerzania możliwości pluginów.

Często w rozmowach o Ruby on Rails na różnych listach dyskusyjnych można usłyszeć, że gdy chcemy coś zmienić w danej metodzie, najlepiej przekopiować kod metody, nadpisać ją, zmienić to co trzeba i voilla. Ale nie tędy droga panie i panowie :)

Wyglądałoby to mniej więcej tak. Chcemy na przykład nadpisać metodę find. Wchodzimy na Rails API, znajdujemy ActiveRecord::Base#find, wklejamy kod w modelu i zmieniamy:

#w modelu:
def self.find(*args)
  #jakiś zmodyfikowany kod finda
end

Jakie minusy ma takie podejście? Gdy mamy zainstalowaną dużą liczbę pluginów nigdy nie wiadomo czy któryś z nich nie nadpisuje już metody find i wtedy nadpisując ją stracimy funkcjonalność dodaną przez plugin. Smuteczek. Poza tym gdy zmieni się kod metody find w samym frameworku również u nas będziemy musieli go zmienić.

Jak to zrobić Ruby Way™? Przypuśćmy, że chcemy się popastwić nad wspomnianą metodą find:

#w modelu:

# metoda find jest metodą klasy
class << self
  def find(*args)
    args[1] ||= {}
    args[1][:conditions] ||= {} 
    args[1][:conditions] = [args[1][:conditions]] if args[1][:conditions].is_a?(String)
    case args[1][:conditions]
      when Hash: 
        args[1][:conditions].merge!(:deleted => false)
      when Array:
        if args[1][:conditions][0].strip.blank?
          args[1][:conditions][0] = "deleted = ?"
        else
          args[1][:conditions][0] = ["(#{args[1][:conditions][0]})", "deleted = ?"].join(' AND ')
        end
        args[1][:conditions] << false       
    end
    super(*args)
  end
end

Powyższy kod dodaje do conditions warunek “deleted = false”, po czym wywołuje metodę find z tak zmodyfikowanymi argumentami. Czasami trzeba jednak namieszać coś w kodzie metody. Można wtedy dodać dodatkowy argument. Następnie dajemy ifa – jeżeli argument zwraca true wykonujemy zmodyfikowany kod, a jeżeli nie, wykonujemy kod oryginalnej metody.

Dzięki takiemu podejściu możemy w miarę łatwo upgradować pluginy i Railsy bez większego stresu :)

Thin. Nowy lepszy mongrel. Sphinx. Nowy lepszy ferret.

2008-01-06T00:00:00-08:00

Jak donosi Ruby Inside, wypuszczony został ostatnio serwer szybszy od mongrela.

Chodzi o Thin, czyli połączenie EventMachine, Racka (interfejs do komunikacji z serwerem) i Mongrela (a dokładniej jego bibliotek do parsowania). Instalacja i użycie jest równie łatwe co użycie samego mongrela. `gem install thin`, a później w katalogu aplikacji `thin start`. Jedna z moich aplikacji wyciągała na mongrelu 110req/s, a na thinie około 150req/s (ab -c 10 -n 100). Różnica całkiem spora. Warto się przesiąść

Sprawdziłem też ostatnio sphinxa. O sphinxie pisał już Jarosław Zabiełło i bardzo mnie powyższym artykułem zainteresował. Do tej pory używałem ferreta, ale odpalanie nie do końca stabilnych i niezbyt szybkich serwerów dla każdej aplikacji było trochę uciążliwe. Ezra Zygmuntowicz, twórca frameworka Merb wypowiadał się, że miał dość duże kłopoty ze stabilnością ferreta, które skończyły się po przejściu na sphinxa.

Instalacja opisana jest w dokumentacji, więc nie będę powtarzał :) Mogę dodać jedynie, że czasami używając bazy postgresql trzeba ręcznie dodać language poleceniem `createlang plpgsql nazwa_bazy` (chodzi o nowy język proceduralny dla postgresa). Serwer odpalony przez sphinxa jest bardzo wydajny i zajmuje kilkadziesiąt razy mniejsze ilości pamięci operacyjnej. Jedynym minusem jest to, że nie ma niektórych opcji, które posiada ferret – jeżeli ktoś ich potrzebuje proponuję sprawdzenie Solr.

Zapomniałem wspomnieć, że ultrasphinx działa z bazami postgresql >= 8.2

God.rb

2008-01-05T00:00:00-08:00

Wpadłem jakiś czas temu na bardzo fajną aplikację wspomagającą deployment Ruby on Rails. god.rb monitoruje procesy i w razie potrzeby (out of memory, zbyt dużo pożartego cpu, pad serwera) restartuje je. Config, jak i sam god oczywiście, jest napisany w Ruby’im, więc można sobie nieco ułatwić pracę (wspominałem kiedyś, że nigdy nie miałem dość samozaparcia, żeby się nauczyć pisać skrypty powłoki pod linuxem?).

Aby go zainstalować należy jako root (pod ubuntu sudo) wykonać polecenie:

gem install god

Na stronie goda są podane różne configi, ale nie zakładają one scenariusza: “sporo aplikacji, taki sam config, jak to zrobić automatycznie?”. Pomyślałem sobie, że napiszę prosty config, który będzie pobierał listę aplikacji Rails z pliku i dodawał mongrele do monitorowania. Gdy na serwerze siedzi więcej aplikacji głupio byłoby kopiować config dla każdej z nich i ręcznie ustawiać numery portów i katalogi.

Pełny config z komentarzami wyjaśniającymi o co kaman (wersja tekstowa):

# run with:  god -c /path/to/config.god<span class="c1"># run with:  god -c /path/to/config.god</span>
require 'yaml'
# otwieramy plik ze spisem aplikacji i robimy z nich tablicę

rails_apps = File.open("/etc/god/applications", "r").readlines.collect { |app| app.strip }
for rails_app in rails_apps

  # załadujmy ustawienia danej aplikacji

  # korzystać będziemy z konfiguracji dla clusterów

  config = YAML::load(File.open(File.join(rails_app, "config/mongrel_cluster.yml")))

  config["servers"] ||= 1 # domyślnie startujemy jeden serwer
# teraz stawiamy mongrela dla każdego portu
((config["port"].to_i)..(config["port"].to_i+config["servers"].to_i-1)).each do |port|
God.watch do |w|
pid_file = File.join(rails_app, config["pid_file"].gsub(/\.pid$/, ".#{port}.pid"))
w.name = "#{rails_app[/[^\/]*$/]}-mongrel-#{port}"

# dodajemy mongrele danej aplikacji do grupy o nazwie takiej samej jak nazwa katalogu
w.group = "#{rails_app[/[^\/]*$/]}"
w.interval = 30.seconds # default      
w.start = "mongrel_rails start -c #{rails_app} -p #{port} \
        -P #{pid_file}  -e #{config['environment']}  -d"

      w.stop = "mongrel_rails stop -P #{pid_file}"

      w.restart = "mongrel_rails restart -P #{pid_file}"

      w.start_grace = 10.seconds

      w.restart_grace = 10.seconds

      w.pid_file = File.join(pid_file)
w.behavior(:clean_pid_file)

w.start_if do |start|
start.condition(:process_running) do |c|
c.interval = 5.seconds
c.running = false
end
end

w.restart_if do |restart|
restart.condition(:memory_usage) do |c|
c.above = 150.megabytes
c.times = [3, 5] # 3 out of 5 intervals
end

restart.condition(:cpu_usage) do |c|
c.above = 50.percent
c.times = 5
end
end

# lifecycle
w.lifecycle do |on|
on.condition(:flapping) do |c|
c.to_state = [:start, :restart]
c.times = 5
c.within = 5.minute
c.transition = :unmonitored
c.retry_in = 10.minutes
c.retry_times = 5
c.retry_within = 2.hours
end
end

end
end
end
puts "kuniec"




Aplikacje w pliku, który jest odczytywany na początku to ścieżki wpisane w kolejnych liniach. gdy wystartujemy goda poleceniem `god -c /sciezka/do/configu` uruchomią się mongrele dla wszystkich aplikacji. Ważne: powyższy config korzysta z konfiguracji stworzonych dla clusterów. Aby ją stworzyć należy wykonać w katalogu aplikacji:
mongrel_rails cluster::configure -e production -p 8000 -N 2


Powyższa komenda wygeneruje plik `mongrel_cluster.yml` w katalogu config aplikacji Ruby on Rails. Zostanie ustawione środowisko production, port 8000 i 2 serwery (na portach 8000 i 8001).
Żeby szczęście było pełne i niczym niezmącone można jeszcze pokusić się o napisanie skryptu startowego init.d. Oczywiście w ruby’im. A jakie to proste pokazywał kiedyś Jarek Zebiełło.
W razie wątpliwości pytajcie o szczegóły w komentarzach.



Nieinwazyjny javascript razem z Ruby on Rails
2007-12-25T00:00:00-08:00
Jakiś czas temu Riddle napisał o tym dlaczego nie można zakładać, że ktoś ma włączony javascript. Temat był już wcześniej wiele razy poruszany, mi bardzo podobał się artykuł Chrisa Heilmanna The seven rules of Unobtrusive JavaScript. Zachęcam do zapoznania się z tymi dwoma tekstami – pomogą zrozumieć dlaczego “tracić” czas na rozwiązywanie problemów, o których napiszę poniżej. Streszczając krótko artykuły mogę napisać, że jeżeli to możliwe, należy pisać aplikację tak, żeby działała bez włączonego javascriptu. Skrypty mogą nie działać z kilku powodów:

	użytkownik ma wyłączony javascript w przeglądarce
	wystąpi błąd w kodzie (nie możemy sprawdzić kodu na wszystkich urządzeniach)
	strona nie załaduje się do końca
	boty wyszukiwarek nie używają javascriptu, więc w skrajnym wypadku możemy uniemożliwić zindeksowanie naszej strony

Jak to wygląda w Railsach?
Railsy są wyposażone w zestaw helperów generujących różnego rodzaju kawałki kodu javascript. Pomysł jest z pozoru bardzo fajny. Początkujący mogą szybko zacząć używać javascriptu razem z dobrodziejstwami, które daje nam Ajax bez znajomości samego języka. Jest jednak sporo minusów używania helperów:

	generują one dodatkowy niepotrzebny kod javascript. jeżeli na stronie mamy kilkadziesiąt linków, a każdy z nich ma wklejony kod `onclick=“new Ajax.Request(‘/controller/action?n=33’, {asynchronous:true, evalScripts:true, onComplete:function(request){undoRequestCompleted(request)}}); return false;”` strona będzie ważyć dużo więcej.
	javascript w nich użyty jest “inwazyjny”. Jeżeli javascript nie będzie działał, to element wygenerowany w taki sposób również nie zadziała^1^
	ciężko jest się przy nich trzymać zasady DRY. Mając 5 linków wygenerowanych metodą link_to_remote z takimi samymi opcjami, za każdym razem gdy coś musimy zmienić, zmieniamy to w 5 miejscach. Powinno się oczywiście napisać helpera, który wygeneruje link z danymi opcjami. Tylko chyba nie tędy droga – w dalszej części artykułu postaram się pokazać dlaczego nieinwazyjny javascript jest lepszy w tego typu zadaniach.
	z mojego doświadczenia wynika, że bardzo często, gdy ilość kodu się powiększa i javascript generowany przez railsy miesza się z tym z plików js można łatwo się pogubić. Tyczy się to także różnego rodzaju api – na przykład google maps. Najłatwiej działać, gdy javascript jest odseparowany od kodu railsów
	jesteśmy związani z jedną biblioteką (w tym wypadku prototype+script.aculo.us) – jeżeli chcemy zamienić ją na coś innego (ja ostatnio przesiadłem się na jQuery, zastanawiałem się też nad YUI) helpery przestaną działać – można je oczywiście przepisać, ale komu by się chciało. DHH nie zamierza nic w tej kwestii zmieniać, więc na zmianę tego w Railsach nie ma co czekać.

Jakie są minusy? Trzeba lepiej poznać javascript (właściwie dla mnie to nie jest minus, ale dla niektórych być może tak). Nie jest to jednak przeszkoda nie do pokonania dla początkujących. Javascript, który jest potrzebny do zadań możliwych do wykonania z użyciem samych helperów nie jest z reguły przesadnie trudny do nauczenia. Ratunkiem dla osób, które nadal chcą korzystać z helperów jest plugin UJS. Jeżeli bardzo nie chcesz pisać wszystkiego w czystym javascripcie, to jest to bardzo fajne połączenie prostoty helperów i zalet nieinwazyjnego javascriptu. Jest ona jednak pisana dla Prototype’a, więc tak jak w ostatnim punkcie z powyższej listy można o niej zapomnieć, jeżeli używana jest jakakolwiek inna biblioteka.
W komentarzach apohllo zauważył, że plugin UJS nie jest już rozwijany. Używacie na własną odpowiedzialność. :)
Przejdę do przykładów, bo przecież nie samą teorią człowiek żyje.
Przerzuciłem się ostatnio na jQuery i chyba przy niej zostanę. Rozumiem jednak, że większość użytkowników railsów jest związana z Prototype’em, więc kod będę podawał w dwóch wersjach, dla Prototype’a i jQuery.
Na początek wprowadzenie. Co zrobić, żeby wyrzucić z htmla (i railsów) wstawki Javascript? Wszystko wstawiamy do aplikacji używając zdarzeń. Przypuśćmy, że mamy linka o id=“someLink”. Zamiast dopisania onclick:
  <a href="#" onclick="alert('Klik!'); return false;">Link</a>


należy użyć:
Prototype:
  Event.observe($('someLink'), 'click', function(event) {
    alert('Klik!');
    Event.stop(event);
  }


jQuery:
  $('#someLink').click(function (){
    alert('Klik!');
    return false;
  });


Oba przykłady dodają zdarzenie uaktywniane kliknięciem w linka. Ostatnia linijka w obu funkcjach, które są wykonywane po kliknięciu (nazywane są z reguły handlerami) jest wstawiona po to, żeby kliknięcie linka nie przeładowało strony.
Kod taki w aplikacji Rails można wrzucić do pliku application.js, lub jakiegoś specyficznego pliku js ładowanego na danej stronie. Należy też go załadować dopiero po wczytaniu się całego dokumentu. Normalnie coś takiego uzyskiwało się wpisując w body: `onload=“jakasFunkcjaJavascript();”`, ale takie dodawanie jest passe, więc:
Prototype:
  Event.observe(window, 'load', function() {
    //kod który wykona się po załadowaniu strony
  }

  // lub zdefiniowana wcześniej funkcja, która wykona się po załadowaniu strony
  Event.observe(window, 'load', jakasFunkcjaJavascript());


jQuery:
  $(function() {
    //kod który wykona się po załadowaniu strony
  });
  
  // lub zdefiniowana wcześniej funkcja, która wykona się po załadowaniu strony
  $(jakasFunkcjaJavascript);
  //powyższe przykłady, to skrócone wersje document.ready:
  $(document).ready(function () {});


Dzięki tym konstrukcjom mamy pewność, że kod wykona się dopiero gdy załaduje się cały dokument, a nie w momencie, gdy dołączony jest plik js.
Teraz przykład prostego zapytania ajax (przykład z dokumentacji railsów):
  link_to_remote 'hello', :url => { :action => "action" }, 
    404 => "alert('Not found...? Wrong URL...?')",
    :failure => "alert('HTTP Error ' + request.status + '!')"
  # Wygeneruje: <a href="#" onclick="new Ajax.Request('/testing/action', {asynchronous:true, evalScripts:true,
  #            on404:function(request){alert('Not found...? Wrong URL...?')},
  #            onFailure:function(request){alert('HTTP Error ' + request.status + '!')}}); return false;">hello</a>



Jak widać powyżej wygenerowanego kodu jest całkiem sporo. Jeżeli będzie trzeba wstawić taki link w paru miejscach dobrze by było napisać swojego własnego helpera, który automatycznie będzie wklejał komunikaty o błędach.
Jak można to zrobić lepiej? Na początek wystarczy stworzyć zwykłego linka z jakąś klasą, lub id:
  link_to 'hello', { :action => 'action' }, :class => 'ajax'



Teraz trzeba użyć trochę javascriptu :
        $$('a.ajax').each(function (element) {
          Event.observe(element, 'click', function(event) {
            new Ajax.Request(this.readAttribute('href'), {asynchronous:true, evalScripts:true, 
              on404:function(request){alert('Not found...? Wrong URL...?')}, 
              onFailure:function(request){alert('HTTP Error ' + request.status + '!')}}); 
            Event.stop(event);
          });
        });



Na początku pobieramy wszystkie linki z klasą ajax i dla każdego z nich wywołujemy funkcję `Event.observe(element, ‘click’….`. Dalszy kod wykona się więc po kliknięciu w danego linka. W tym wypadku wykonujemy zapytanie ajaxowe (`new Ajax.Request`). Pierwszy argument to atrybut href linka (uwaga, kod ten nie zadziała w starszych wersjach prototype’a, które niepoprawnie obsługiwały this w tego typu funkcji). Reszta kodu to standardowe opcje, po więcej odsyłam do dokumentacji Prototype.
A w jQuery wyglądać to będzie tak:
    $('a.ajax').click(function (){
      $.ajax({
        url: this.href,
        dataType: "script",
        beforeSend: function(xhr) {xhr.setRequestHeader("Accept", "text/javascript");},
        error: function(){
          alert( "Error loading page");
        }
      });     
      return false;
    });


Kod zasadniczo robi to samo, co poprzedni przykład. Można przy okazji porównać prostotę jQuery i porównać ją z Prototype’em (ostatnio dużo się w tej bibliotece pozmieniało, a ja nie jestem na bieżąco, więc jeżeli ktoś zna lepszy sposób na napisanie czegoś takiego, to proszę o komentarz). Skomentuję tylko atrybuty dataType i beforeSend w funkcji ajax(). Ustawiając je w taki sposób przekazujemy serwerowi, że chcemy dostać odpowiedź jako skrypt i akceptujemy typ MIME “text/javascript”. Należy te 2 rzeczy dodać, ponieważ inaczej nie będzie renderować się plik RJS. Więcej na ten temat w artykule jQuery Ajax + Rails
Rozwiązanie proste i efektywne. Żeby link wykonał javascript wystarczy dodać do niego klasę ajax. Jeżeli strona i kody javascript nie wczytają się, link dalej będzie działał poprawnie. Przy założeniu, że poprawnie obsłużymy wszystko w kontrolerze. Służy do tego metoda `respond_to`
  respond_to do |format|
    format.js # jeżeli to zapytanie wykonane ajaxem uruchomi się plik RJS
    format.html # w przeciwnym wypadku wyrenderowany zostanie template rhtml
  end


Więcej o takim sposobie renderowania templatów pisał na przykład Jamis Buck.
Można też w podobny sposób zamienić zwykłą formę na taką wysyłaną ajaxem:
Prototype:
     $$('form.ajax').each(function (element) {
        Event.observe(element, 'submit', function(event) {
          new Ajax.Request(this.readAttribute('action'), {
            parameters: Form.serialize(this),
            asynchronous:true, 
            evalScripts:true
            }); 
          Event.stop(event);
        });
      });  


Powyższy kod jest bardzo podobny do poprzedniego przykładu. Różnica polega na tym, że zdarzeniem nie jest ‘click’ tylko ‘submit’ i jako parametry podajmy wynik funkcji `Form.serialize(this)` – zbiera ona wartości pól i zwraca string typu: “pole1=wartosc1&pole2=wartosc2”
jQuery:
  $("form.ajax").ajaxForm({
    dataType: 'script',
    beforeSend: function(xhr) {xhr.setRequestHeader("Accept", "text/javascript");},
    resetForm: true
  });



W jQuery najłatwiej skorzystać z pluginu jQuery Form – załatwia on za nas wszelkie formalności ;-)
W ten sposób zmiana jakiegoś linka lub formy na jego ajaxową formę to kwestia dodania jednej klasy. Można oczywiście napisac wiele takich funkcji dla różnych przypadków, dowiązanych do tagów z innymi klasami, lub z konkretnym id.
Na koniec krótkie podsumowanie.
Kod javascript dodajemy do aplikacji tak, żeby nie zablokować dostępu w wypadku braku jego wykonania. Zapomnieć można o wszelakich “onclick” i innych tego typu sprawach. Wszystko powinno być dołączone jako zdarzenia. Dzięki temu zmniejsza i upraszcza się kod railsów i ten przez nie generowany.
Warto obejrzeć również plugin MinusMOR, który zmienia trochę podejście do javascriptu. Zamiast plików rjs, w których używamy rubiego zamienianego później na javascript, mamy pliki ejs, w których wpisujemy kod javascript z możliwością wstawiania kodu rubiego. Tak samo jak w rhtmlu poprzez <% %>.
W komentarzach apohllo zauważył, że plugin MinusMOR nie jest już rozwijany. Trzeba o tym pamiętać zaczynając go używać. Z drugiej strony widziałem kod pluginu i rejestruje on tylko nowe rozszerzenie “ejs”. Na początku szukane będą pliki z tym rozszerzeniem, a jeżeli ich nie będzie Railsy wyrenderują RJS. W każdym razie zaczynacie używać na własną odpowiedzialność. :)
Zapraszam do komentowania – prosiłbym o opinie dotyczące tego typu artykułów. Czy są zrozumiałe? Czy przydają się wam? Konstruktywna krytyka mile widziana. :)



	W tym miejscu trzeba zaznaczyć, że jest możliwość wygenerowania linku, czy formy, która będzie działała przy wyłączonym javascripcie, ale niewiele osób o tym wie i z tego korzysta. I trzeba dopisać 2 url, który z reguły jest taki sam – łamana jest zasada DRY



jQuery vs Prototype
2007-09-04T00:00:00-07:00
Kilka dni temu wrzuciłem notkę promującą jQuery. Często podczas porównywania narzędzi przeżywam pewien rodzaj euforii, która nie pozwala mi na obiektywne rozpatrzenie wszystkich za i przeciw. Przez chwilę wydaje mi się, że znalazłem narzędzie idealne (co oczywiście jest okropnym nadużyciem. jak ogólnie wiadomo idealny jest tylko polski rząd i jego sukcesy na przestrzeni ostatnich 2 lat – widziałem w reklamach).
W każdym razie ochłonąłem trochę i ze spokojem buddyjskiego mnicha (mówiłem już, że jestem oazą spokoju?) przetrząsnąłem cały internet w poszukiwaniu informacji. Próbowałem nawet wywołać flamewara na google groups. I biednie jest. Niewiele znalazłem. Wszędzie jakieś artykuły, których sens jest mniej więcej taki: “Przez długi czas używałem prototype(jQuery) i stwierdziłem, że muszę dać jQuery(prototype) szansę. jQuery jest prototype killerem!”. Nie licząc fajnego artykułu na agile ajax. Stety albo niestety autor nie do końca chce wyjawić, które podejście jest dla niego lepsze. Aczkolwiek pewną wskazówką może być przesiadka na jQuery, a nie odwrotnie.
No i krytyka modelu dziedziczenia zastosowanego w prototype.
Pozwoliłem sobie zrobić własne porównanie. Mam nadzieję, że chociaż w małym procencie obiektywne. ;-)
Manipulacja DOM i CSS
Na tym polu zdecydowanie wygrywa jQuery. Twórca zapewnił coś, co nazywa się “chainability”. Metody manipulujące elementami HTMLa można wywoływać w łańcuchach, na przykład jQuery('#some').show('slow').css('background-color', 'white').add('<p>Dodatkowy paragraf!</p>').
Jeżeli chodzi o same selektory, to od wersji 1.5.0 prototype ma obsługę selektorów CSS, więc nie ma już problemu z wybieraniem elementów w bardzo fikuśnych konfiguracjach ;-)
jQuery ma jeszcze jedną ciekawą właściwość. Wybrane elementy zawsze zwracane są w tablicy dzięki czemu biblioteka sama zadba o przeiterowanie po kolekcji i zaaplikowaniu metody do każdego jej elementu. Na przykład zamiast napisać (prototype):
$$('a').each(function(v, i) { Event.observe(v, 'click', fn); });


Możemy użyć:
jQuery('a').click(fn);


Wydajność
Na tym polu prototype mocno dawał w kość jQuery, ale sytuacja się poprawiła. W poprzednim poście zamieściłem 2 screeny, na których można zauważyć, że obecnie jQuery jest jakieś 2 razy wolniejsza (oczywiście jeżeli chodzi o same selektory). Dla innych metod podejrzewam, że będzie podobnie (dla each i map na pewno – jeżeli ktoś się bardzo nudzi może się pobawić i zrobić więcej benchmarków).
Ale statystyki na szczęście nie zawsze oddają to, co dzieje się w rzeczywistości. Jeżeli ktoś dysponuje odpowiednio wolnym komputerem (kilkaset mhz najlepiej), łatwo może sprawdzić, że efekty napisane w script.aculo.us bardziej “mulą” kompa niż ich odpowiedniki w jQuery (linux, firefox2 – wydaje mi się, że na innych systemach i przeglądarkach będzie podobnie). Szczególnie widać tą różnicę przy wszelakich tworach drag&drop.
Rozszerzenia
W tym miejscu wystarczy spojrzeć na listę rozszerzeń dla jQuery. Tego chyba nic w tej chwili  nie pobije. Rozszerzenia z zakresu UI dla prototypa (a właściwie script.aculo.us) wyglądają biednie w takim porównaniu.
Duży plus dla jQuery.
Społeczność
jQuery jest niewątpliwie biblioteką popularniejszą. Niektórzy mówią, że to chwilowy buzz (znowu ulegam modzie frameworkowej? :).
Prototype z kolei, chociaż mniej popularny, ma mocne wsparcie w społeczności RoR i wsparcie Rails Core Team. Podobno niektórzy pracują nad czymś co można nazwać “jQuery on Rails”, ale nadal prototype jako jedyny jest dostępny “out of the box”.
Rozszerzenia języka.
Prototype dodaje do javascriptu bardzo dużo metod, wzorowanych na metodach rubiego,  ułatwiających pracę z wbudowanymi typami. Między innymi moduł Enumerable, Hash, sporo metod do String, Date i dużo dużo więcej.
jQuery z kolei udostępnia tylko kilka metod (each, map, trim, grep…). Oczywiście można dodać swoje metody, ale w tym miejscu trzeba wspomnieć o filozofii jQuery.
Prototype dodaje nowe metody do poszczególnych klas, dzięki czemu można napisać na przykład:
['a', 'b', 'c'].each(function(v, i) { alert(v); });


W jQuery wyglądałoby to w ten sposób:
jQuery.each(['a', 'b', 'c'], function(v, i) { alert(v); });


Jeszcze nie jestem do końca pewien, które podejście mi bardziej pasuje. Być może połączenie jQuery z podejściem prototype?
jQuery.extend(Array.prototype, {
  each: function(iterator) {
    jQuery.each(this, iterator);
  }
});


I już można użyć konstrukcji analogicznej do prototype. Po paru zmianach można dodać też resztę funkcji z Enumerable – po odpowiednim przygotowaniu potrzeba niewiele więcej niż copy&paste. Podobnie łatwo będzie z resztą rozszerzeń.
Można również zostać przy podejściu jQuery i napisać metody działające mniej więcej tak:
jQuery.collect(arr, function(v, i) { /* jakiś kod */});


Chwilę po dodaniu tego posta przypadkiem trafiłem na fajny artykuł, który pokazuje dlaczego podejście a’la prototype jest po ciemnej stronie mocy ;-)
W następnym poście opiszę jak można to szybko, łatwo i przyjemnie zrobić. (o ile starczy mi czasu i samozaparcia)
Od wersji 1.6.0 prototype dostanie też parę bardzo przydatnych funkcji i narzędzi. Między innymi DOMBuilder, custom events, wrap() – bardzo podobają mi się takie smaczki. Więcej informacji w notce na stronie prototype
Podsumowując ten punkt, jeżeli chcemy intensywnie korzystać z wymienionych powyżej metod (polecam przejrzeć dokumentację prototype) lepszym wyborem będzie prototype. Z zaznaczeniem, że sporo z tych funkcji można bardzo łatwo przenieść do jQuery ;-)
Materiały
Przez pewien czas, dawno dawno temu, prototype nie miał prawie dokumentacji, co mogło niektórych zniechęcać. Aktualnie można powiedzieć, że zarówno prototype, jak i script.aculo.us są dobrze udokumentowane i raczej nikt nie będzie miał problemu z nauką. Tak samo zresztą jest z jQuery.
Oba framweorki doczakały się książek.

	jQuery:
	
		Learning jQuery
		jQuery Reference Guide
	
	prototype:
	
		Prototype and Scriptaculous in Action
		Prototype and script.aculo.us: You Never Knew JavaScript Could Do This!
	

Podsumowanie
Ciężko mi wybrać ten lepsiejszy framework. I na pewno wybór ten nie będzie obiektywny – każdy musi sam rozważyć czego oczekuje po bibliotece.
Wydaje mi się, że przy projekcie, który w tym momencie zaczynam bardziej sprawdzi się jQuery. Mam w głowie ułożony zaawansowany interfejs użytkownika i nie chciałbym żadnych zgrzytów, a jak pokazuje przykład scriptaculous, płynność różnych efektów nie ma wiele wspólnego z szybkością biblioteki.
Z drugiej strony jeżeli ktoś uważa, że będzie wykonywał po stronie użytkownika sporo obliczeń, pętli, działania na dużych tablicach itp. itd. prawdopodobnie dobrym wyborem będzie prototype – nie dość, że jest łatwiej wykonywać te czynności, to jeszcze wszystko działa szybciej.
Mam nadzieję, że powyższy opis pomoże w wybraniu biblioteki lepszej do rozwiązania danego problemu. Jeżeli pominąłem jakieś soczyste właściwości którejś z bibliotek proszę o komentarz – uzupełnię porównanie :)


Książki
2007-09-01T00:00:00-07:00
Zdarza mi się ostatnimi czasy przeczytać komentarz, że książki programistyczne są już niepotrzebne, bo i tak wszystko jest w necie. A nawet, cytuję: “w książkach to jest naćkane, jak chcesz konkretów to nie kupuj książek”.
Całkiem głupie to ;-)
Dla mnie książki programistyczne są niezastąpione. I najchętniej kupiłbym sobie połowę pozycji dostępnych na rynku. Po czym prawdopodobnie 1/3 bym nie przeczytał, ale to już inna kwestia. Ogólnie rzecz biorąc większości rzeczy zawartych w książkach można pewnie nauczyć się samemu, z lekką pomocą wujka Googla. Ale o ile przyjemniej przeczytać jak to robią profesjonaliści (o ile nikt nie da się nabrać niektórym profesjonalistom inaczej)
Po takim wstępie nie mogę się nie pochwalić, że jakiś czas temu kupiłem wspólnie z ludźmi od nowego projektu (na razie nie zapeszam. za jakiś czas pewnie coś napiszę) parę bardzo fajnych książek.

	Don’t make me think – genialna książka o usability. Bardzo krótka i treściwa. Autor starał się napisać książkę, którą będzie się dało przeczytać w parę godzin. I muszę przyznać, że bardzo dobrze mu to wyszło. Idealna dla ludzi, którzy nie są specami w tej kwestii, a chcą poprawić użyteczność swoich stron.


	Agile development with Rails – Pozycja obowiązkowa dla uczących się RoR. Co prawda teraz niewiele mi się przyda, ale czułbym się źle jakby jej nie kupił. Korzystałem dość sporo z ebooka z amule’a. No i przyda się bliźniemu, który właśnie zaczyna się uczyć RoR.


	Ruby for Rails – jeszcze nie przeczytałem, ale po przekartkowaniu zapowiada się bardzo ciekawie. Napiszę coś więcej jak wreszcie się za nią wezmę ;-)


	The Ruby Way – bardzo dobra książka. Jestem właśnie w trakcie czytania. Podaje bardzo dużo rozwiązań często spotykanych problemów zgddnie z “ruby way”. Ponad 600 stron esencji programowania ;-)


	JavaScript: The Definitive Guide – niektórzy narzekają, że książka bardziej zbliżona jest do dokumentacji niż do książki “do nauki”. Dla mnie to plus. Javascripta znam całkiem dobrze. Pewnie dzięki temu, że w poprzednim stuleciu, kiedy o bibliotekach takich jak jQuery nikt nie słyszał, bawiłem się w pisanie różnego rodzaju latających warstw, wysuwanych menu i innych arkanoidów (nawet fajnie się grało ;-). W tym momencie potrzebuję właśnie takiej dokumentacji, do której mogę spojrzeć podczas pisania i zobaczyć jakie metody udostępnia dana klasa, albo jak powinien się zachowywać jakiś kod. Jeżeli ktoś chce pisać coś więcej niż efekty z użyciem jQuery (czy innego script.aculo.us), to naprawdę zachęcam do kupna.

Podejrzewam, że gdyby początkujący programiści więcej inwestowali w wiedzę książkową to byłoby dużo mniej partactwa. Szczególnie, że książki związane z Rubim i RoR oprócz nauki programowania próbują od początku wpajać dobre praktyki programistyczne. I koniecznie trzeba przeczytać Pragmatycznego programistę :)


Dlaczego jQuery?
2007-08-31T00:00:00-07:00
Jako javascriptowego frameworka (z góry przepraszam ukrytych purystów językowych za brutalne wrzucanie spolszczonych angielszczyzmów – w razie czego proszę o wersję przetłumaczoną w komentarzu, trochę humoru zawsze się przyda) przez długi czas używałem zestawu prototype + script.aculo.us. Po krótkim czasie przywiązałem się i stwierdziłem, że nie ma sensu sprawdzać innych możliwości

	bo i tak większość frameworków oferuje podobne możliwości
	będę musiał stracić czas na nauczenie się czegoś nowego
	Ruby on Rails wspiera powyżej wymieniony zestaw

Właściwie to “wybranie” prototype’a było bezpośrednim następstwem ostatniego punktu. Pomyślałem, że skoro DHH wybrał ten framework, to coś w tym musi być. Podejrzewam, że w rzeczywistości było to spowodowane tym, że jQuery miał w tamtym okresie małą popularność (o ile w ogóle istniał). Patrząc na to jak wyglądają obie biblioteki można odnieść wrażenie, że filozofię dużo bliższą Railsom realizuje jQuery.
Najlepiej to widać patrząc na przykłady:
prototype:
  new Ajax.Updater('id', url, { method: 'get', parameters: par });
  var anchors = document.getElementsByTagName('a');
    for (var i=0; i<anchors.length; i++)
    {
        var anchor = anchors[i];
        var relAttribute = String(anchor.getAttribute('rel'));
        if (relAttribute.toLowerCase().match('history'))
        {
            Event.observe(anchor, 'click', function(){
              //siakaś funkcja
             });
        }
    }


jQuery:
  $('#id').load(url + par);
  $("a[@rel='history']").click(function(){
    //siakaś funkcja
  });


Od razu widać po której stronie stoi przejrzystość (i jasna strona mocy). Ten drugi przykład może nie być już aktualny, bo ostatnio programiści prototype wzięli się do roboty i co jakiś czas zamieszczają wiadomości o zmianach w API, ale takich kawałków można wkleić dużo więcej. Wszystko idzie w dobrą stronę, ale nie wiem czy uda się w niedalekiej przyszłości uzyskać lekkość jQuery.
Ruby on Rails niestety nie mają wsparcia dla jQuery, ale nie jest tak źle. Selektor elementów w RJS’ach dalej będzie działał, resztę kodu można wrzucać bezpośrednio poprzez `page <<`, a brak helperów? Możnaby je przepisać (i zapewne ktoś już to zaczął robić). Aczkolwiek pojawiają się głosy, że domyślne helpery w RoR są krnąbrne oraz złe. Po części całkiem słusznie. Z drugiej strony w niektórych aplikacjach nie ma sensu robić obsługi bez javascriptu (jakieś rozbudowane interfejsy użytkownika), a podobno używanie event handlerów jest wolniejsze niż zwykły onclick. Jak zwykle wszystko zależy od zastosowań i potrzeb. Ciężkie jest życie programisty. Kiedyś padnę na zawał od takiego nawału trudnych decyzji do podjęcia ;)
Jako dalszą lekturę polecam propagandę na blogu jQuery i doniesienia o nowej wersji, gdzie można podziwiać wyniki zabiegów optymalizacyjnych i sporo nowych mechanizmów. Całkiem niedawno jQuery doczekało się książki. Dużym plusem jest też ogromna ilość rozszerzeń. Lista wygląda imponująco.
Jedyne co mnie ostatnio zaniepokoiło to przesiadka z jQuery na prototype, o której mówi Zbigniew Sobiecki w wywiadzie. Jego doświadczenie widać najlepiej patrząc na blipa, więc jakieś powody musi mieć. Będę musiał to zbadać ;)
W każdym razie w tym momencie moim frameworkiem javascriptowym “of choice” jest jQuery. Jeżeli ktoś zna argumenty przemawiające za pozostaniem przy prototype i script.aculo.us niech się nie krępuje i zostawi komentarz.
Dopisane:

Znalazłem wczoraj fajne narzędzie do benchmarków. Niestety wersje bibliotek nie są najnowsze, co owocuje cienkimi wynikami jQuery, ale na szczęście jest link do źródeł, więc można wrzucić swoje wersje (ostatnie stabilne wersje jQuery i prototype). Jak widać na obrazkach twórcy jQuery włożyli ogromną ilość pracy w optymalizację, ale cały czas jeszcze trochę brakuje, żeby dogonić prototype.
Rozmawiałem wczoraj ze sztywnym na blipie (jest teraz jednym z developerów blipa). Zwrócił mi uwagę na parę rzeczy, które mi umknęły. Jedną z nich jest brak rozszerzeń dla obiektów istniejących już w javascripcie. Prototype udostępnia bardzo dużo metod, wzorowanych głównie na metodach rubiego, które ułatwiają pracę z typami wbudowanymi (wszelkie iteratory typu collect, each, any, all, różne metody dla klasy String, hashe itp. itd.). Szczerze mówiąc nawet nie pomyślałem, że nic podobnego nie ma w jQuery – przerzuciłem się dosłownie parę dni temu i nie pisałem nic większego. W takim momencie trzeba zadać sobie pytanie co jest priorytetem w danym projekcie. Oczywiście warto znać obie biblioteki, ale niestety do danego zadania trzeba wybrać jedną z nich (teoretycznie nic nie stoi na przeszkodzie, żeby załączyć obie, dzięki jQuery.noConflict, ale trzeba się liczyć z dodatkowymi kilobajtami).
Przejrzałem dodatkowo bloga prototypa i pojawia się cały czas sporo fajnych rzeczy. Myślę, że przy wyborze między tymi dwoma bibliotekami trzeba pomyśleć czy bardziej przydatne będą efekty wizualne i ogólnie grzebanie w CSS i DOM, czy stawiamy na pisanie różnych funkcji “niższego poziomu”. Najgorsze jest to, że wydaje mi się, że w projekcie, który zaczynam będzie się to rozkładało mniej więcej po połowie. Coś czuję, że wrócę jeszcze do tego tematu.


Kilka przydatnych linków
2007-08-25T00:00:00-07:00
Dawno nic nie pisałem, przez co mogło się niektórym wydawać, że blog umarł śmiercią naturalną. Bądź też ja umarłem (śmiercią niekoniecznie naturalną). Jak można dość łatwo zauważyć myśli o owych śmierciach (dwóch! chwila nieuwagi i sytuacja ociera się o żałobę narodową) były mocno przesadzone.
Na dobry początek reanimacji ledwo dychającego już blogusia tytułowe przydatne linki:

	Toggl – podczas pracy, szczególnie w domu, można bardzo łatwo zacząć zajmować się tysiącem rzeczy, które przerwą kodzenie. Toggl jest serwisem, który pozwala zmierzyć realny czas pracy. Dodaję nowy projekt, klikam “start” i zegar zaczyna tykać. I tyka tak sobie licząc godziny pracy. Od kilku dni takie liczenie pomaga mi bardzo w skupieniu nad pisaniem. Jak już chcę kliknąć na zakładkę z google readerem, to zaraz przychodzi myśl, że będę musiał przystopować toggl i realny czas pracy będzie dużo mniejszy.
	jQuery doczekało się kolejnej już wersji. Jak zwykle dużo nowych bajerów i jeszcze szybsze działanie (a po ostatnim “800% faster” myślałem, że dużo więcej nie wyciągną). Właściwie to na jQuery przesiadłem się dosyć niedawno i jako były-wielki-fan™ script.aculo.us czuję się zobligowany do napisania artykułu o tym co otworzyło mi oczy. Beware!
	Mashable przygotowało spis narzędzi do google readera. Wreszcie jakaś lista “x tools for…”, która mi się przydała. Polecam skin w stylu OS X. Naprawdę cieszy oko. Aż chce się zacząć przeglądać pomimo straszącego 100+

Na dzisiaj tyle. Oby to nie był ostatni post w przeciągu kolejnych kliku miesięcy. Trzymajcie kciuki.


Postanowienia na rok 2007
2006-12-31T00:00:00-08:00
A jakże ;-)

	napisać wreszcie i wypuścić jeden (może więcej?) z serwisów, na które mam pomysły. sporo tego jest, w większości serwisy niszowe i dość hermetyczne połączone z moimi zainteresowaniami. głównie na zasadzie: a gdybym tak miał możliwość…. (takie moje egoistyczne pobudki :) )
	uporządkować sprawy na uczelni (czyt. zaliczyć zaległe egzaminy, laborki, ćwiczenia)
	w kwestii nauki i poznawania nowych narzędzi:
	
		zostać guru w Rubim i Railsach ;)
		może Python i Django?
		Java – w stronę programowania na PDA itp.
		poznać lepiej JavaScript – żeby nie ograniczać się tylko do tego co oferują biblioteki typu Prototype/Scriptaculous, czy niezbyt wyrafinowane skrypty napisane przezemnie
		Google Maps
	
	wyremontować Misia Yogiego
	więcej czasu poświęcać bliskim :) (coś czuję, że ostatnio zaniedbuję znajomych bardziej niż zwykle)

Na razie nic więcej nie przychodzi mi do głowy. Pozostaje mi tylko życzyć wszystkiem szczęśliwego nowego roku :)


WAT on Rails
2006-12-07T00:00:00-08:00
W ramach pierwszego sympozjum CyberGuru na Wojskowej Akademii Technicznej w Warszawie wygłosiłem dzisiaj prezentację Przedstawienie framework'a Ruby on Rails. CeyberGuru skupia studentów, którzy chcą rozwijać swoje zainteresowania informatyczne. Do tej pory grupy wchodzące w skład CyberGuru były w większości mało aktywne, o ile w ogóle miały jakichś członków. Dość niedawno powstała inicjatywa odświeżenia owej organizacji, owocem której jest pierwsze (i mam nadzieję nie ostatnie) sympozjum.

Jeżeli chodzi o przebieg sympozjum to było bardzo przyjemnie. Wygłoszone prezentacje:
* Bezepieczeństwo aplikacji webowych, Krzysztof Wilkos
* Przedstawienie framework'a Ruby on Rails, Piotr Sarnacki
* Java w zastosowaniach wbudowanych, Andrzej Olszak
* Wprowadzenie do C# - Jakub Bańkowski

Wszystko nieco się przedłużyło - nie mamy dużego doświadczenia w orgaznizowaniu takich spotkań, więc prezentacje trwały dłużej niż zakładaliśmy. Uczestnicy sympozjum wypełnili ankiety, dzięki czemu będziemy wiedzieli co zmienić. Z tego co widziałem przydałoby się więcej przykładów, a mniej teorii. Prawdopodobnie będziemy dążyli wtedy do zmniejszenia liczby referatów podczas jednego sympozjum, co automatycznie wydłuży czas trwania pojedyńczego referatu.

Korzystając z okazji, po prezentacji, powiedziałem o swoim pomyśle stworzenia grupy webowej. Chciałbym zebrać ludzi zainteresowanych pisaniem i rozwijaniem aplikacji internetowych i rozpocząć pracę nad (bliżej jeszcze neisprecyzowanym) wspólnym projektem. Jedyne co na razie mogę powiedzieć na pewno - będziemy pisać używając Ruby on Rails. Jeżeli coś z tego wyniknie na pewno o tym napiszę.