afpfs-ng-t ha fordítanál, hogy teljesen például AFP mountokat húzz be Linux alatt, fordítás előtt győződj meg, hogy a build-essential libgcrypt11-dev libgmp3-doc libmpfr-dev libgcrypt11 libgcrypt11-dbg libgmp3-dev libgmp3c2 csomagok, meg a readline és a fuse csomagok forrásostól telepítve vannak. Különben meglepődsz és nem fogod érteni, hogy miért csak Cleartext UAM lesz elérhető. (Telepítés után futtass afp_client status-t, hogy ellenőrizd, milyen UAMokat fordított le végül a make. Helyes válasz: UAMs compiled in: Cleartxt Passwrd, No User Authent, Randnum Exchange, 2-Way Randnum Exchange, DHCAST128, DHX2)
Kiegészítés az előzőhöz
Írtam, hogy szerintem hogyan érdemes és ideális dev környezetben a passengert használni.
Azóta ez két aprósággal változott:
- agresszívebben irtom a ruby processzt: került egy
PassengerPoolIdleTime 1opció is az Apache confba. - a
projekt/tmpfolderbe tettem egyalways_restart.txt-t, ami nekem valamiért csak 3-as Passenger óta működik. Most viszont már fut, tehát juhé.
Passenger + Ruby dev környezethez
Apró ötlet: elegem volt a script/server típusú szerverindítgatásból, ami ráadásul “csúnya” megoldás, mert nem magától fut, külön minden projekthez egy StartupItemet gyártani (OSX) nem túl esztétikus megoldás. Keresgélés után végül a Passenger mellett döntöttem, egyszerű telepíteni, gyorsan összetracskolható az Apache-csal. Ugyanakkor ha Rails-es projekt fejlesztése közben az initializer-ekkel kell dolgozni, macerássá válik: a Passenger a szerver indításakor felnyalja az environment.rb-t és - bár más fájlok változását észreveszi - pont az initializereket nem lehet módosítani emiatt. (Illetve nyilván lehet, csak újra kell indítani hozzá a szervert, így meg oda az elegáns, állandó újraindítgatástól mentes munka.)
Nem teljesen kézenfekvő ugyan, és a problémával is kevesen foglalkoznak, de a dokumentációból tkp. összerakható a megoldás.
<VirtualHost *>
ServerName projekt1
DocumentRoot /sites/projekt1
RailsEnv development
RailsSpawnMethod conservative
PassengerMaxRequests 1
</VirtualHost>
RailsEnv nem létszükséglet, de mindenhol javasolják, hogy konkrétan állítsuk be development módra - még nem tudom, hogy ez befolyásolja-e a Passenger viselkedését.
PassengerMaxRequests 1 - ettől a Passenger az adott app instance-ét kiüti a kiszolgált request után. Nem a legelegánsabb megoldás, de automatikus újraindítást jelent, ergo initializeres tesztelős-tracskolós időkben enyhíti a lelki bajokat.
RailsSpawnMethod conservative - amíg smart-lv2 vagy smart módban volt a szerver, a becache-elt framework kód (aminek ezek szerint része az initializers is) nem volt hajlandó “kiürülni”. Conservative módban nincs gyorstárazás, restartkor újratöltődik minden, amit szeretnénk, ellenben minden lassabb lesz: a reload miatt oldalbetöltődésenként mondjuk 3-4 sec is eltelhet.
Az előbb említett homebrew meg most éppen úgy telepíthető a legegyszerűbben, hogy
ruby -e "$(curl http://gist.github.com/raw/456062/install_homebrew.rb)"
OS X 10.6, ruby, nokogiri gem telepítése általában elhasal.
libxml2 a homebrewből telepíthető, zlibet újat kell forgatni.

Hogy ez mi volt? Mi zabált laza 1.5 gigát? Igen, a Flash, a fenébe is.
Nem érdekel, hogy a szegény, éhező dizájnerek csak Flashben tudnak bármit csinálni, ahogy az sem érdekel soha, hogy a nyomdászok átláthatatlan, nyolcvan ponton elromolni képes színkezelés nélkül halottak lennének.
Ajax-os, ámde trekkelhető url-t kellett gyártanom, facebook mintára megvalósítva. http://plugins.jquery.com/project/hashchange - van ez a plugin, azért jó, mert az összes böngésző sajátosságaira meg van benne valósítva minden, nekem csak az események elkapására meg a location.hash változtatgatására kell figyelni. A siteon írt demó
$(window).hashchange(function(){});
ugyanakkor nem működött normálisan, ti. a hashchange esemény minden hash változásnál kétszer triggerelődött.
Röviden a megoldás: $().hashchange(callback); - nem kell window. Fura.