Napi GWT

1. Az anonymous inner classokkal több baj is van:

• Nem szerializálhatóak GWT.RPC szerint.
• Ha egy ilyenbe egy másik anonymous innder class-t hozol létre, az életbe nem fogsz tudni bele debugolni hosted módban.

2. (vrg találmánya) Tömb rendezése nagy tömböknél iszonyat belassúl. Az a működő megoldás, ha a javascript natív sort-ot hívjuk meg. Valószínű alapból a GWT a Java SE nagyon rafinált de kicsit bonyolult megoldását próbálja javascriptre fordítani.

Challenge 24 tapasztalatok.

Tapasztalatok:

• Bámulatos mi mindent meg lehet oldani brute force-szal.
• Meglepő milyen nehéz még brute-force algoritmust is megfogalmazni, ha nem vagyunk járatosak algoritmus elméletben.
• Nem voltunk járatosok algoritmus elméletben.
• Abszolút felkészületlenek voltunk.
• Legközelebb fizikailag egy teremben leszünk, és rászánjuk az időt, hogy minden problémát jól átbeszélünk.
• Legközelebb úgy intézzük, hogy a 3 emberből ne csak 2 érjen rá az EC alatt.

Viszont egész lelkesek lettünk az algoritmus elmélet iránt, és most éppen jobbnál jobb megoldások után guglizunk, és utólag megírjuk magunknak a megoldásokat. Most pl. épp a suffix tree napi téma.

Kérdés: Vajon, ha elmélyedünk az algoritmus elméletben, akkor lesz olyan, hogy a napi munkánkban tudni fogjuk ezt használni? (Úgy mint pl. a tervezési mintákat, amik csak előbukkannak a fű alóll, itt-ott).

+1. A szervezőknek minden tisztelet. Teljesen jó volt.

Továbbra is GWT

A GWT a maga "correct level of abstraction"-jával, azért elég sok kérdést nyitva hagy. Bár lassan alakulnak a frameworkok hozzá, azért ezek még koránt sincsenek kiforva teljesen.

Nekünk most lassan 2-3 hónap projekt tapasztalat után kezdi kiforni magát a saját rendszerünk. Még 1-2 hónap és tényleg neki állhatunk újra írni az egészet, és akkor jó lesz.

A reflectionunkat pl. a gwittir-től loptuk bár egyik tanult kolegám még csavart rajta kicsit. A többi részt viszont nem használjuk belőle, mert bár nagyon jó MVC jellegű felépítése és binding-jai vannak, nekünk egy kicsit komponens alapúbb speciálisabb rendszer kellett. De kezd az látszani, hogy bár nyilván ennek is megvannak a korlátai, azért elég komoly rendszert lehet belőle építeni.

Kis színes

1. Egyrészt, még a hétvégén Sun Java System Web Server helyett Apache httpd + mod_jk + Glassfish került a szerverre. Ennek örömére rögtön fel is javítottam két régi ROME alkalmazást, és deployoltam. Ez az az napi névnapokat adja feedben. Ez pedig minden napra egy híres ember születés napját adja ki. (A születésnapokat még 5-6 éve gyűjtöttük egy barátommal abból a megfontolásból, hogy tudjuk, hogy melyik nap kire iszunk.)

2. Egy kicsit próbálom hírekkel élénkíteni a jhacks-et. Még nem tudom pontosan mi lesz belőle, mindenesetre a rövid hír jellegű postok ezentúl odamennek (Ha van valakinek jó külföldi/belföldi Java-s blog ajánlata az jöhet, mert nagyon nehéz naponta/kétnaponta értékelhető hírt összeszeni.) Aki még nem bookmarkolta a feedjet, annak ezt is csak ajánlani tudom.

3. Az utolsó pillanatban neveztünk a Challenge24-re a kollektívával. Nem tudom mi lesz belőlre, mert algoritmuselméletből elég támadható vagyok, ide meg az pl. erősen jól jön, de majd még meglátjuk. Még vasárnapig lehet nevezni.

Openfire + Pidgin

The solution: Use only the first part of your domain in the Domain field (Basic tab) eg. domain and the fully qualified domain name in the Connect Server field (Advanced tab) eg. domain.com.

Ez a fenti csak azok kedvéért, akik a gugliból jönnek a kulcsszóra. Csak, hogy ők se csalódjanak. Egyénként az Openfire nagyon kezes Jabber szerver. Letölt, elindít, és megy. (Csak arra kell vigyázni, hogy ha 8080-as porton valaki figyel, akkor a defaultból bekapcsolt HTTP bind-del összeakad). Van hozzá enterprise is, de az Open Source változat is mindent tud. Van hozzá szép webes admin felület is, kattintgatós.

Sajnos a Pidginnek egy kicsit imádkoni kellett, hogy menjen vele (lásd felül), nem volt időm még tetten érni, de vagy a Pidgin, vagy az Openfire valamelyik hash (talán MD5?) implementációja különbözik.