admin February 4th, 2010
Próbálom beállítani, hogy az email notification megjelenjen a főképernyőn. Megteszem. Azt mondja, hogy először connect to mailbox first. E? Megvan, connect. Nem megy. Végül megtaláltam a megoldást. Küldjél magadnak emailt, akkor connect to mailbox, majd utána lehet beállítani, hogy az email notification menjen a főoldalra. Grrr! Latest and greatest firmware BTW.
admin November 5th, 2009
Kóstolunk Rizlinget, Chardonnay-t, pezsgőt meg még rengeteget, megtanuljuk, hogyan kell kóstolni, felszolgálási ismeretek stb. Nyamm! A végén pedig vizsga. Jó is lesz ez. 
Még 2 hét!
admin June 18th, 2009
Ismerkedem az Office 2007 ribbonjával és csak annyit tudok mondani, hogy das ist beteg. A mostani wide screen képernyőkön a képernyő két széle Word alatt kihasználatlan, simán lehet oda tenni a ribbont. De nem lehet belőle függőlegeset csinálni. Továbbá a “good old” menüre sem lehet visszaállni. A hátam közepébe kívánom ezt az UI módosítást. Sokkal bonyolultabb megtalálni egy feature-t és sokkal több helyen elvesz a képernyőből…
admin June 13th, 2009
Nem jutott eszembe a Bauhaus. De a google setsnek azt mondtam, hogy Bricostore, Baumax, Obi, Praktiker. Erre ő meg azt mondta, hogy Bauhaus. Már jópár éve a labban van, igazán felnőhetne, mert néha roppant hasznos.
admin June 1st, 2009
Tök vicces a google. Kerestem a squidre arm platformon. Erre előjött nekem mindenféle squid tentacles meg giant squid. Picit félreértett a kicsike. Vagy lehet, hogy ideje lenne az állatot átnevezni? 
admin May 31st, 2009
WAP-os megoldás. POST-ot küldenek be. User Profile nincsen. Accept header hiányzik. Csoda, hogy content-type-ot küldenek. Szerver válaszol text/html-t. Csak éppen a válasz maga nem html, de még csak nem is text. Ezért a kódért fizettek és használják! Pedig az ilyen fejlesztőt jobb helyen legfeljebb epret szedni vennék csak fel.
admin May 31st, 2009
Végre megvan, miért töri néha össze-vissza a sorokat! És költözöm ezerrel a ThinkPademre.
admin May 19th, 2009
Az Externet kiad egy PR hírt, néhány oldal leközli. És születik belőle olyan eszetlen mondat, mint:
Az Externet által nyújtott IPv6-os címtartomány gyakorlatilag kimeríthetetlen számú, 272 darab fix IP-címet jelent, így nem kell attól tartani, hogy valaha is elfogynak az új szabványú címek. (Érdekességképpen: mindössze 232 darab IPv4 cím létezik összesen!)
Az online lap meg hülye állatfajta, nem értelmezi a leírtakat, hanem egy az egyben leadja. Ha elolvasta volna akár egy laikus is, akkor feltűnt volna, hogy ha csak 232 db IPv4 cím létezne, akkor nem lenne Internet. Ahhoz képest pedig a 272 db IPv6 cím nem nagy előrelépés. Igen ám, de az Externet eredeti cikke szerint 272, illetve 232 db IP címről volt szó. Ez pedig a copy&paste&újraformázás háromságban elveszett. Ja, legalább két helyen is rosszul szerepelt a PR cikk.
BTW, kötekedésképpen: az IP címek számosságánál teljesen felesleges, hogy fix vagy dinamikusan kiosztott címről van szó. Lehet piros is meg sárga. Darab, darab.
És miért 72? Miért nem 128?
admin May 16th, 2009
Nem értem, hogy bírt ez elterjedni. Egy trágya és ezzel még dícsértem is. A timezone kezelése katasztrófális. Nem igazán értem magát az adattárolást sem, a JDBC driver írói pedig egy kicsivel a high school drop-out szint felett vannak (és ez már a saját bevallás szerint újraírt optimalizált változat). Létrehoznak egy Calendart, majd a visszaadandó Date típust ebből úgy állítják előt, hogy new Date(calendar.getTime().getTime()). Végülis, miért ne példányosítsunk minden egyes dátum olvasáskor és íráskor egy Date-t feleslegesen? És ez csak egy metódus volt. A goto-kat már nem is említem. Vagy a deklarált throws NullPointerExceptioneket. Ott már szinte sírtam. 1.5-ös JDK driver, de type safety nuku. Változónevek calendar1, calendar2, calendar3, calendar4. Beszédes. Ciklusváltozó: k1. new String() leírva. Így.
A timestamp with timezone adattípus JDBC konvertálása meg kritikán alúli. Hosszas keresgélés után sem találtam leírást arról, hogyan is működik ez CEST->CET átálláskor. Illetve annyit, hogy nem csak a TZR kell, hanem a TZD is ilyenkor. Mármint ha VARCHAR-t töltünk bele. Ezt értem. De ha java.util.Date kerül bele, akkor az miért nem jó (abban az Epoch óta van benne az idő, tehát minden tuti)? Illetve kiíráskor jó, olvasáskor nem. JDBC driver visszafejt. A következők derültek ki: byte[]-ben tárolja a GMT-be konvertált (persze nem a JDK TimeZone-ja alapján, hanem saját timezone adatok szerint) dátumot (akkor ha a oracle.jdbc.timestampTzInGmt true, ami defaultból igaz azt hiszem) és utána az offsetet. Ez OK, bár hatékonyabban is lehetne tárolni. Kiolvasás. Na, ez itt katasztrófa. Új Calendart hoz létre GMT TZ-vel, majd beletölti a GMT-be konvertált dátumot és hozzáadja a TZ offsetet, ebből csinál egy java.util.Date-t és azt visszaadja. Mindössze arról feledkeztek el a zseniális programozók, hogy CEST->CET, illetve hasonló átálláskor az így keletkező október 25 02:30 nem lesz egyértelmű, hogy CEST vagy CET és szopás van (szopunk is). Nem ám, hogy egy (TZ offsetnek) megfelelő Calendart hoznak létre és abba megy a dátum, majd getTime() és már jók is vagyunk. Lehet, hogy van oka annak, de ez így tuti nem jó. Hogy tesztelték ezt?
Úgy néz ki, hogy néhány timezone issue-t próbáltak így fixelni (11.1.0.7-es változat, tehát nem egy korai bétáról van szó!):
BUG-6749320
Timestamp values are incorrect around daylight savings time change
when the client time zone is different from the session time zone.BUG-6870832
Same as 6749320 above but for TIMESTAMP WITH LOCAL TIME ZONE.BUG-6977990
Wrong value TIMESTAMPLTZ when the retrieved timestamp is in the
DST overlap for the session timezone.BUG-7028625
Wrong value of TIMESTAMPTZ with the retrieved value is near the
DST changeover.
Gratulálok! A kód már teljes mértékben áttekinthetetlen, aluldokumentált és már teljesen elvesztettem a fonalat. Javadoc reménytelen: “The timezone information is stored as an offset in the RegionID format or in the HOUR/MINUTE format”. Mikor melyik? Azt már nem írják le. Beszédes metódusnevek. getDate, getDate2. Hogy melyik micsoda, az csak akkor derül ki, ha visszafejti az ember és látja, hogy melyiket mikor hívják meg.
Hétfőn megpróbálom a oracle.jdbc.timestampTzInGmt-t false-ra állítani és úgy tesztelni. Amennyire átlátható az átláthatatlan kód, úgy ebben az esetben a dátum visszaadásakor legalább erőfeszítést tesz a helyes TZ beállítására. Találtam Eclipse kódot. Na, abból kezdem megérteni az Oracle driver működését. A kód fele az Oracle driver dátumkezelésének workaroundja.