Portál AbcLinuxu, 1. května 2025 16:22
Za programátora se nepovažuji, nicméně čas od času něco pro sebe či pro jiné napíšu. Ať již pro zábavu a nebo protože to potřebuji k vyřešení aktuálního problému.
Programovat jsem začal v roce 1987 a postupně jsem (nepočítaje krátkodobé slepé uličky) používal Atari Basic, Assembler 6502, Pascal (ve škole), Assembler Motorola 680x0, C a Perl. Pokukoval jsem po C++, ale nakonec jsem se k němu nedostal...
Prozatím jsem si s C a Perlem vystačil, ale už dlouho se ukazovalo, že by to chtělo ještě "něco". Programovací jazyk, který by nebyl čistě interpetovaný, jehož "výstupy" by přitom byly multiplatformní, daly by se v něm bez větších problémů dělat GUI aplikace a člověk by se nemusel pohybovat příliš nízko a starat se třeba o uvolňování paměti. A kdyby v něm šel sem tam napsat i nějaký web, bylo by to úplně skvělé. Prostě jsem asi zlenivěl.
Rozhodování nakonec nebylo příliš těžké, protože obecnou povědomost o dostupných a vhodných programovacích jazycích mám a pár podobných rozhodnutí už jsem v historii udělal. Před lety jsem takto poslal k šípku například Python (u něhož jsem nebyl ochoten akceptovat odsazování místo "vlaštovek") nebo PHP (panejo, to je ale příšerná zpatlanina).
Definitivně to ve mně uzrálo na přelomu roků 2007/2008. Vybral jsem si Javu a začal jsem. V případě Perlu se mi před lety osvědčilo napřed si komplet přečíst učebnici základů jazyka a teprve potom začít psát svůj kód. A to rovnou nějaký "užitečný", žádné "helloworldy". Sem tam samozřejmě kouknout do knížky, do dokumentace, do google. Stejně tak jsem postupoval i u Javy. Napřed jsem si přečetl knihu Miroslava Viriuse, ale než jsem opravdu začal psát, dostala se mi do rukou kniha Pavla Herouta, tak jsem přečetl i tu. První poznatek - Herout je lepší než Virius, ale na Satrapu nemá . (Kniha Miroslava Viriuse byla alespoň lepší v tom, že v ní byly základy GUI, Pavel Herout má o Java GUI samostatnou knihu.)
První nápad, na kterém jsem se také začal Javu učit, byl vizualizátor mapy pro hru Divoké kmeny, kterou jsem v té době trošku hrál. Ačkoliv dnes už hře nemůžu přijít na jméno (spíše kvůli hráčům než hře samotné) a prakticky ji nehraji, ve vývoji projektu DK Mapa však pro velký zájem zatím stále pomalu pokračuji. (Mimochodem, je to poprvé, co jsem napsal program pro "širší masy" a jsem za to i náležitě potrestán. Tolik stupidních dotazů v mailboxu jsem snad ještě neměl...)
Ovšem teď k tomu samotnému programování. Jsem nadšen! Jistě, nic není zcela dokonalé, výtky by se našly, některá temná zákoutí stále úplně nechápu, ale stále se učím a musím říci, že takhle dobře se mi už dlouho v žádném jazyce nepsalo. Tenhle výběr jazyka byl zatraceně dobrý! To je tedy to nebe...
Poté, co jsem dostatečně ovládl Javu, jsem se asi před měsícem vrhnul na JSP (Java Server Pages). Tentokrát jsem to chtěl vyřešit jen nějakým tutoriálem na webu, ale nic použitelného jsem nenašel. Už to mě mohlo varovat. Vyřešil jsem to nakonec opět knihou, tentokrát byl autorem Barry Burd. Základy byly jasné, kniha ukázala, že v případě JSP se jedná o velice silný nástroj a že bude radost v něm psát. Rozhodl jsem se tedy, že z Perlu do JSP přepíšu jeden svůj neveřejný webový projekt. Začal jsem a začalo peklo...
Začalo to tím, že rozjetý Tomcat nebyl ochoten použít ani nejjednodušší aplikaci. Nepomohla dokumentace, nepomohl google, nakonec jsem náhodou zjistil, že existuje nějaký Security Manager, který vše blokuje a přišel jsem i na to, jak ho vypnout. Jak nakonfigurovat, to ovšem ne...
Na další potíže jsem narazil, když jsem potřeboval vypsat nějaké ladicí informace uvitř použitých objektů. Kniha tvrdila, že pokud použiji System.out, výstup uvidím. Neříkala kde, nezdálo se mi to a dle očekávání jsem také hov<CTRL+H>uby viděl. K logování jsem nic nevygoogloval. Nejřív jsem zkoušel z příslušného objektu otvírat soubor a zapisovat do něj. To nefungovalo, ale nevím proč, protože jsem si prostě nemohl nic nikam vypsat (Hlava XXII). Zkoušel jsem předávat do příslušného objektu objekt PrintWriter, což sice fungovalo, ale kromě toho, že to bylo hrubě neelegantní to neřešilo případ, když šlo o objekt JavaBeans (tedy s konstruktorem bez parametrů) a já potřeboval ladit konstruktor. Nakonec jsem vygoogloval, že musím použít nějaký Java Logging Framework (proboha, proč to není nikde jasně napsáno). Našel jsem log4j, zkusil použít a prozatím skončil na hlášce "log4j:WARN Please initialize the log4j system properly", ovšem v logu! Sláva, přeci jen to asi bude logovat, ale napřed se musí log4j nakonfigurovat, což asi taky bude stát za to....
A mé stížnosti nekončí. Když ve zdrojáku objektu (.java) udělám nějakou drobnou změnu a znovu jej překompiluji, Tomcat má stále někde nacacheovaný ten starý. Dle google nezbývá, než prostě kontejner restartovat. To musím vážně kvůli změně jednoho písmenka restartovat celý kontejner (tedy webserver)? Vždyť to je na hlavu padlé...
No a zatím poslední nadávka. Pokud je v kódu chyba zobrazí se v prohlížeči výpis výjimky. Pokud stránku obnovím (se SHIFTem!), rázem se objeví stránka bez chyby, ovšem nějaká předchozí (někde - ne v browseru - nacacheovaná verze), ta je tam ještě několik následujících reloadů a zhruba při pátém se zase objeví chybový výpis. A tak stále dokola...
Fajn, je to pro mě nové, neumím to, chyba je dost možná ve mně. Ale děsí mne, kolik je tu drobných "ale", o kterých se nikde nepíše. Mám pocit, že o JSP se nepíše vůbec. Pokud mám problém přímo v Javě, stačí většinou jediný dotaz do google a dostanu relevantní odpověď nebo alespoň tip, kudy pátrat dál. Pokud jde o problém v souvislosti s JSP, můžu googlovat do aleluja, relevantního nenajdu skoro nic...
Je to peklo. Doufám tedy, že jen zatím...
Tiskni
Sdílej:
co se nemusí kompilovat
No to klidně, ale musí to mít min. kontrolu syntaxe, když už nic jako kompilaci, která obhalí i další chyby.
skvěle vystavěný hororový román na pokračování.No ty si delas srandu, ale ono to tak fakt v nekterych mistech je
Spolehnout se na nějaké to reloadování modifikovaných částí aplikace prostě nešlo.Tomcat pouzivam na vyvoj porad a s timhle jsem nikdy problem nemel. Pokud je nakonfigurovan na reload kontextu pri zmene na classpathu, vzdycky se chytne. Ze se mu po case preplni prostor pro tridy, ktere neschramstne GC (PermGen space), to uz je jina... ale tusim, ze i na to je nejaky hack (myslim jeste jiny, nez pouzit Jetty
Kniha tvrdila, že pokud použiji System.out, výstup uvidím. Neříkala kde, nezdálo se mi to a dle očekávání jsem také houby viděl.Stacilo by tu aplikaci psat treba v Eclipse. Vystup byste videl v konzoli. Od toho ty IDE jsou, abyste nemusel travit cas resenim blbosti
Sláva, přeci jen to asi bude logovat, ale napřed se musí log4j nakonfigurovat, což asi taky bude stát za to....Zas tak strasne to neni
Když ve zdrojáku objektu (.java) udělám nějakou drobnou změnu a znovu jej překompiluji, Tomcat má stále někde nacacheovaný ten starý. Dle google nezbývá, než prostě kontejner restartovat. To musím vážně kvůli změně jednoho písmenka restartovat celý kontejner (tedy webserver)? Vždyť to je na hlavu padlé...Staci redeploy daneho kontextu. Restart serveru AFAIK neni nutny. Zkuste nejake vyvojove prostredi, ktere automaticky po ulozeni *.java tridu zkompiluje a nastavte si ho tak, at ji kompiluje to WEB-INF/classes a Tomcat tak, aby reloadoval kontext. Nebo pouzijte Eclipse a nemusite tohle vubec resit.
Pokud je v kódu chyba zobrazí se v prohlížeči výpis výjimky. Pokud stránku obnovím (se SHIFTem!), rázem se objeví stránka bez chyby, ovšem nějaká předchozí (někde - ne v browseru - nacacheovaná verze), ta je tam ještě několik následujících reloadů a zhruba při pátém se zase objeví chybový výpis. A tak stále dokola...Jo, jo, to dela. Nekde mu tam asi jeste visi ta stara classa bez chyby...
Pokud je pro tebe JSP a Tomcat peklo, tak by me zajimalo, co zacnes rikat na JSF, JTA, EJB3 ci RMI.Co by měl říkat. Začne používat technologie, které umožňují to samé bez té ohromné spousty nepoužitelného balastu (hint: Spring a Wicket).
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.