Ruby 1.9 i Rails 2.3.4

Tips and tricks
1

Część osób próbuje korzystać z Ruby 1.9 i najnowszych Railsów (w momencie pisania 2.3.4).

Jest jednak sporo problemów, które trzeba rozwiązać, aby Railsy zaczęły działać. W tym wątku chciałbym umieścić
informacje o tych problemach oraz o najbardziej sensownych rozwiązaniach.

  1. Mongrel - posiada stare wywołania RSTRING§->ptr oraz RSTRING§->len

Rozwiązanie: mongrel.patch

  1. Kodowanie znaków w widokach - domyślnie brane jest zdaje się z LC_ALL, co powoduje błędy pt. Encoding::CompatibilityError: incompatible character encodings: …

Można to nadpisać w config/environment.rb

Encoding.default_external="UTF-8"

Nie zawsze jednak wystarcza! Patrz niżej.

  1. Problem w implementacji message_verifier (aka “undefined method `^’ for String”) - rozwiązanie:
    patch Jakuba Kuźmy

  2. Mysql - problem zarówno z RSTRINGIEM, jak i z właściwą obsługą kodowania. Rozwiązanie:
    “poprawiona” wersja MySql-a. Uwaga: piszę w cudzysłowie, bo rozwiązanie jest bardzo powierzchowne, zakłada, że w bazie trzymamy dane w UTF-8, co nie zawsze jest prawdą.

  3. Jak wyżej dla Postgresa. Rozwiązanie poprawiona wersja PG. Działa ale tylko połowicznie - tzn. jeśli wszędzie mamy utf-8, to spoko. Jeśli jednak po stronie aplikacji chcielibyśmy używać np. iso, a w DB UTF-8, to niestety się wykrzaczy. Problem polega na tym, że prze wysłaniem łańcucha do serwera SQL nie jest sprawdzane jego kodowanie.

2

Na mojej stronie można znaleźć prosty sposób na łatanie Railsów i gemów tak, aby nie trzeba było trzymać wszystkiego w repozytorium: http://jah.pl/articles/patching-rails-and-gems-locally.html

3

Ciekawy sposób, skorzystam pewnie :slight_smile:

4

Dwa nowe odkrycia:

  1. sqlite3 - też problem z kodowaniem. Znowu rozwiązanie Qoobyy okazało się pomocne: http://github.com/qoobaa/sqlite3-ruby

isitruby19.com to strona, na której można sprawdzać, czy gemy działają pod 1.9. Tak jak w powyższym przypadku, odpowiedzi pozytywne, nie znaczą, że wszystko pięknie śmiga. Ale często jest to najłatwiejszy sposób na znalezienie rozwiązanie.

5

A ktoś z Was korzystał już może z Ruby 1.9 na produkcji?

Wyprodukowałem kod, który działa bez problemów, na kilka rzeczy wrzuciłem patch i wygląda na to, że itisruby19. :wink: Warto próbować?

6

No ja ostatnio miałem porażkę, której póki co nie udało mi się rozwiązać.
U mnie “produkcja”, to np. 40 studentów piszących samosprawdzające się sprawdziany z Rubiego :slight_smile:

7

[quote=apohllo]No ja ostatnio miałem porażkę, której póki co nie udało mi się rozwiązać.
U mnie “produkcja”, to np. 40 studentów piszących samosprawdzające się sprawdziany z Rubiego :)[/quote]
Uuu… taka produkcja to pewnie potrafi wyłożyć każdą aplikację :smiley:

8

http://twitter.com/wycats/status/5704368992 - chyba zaczynają poważniej podchodzić do 1.9 :slight_smile:

9

[quote=drogus][quote=apohllo]No ja ostatnio miałem porażkę, której póki co nie udało mi się rozwiązać.
U mnie “produkcja”, to np. 40 studentów piszących samosprawdzające się sprawdziany z Rubiego :)[/quote]
Uuu… taka produkcja to pewnie potrafi wyłożyć każdą aplikację :D[/quote]
Z pewnością - mówisz im - napiszcie funkcję, która akceptuje parametry i zwraca wartość, bla, bla, bla i jakiś 20% zacznie używać puts i gets :smiley:

A co do meritum - kolejna zagwozdka rozwiązana - passenger nie przekazuje zmiennych LANG i LC_CTYPE, przez co nawet jak odpalamy aplikację w produkcji via mongerl lub webrick i wszystko bangla, to w Passengerze mogą być klocki.

Rozwiązanie - ruby_wrapper:

#!/bin/bash exec /usr/local/bin/ruby -E utf-8:utf-8 "$@"
Zamiast zwykłego rubiego, podsuwamy mu taki “egzekutabel” (PassengerRuby … w pliku konfiguracyjnym Apache’a lub Nginxa) i jeśli używamy utf-8 to powinno pomóc (w szczególności w odniesieniu do templatów Hamla lub Erb’a, aka “invalid byte sequence in US-ASCII”)

10

A to znana przypadłość studentów :slight_smile: