Erik Burke írt néhány dolgot, arról, amikor használunk ugyan verzió kontroll rendszert, de valami azért mégse 100-as vele. A gyanús jelek szerinte:
1. Ha a helyett, hogy törölnénk a kódból inkább kommentezünk, hátha még kelleni fog a jövőben. Hülyeség: a verzió kezelő pont arra való, hogy megnézd az előző verziót. (Nálunk ez rendesen be van tartatva, code reviewn nem megy át, ha kikommentezett sorok vannak.)
2. Hetente egy nagy kommit, sok kis helyett. (Nálunk sajnos a rendszer miatt ez van. A clearquest-re ráépített rendszerben egy task = egy kommit, ami akár 40 órás task is lehet. Ha közben másnak is kénének újonnan létrejött fájlok, akkor nincs más mint local copy.)
3. Fizikai backup biztos ami biztos (ami ugye felesleges, mert a verzió kezelő sokkal jobb backupot ad). (Szerintem ez azért annyira nem probléma. Legalábbis nálunk nem fordul elő.)
4. History log: ahelyett, hogy a verziókezelőbe írnánk commitkor mi változott, a fájlok elején txt-be írunk valami log félét. (Abszolút igaza van, nálunk pont ez van, és idegesít is.)
Szóval nálunk a kincstári projektek 4/2 arány érnek el. Lenne még hová...
2007/09/30
2007/09/28
SJSWS => Glassfish 2
Le kéne cserélni a Sun Java System Web Server-t Glassfishre. Nem csak azért, mert a config deploy a SJSWS-nél bűn lassú (percekig tart), ezt talán be lehetne jól konfigurálni, és nem is csak azért, hogy hódoljak a Glassfish hype-nak, és trendi legyek, de jól jönne egy futó JBI konténer is, és a Web Service támogatása is jobb. A baj csak az, hogy bár a Glassfish végre nagyjából kezeli a virtual hostokat, egy csomó kényelmi szolgáltatás ami webhostingolásnál hasznos nincs benne. Pl. nem lehet jól beállítani, hogy egyes könyvtárakhoz csak jelszóval lehessen hozzáférni.
Az ideális az lenne, hogy ha lenne egy Servlet/Filterem-em, ami értelmezné a .htaccess fájlokat, (legalább mondjuk a jelszós részeket, vagy ne adj isten a ModeRewrite-ot is), és azt be tudnám deployolni default webappnak, ahová kéne. Nem is lenne nagy dolog megírni, csak épp most úgy tűnik semmi időm nem lesz ilyenre. Ha valaki tud ilyenről készen, az ne habozzon szólni (pl. Jettyben láttam hasonlót, csak az nem csak egy servlet, hanem + kismillió függőség, nem nagyon lehet kibányászni).
Ja meg PHP támoatás is kéne, de ez Scripting API-val + Quercus-szal simán szerintem simán menni fog.
Az ideális az lenne, hogy ha lenne egy Servlet/Filterem-em, ami értelmezné a .htaccess fájlokat, (legalább mondjuk a jelszós részeket, vagy ne adj isten a ModeRewrite-ot is), és azt be tudnám deployolni default webappnak, ahová kéne. Nem is lenne nagy dolog megírni, csak épp most úgy tűnik semmi időm nem lesz ilyenre. Ha valaki tud ilyenről készen, az ne habozzon szólni (pl. Jettyben láttam hasonlót, csak az nem csak egy servlet, hanem + kismillió függőség, nem nagyon lehet kibányászni).
Ja meg PHP támoatás is kéne, de ez Scripting API-val + Quercus-szal simán szerintem simán menni fog.
2007/09/24
Deployer role
A hagyományos JSR speckók mindig ugykezdődnek, hogy szerepköröket definiálnak (Deployer, Application Assembler, Bean Provider) persze sokszor egy ember több szerepkört is megvalósít, ahogy én is a hétvégén amikor néhány percem volt, probáltam egy JCR-es alkalmazást deployolni Sun Web Server és Glassdish alá. Egyik se sikerült tökéletesen (Tomcat 6 alatt remekül fut), úgy hogy debug gyanánt az egyre kiválóbb jcr-explorer-t próbáltam feltenni. Persze azt is sikertelenül.
És itt enyyi, ez egy olyan bejegyzés, aminek nem lesz csattanója. Ha csak nem az, hogy bug reporttoltam (hátha), és a fejlesztő már replayolt is, kössz, hogy szólok, ő JBoss-t használ, és hogy milyen sok szívás van a sok JSF implementáció között.
Így megy ez.
És itt enyyi, ez egy olyan bejegyzés, aminek nem lesz csattanója. Ha csak nem az, hogy bug reporttoltam (hátha), és a fejlesztő már replayolt is, kössz, hogy szólok, ő JBoss-t használ, és hogy milyen sok szívás van a sok JSF implementáció között.
Így megy ez.
2007/09/19
Wicket nyűgök
Na ez tipikusab olyan bejegyzés lesz, ami csak annak érdekes, aki szintén benne van a Wicketben. Két probléma:
1. Ha a WicketFilter-t nem /app/*-ra, hanem /*-ra meppelem, akkor a HomePage-ben a css hivatkozásot (default.css) helyelenul kicseréli egy ../default.cs-re. Ugyanezt az egyenkint felmountolt aloldalakon helyesen oldja meg. Próbáltam bug reportolni, de egyelőre még nem találtam meg, hol a hiba. Workaround: a fő oldalt is fel kell monutolni az Application osztályba valamilyen Bookmarkable címre.
2. Ha Rss-t csinálok ezzel a módszerrel (Gyakorlatilag egyetlen bridge osztály a Rome használatához), akkor nem csak, hogy nem működik, hanem az rss feed helyett kiírja $TOMCAT_HOME/bin tartalmát. Na már most ezt se tudom kinek a hibája (Tomcat/Wicket/Wicket-rome/saját magan), de ez így nagyon durva. Workaround még nincs. Mindjárt megpróbálom Glassfish alatt. (BTW. tudtátok, hogy Glassfish 2 elvileg képes értelmezni deploykor a tomcat-es context.xml-eket?)
1. Ha a WicketFilter-t nem /app/*-ra, hanem /*-ra meppelem, akkor a HomePage-ben a css hivatkozásot (default.css) helyelenul kicseréli egy ../default.cs-re. Ugyanezt az egyenkint felmountolt aloldalakon helyesen oldja meg. Próbáltam bug reportolni, de egyelőre még nem találtam meg, hol a hiba. Workaround: a fő oldalt is fel kell monutolni az Application osztályba valamilyen Bookmarkable címre.
2. Ha Rss-t csinálok ezzel a módszerrel (Gyakorlatilag egyetlen bridge osztály a Rome használatához), akkor nem csak, hogy nem működik, hanem az rss feed helyett kiírja $TOMCAT_HOME/bin tartalmát. Na már most ezt se tudom kinek a hibája (Tomcat/Wicket/Wicket-rome/saját magan), de ez így nagyon durva. Workaround még nincs. Mindjárt megpróbálom Glassfish alatt. (BTW. tudtátok, hogy Glassfish 2 elvileg képes értelmezni deploykor a tomcat-es context.xml-eket?)
2007/09/17
Szép URL-ek
Szeretik a keresők, szeretik az emberek, esztétikus jó ilatú, stb. Ilyet szeretnék mindenhová. A vonzódásom története valami ilyesmi:
Hajdan, még Post-Nukés gyerekkoromban volt az index.php?mod=foo&bar=func¶m=1&.... A Front Controller megkereste a foo modult, annak a saját kis frontcontrollere megvalósította a func funkciót, a paramétereket meg beparzolta a funkció.
Aztán jöttek az ügyes apache rewriteok: index.php/foo/bar?par=... csak kicsit szebb, de nem az igazi.
Aztán megismertem, hogy hogyan csinálja ezt a Drupal. A Drupal-ba alapból csak szép URL-ek vannak. Van egy nagy fa szerkezet, és abba egy path egy modul funkció. Ezt pedig szép szorgalmasan fel kel meppelgetni.
Pl. (hasból) a admin/user/rights => admin_user_rights()-hoz lehet rendelni.
A nagy bravúr benne, hogy ha nem talál a megadott path-hoz hozzárendelve függvényt, akkor elkezdi leszedegetni a részeket / jelenként jobbról balra. Pl. a node/edit/22-höz ha nincs rendelve semmi függvény, akkor a node/edit-hez keres (amihez valószínű lesz), és a 22-t átadja paraméternek.
Ebből következik, hogy a paraméterek a drupálban sokszor nem kulcs érték párok, hanem pozíciók. Az ismert meppelés után első, második, harmadik... stb. Szerintem ez mondjuk sokkal szebb és logikusabb mint az előbbi.
Wicket-ben ez úgy néz ki, hogy alapból az oldalak amiket létrehozunk nem kapnak szép URL-t (sőt rosszabb esetben a csúnya url-n se lehet kívülről elérni őket). Hasonlóan a Drupalhoz kézzel a mappinget beállítani (WebApplication.mountShortBookmarkablePage()). A baj csak azzal van, hogy nem a Drupal féle pozíció=> paraméter leképezést használja, hanem a kulcs érték párosat, ami nekem kevésbé tetszik. Igaz ezt hajlandó akár az oldal/param1/value1/param2/value2 alakban is használni (oldal/value1/value2 helyett, amit én szeretnék).
Megoldás: lesszármaztatni a BookmarkablePageRequestTargetUrlCodingStrategy-t és újra implementálni a decodeParameters-t és a appendParameters-t (ezt a szűlőben látott mint alapján nem nagy flikk-flakk). Ezután a mappelést a WebApplication osztályból a
mount(new AnzixBookmarkablePageRequestTargetUrlCodingStrategy(path, bookmarkablePageClass, null));
paranccsal tehetjük meg. Persze még lehet csinosíthatni, hogy a pozícióhoz rendelt paraméterek lekéréséhez frankó gettereket írunk valami leszármaztotott helyre, de ez innentől újgyakorlat.
Marad viszonta kérdés: Hogyan csináljam meg ugyanezt JSF-ben?
Hajdan, még Post-Nukés gyerekkoromban volt az index.php?mod=foo&bar=func¶m=1&.... A Front Controller megkereste a foo modult, annak a saját kis frontcontrollere megvalósította a func funkciót, a paramétereket meg beparzolta a funkció.
Aztán jöttek az ügyes apache rewriteok: index.php/foo/bar?par=... csak kicsit szebb, de nem az igazi.
Aztán megismertem, hogy hogyan csinálja ezt a Drupal. A Drupal-ba alapból csak szép URL-ek vannak. Van egy nagy fa szerkezet, és abba egy path egy modul funkció. Ezt pedig szép szorgalmasan fel kel meppelgetni.
Pl. (hasból) a admin/user/rights => admin_user_rights()-hoz lehet rendelni.
A nagy bravúr benne, hogy ha nem talál a megadott path-hoz hozzárendelve függvényt, akkor elkezdi leszedegetni a részeket / jelenként jobbról balra. Pl. a node/edit/22-höz ha nincs rendelve semmi függvény, akkor a node/edit-hez keres (amihez valószínű lesz), és a 22-t átadja paraméternek.
Ebből következik, hogy a paraméterek a drupálban sokszor nem kulcs érték párok, hanem pozíciók. Az ismert meppelés után első, második, harmadik... stb. Szerintem ez mondjuk sokkal szebb és logikusabb mint az előbbi.
Wicket-ben ez úgy néz ki, hogy alapból az oldalak amiket létrehozunk nem kapnak szép URL-t (sőt rosszabb esetben a csúnya url-n se lehet kívülről elérni őket). Hasonlóan a Drupalhoz kézzel a mappinget beállítani (WebApplication.mountShortBookmarkablePage()). A baj csak azzal van, hogy nem a Drupal féle pozíció=> paraméter leképezést használja, hanem a kulcs érték párosat, ami nekem kevésbé tetszik. Igaz ezt hajlandó akár az oldal/param1/value1/param2/value2 alakban is használni (oldal/value1/value2 helyett, amit én szeretnék).
Megoldás: lesszármaztatni a BookmarkablePageRequestTargetUrlCodingStrategy-t és újra implementálni a decodeParameters-t és a appendParameters-t (ezt a szűlőben látott mint alapján nem nagy flikk-flakk). Ezután a mappelést a WebApplication osztályból a
mount(new AnzixBookmarkablePageRequestTargetUrlCodingStrategy(path, bookmarkablePageClass, null));
paranccsal tehetjük meg. Persze még lehet csinosíthatni, hogy a pozícióhoz rendelt paraméterek lekéréséhez frankó gettereket írunk valami leszármaztotott helyre, de ez innentől újgyakorlat.
Marad viszonta kérdés: Hogyan csináljam meg ugyanezt JSF-ben?
Feliratkozás:
Bejegyzések (Atom)