Jak jsem se nabodl na nabodeníčka (diskuse)

[Grunt]

Proč se tvůj počítač jmenuje kofola?

[freshmouse]

Protože pořád pracuje, pracuje a pracuje.

[Grunt]

Tak to vůbec nechápu.

[Luboš Doležel (Doli)]

kofola = cikán (aspoň tak to chápu já)

[Grunt]

Bubu, bílí medvědi…už jsem slyšel tedy všelijaké codenames, ale kofole teda ještě ne.

[Käyttäjä 11133]

Bylo to v nějakém filmu a nebylo to jako kofola = cigán, ale jako kofola = černoch. (Český film)

[Luboš Doležel (Doli)]

Horem pádem

[freshmouse]

O nějakém politicky nekorektním dlouhém večeru ti to někdo možná vysvětlí.

[deyia]

Já myslela, že "když ho miluješ, není co řešit"

[freshmouse]

Zase tak ho nemiluju.

[Algi]

To není nic zvláštního, že Java neumí pracovat pořádně s adresáři. Například v práci musíme mít projekt, který je založený na NetBeans RCP v adresáři, jenž neobsahuje mezery. No a protože ještě nemáme Visty (s jejich adresářem /Users převzatým z Macu ), tak nemůžu mít projekty u sebe v domovském adresáři. Abych byl upřímný, tak oni celé NetBeans jsou šáhnuté. Buildování více projektů pomocí Mavenu v NetBeans, to je fakt chuťovka. Btw, enjoy JBoss. Je to supr server, ale Tomcat startuje rychlej

[freshmouse]

Maven? Neznám, ale někdy po tom mrknu. My používáme Apache Ant. (Není dokonce Maven nějaká jeho odvozenina?)

Btw, enjoy JBoss. Je to supr server, ale Tomcat startuje rychlej

JBoss má Tomcat vestavěný, takže by měl startovat ještě rychleji.

[Algi]

Maven je skvělá věc. Hlavně na správu závislostí jak mezi projekty, tak mezi 3rd party knihovnami. Docela hojně používané řešení. Nejedná se o odvozeninu Antu, spíš o jeho náhradu. Zatím co v Antu píšeš jak se má co dělat (voláš javac, apod.), tak v Mavenu akorát popisuješ, co je k tomu potřeba. O zbytek se postará Maven sám. Rozhodně doporučuji nastudovat. Ovšem ne v kombinaci s NetBeans. To bys pak mohl Maven začít nenávidět

JBoss má Tomcat vestavěný, takže by měl startovat ještě rychleji.

Tyhle ty vtipný poznámky Ale co, já mám rád oba dva servery. Každý se hodí na něco jiného. JBoss je spíš na produkční nasazení ve spojení se Steam, nebo EJB 3. Tomcat je pro lehčí řešení typu Spring.

[freshmouse]

Maven je skvělá věc. Hlavně na správu závislostí jak mezi projekty, tak mezi 3rd party knihovnami. Docela hojně používané řešení. Nejedná se o odvozeninu Antu, spíš o jeho náhradu. Zatím co v Antu píšeš jak se má co dělat (voláš javac, apod.), tak v Mavenu akorát popisuješ, co je k tomu potřeba. O zbytek se postará Maven sám. Rozhodně doporučuji nastudovat. Ovšem ne v kombinaci s NetBeans. To bys pak mohl Maven začít nenávidět

Mno, ono to je celkem jedno. Vesměs potřebuju pořád to samé (zkompilovat, zabalit a nahrát na server, případně zkonfigurovat), a na to stačí pár řádků kódu. A navíc se dá jeden sestavovací skript používat opakovaně (pokud si proměnné dáš do nějakého *.properties a měníš je podle potřeby tam). Ale stejně na to mrknu, může to být zajímavé.

A jinak používám Eclipse.

[Ladicek]

O zbytek se postará Maven sám. Rozhodně doporučuji nastudovat.

Měl jsem tu čest a zodpovědně prohlašuji na plnou hubu: Maven je teplej (nic proti gayům). Závislosti vyřeší Ivy, a ty šílené problémy s chybějící dokumentací, podivně se chovajícími pluginy a impotencí ve chvíli, kdy bych chtěl třeba generovat kód nějakým skriptem, za to fakt nestojí. A tuhle jsem narazil na nějaký nástroj v Groovy, který by měl být "Maven done right", ale teď to nemůžu najít; rozhodně to vypadalo dobře.

JBoss je spíš na produkční nasazení ve spojení se Steam, nebo EJB 3. Tomcat je pro lehčí řešení typu Spring.

Asi jde o Seam… Jo, a podle mého ohavného antiJEE názoru je cokoliv těžšího než Tomcat zbytečný kanón na vrabce, a Spring dokáže JEE ve všech ohledech plně zastoupit (jakkoliv se Rod Johnson snaží tvrdit, že jde o technologie, které se navzájem doplňují; zrovna tohle mu ani trochu nežeru ). I když chápu, že občas si prostě člověk nemůže vybírat.

[podlesh]

Měl jsem tu čest a zodpovědně prohlašuji na plnou hubu: Maven je teplej (nic proti gayům). Závislosti vyřeší Ivy, a ty šílené problémy s chybějící dokumentací, podivně se chovajícími pluginy a impotencí ve chvíli, kdy bych chtěl třeba generovat kód nějakým skriptem, za to fakt nestojí.

Problém je v tom, že ant je totéž v bledě modrém - jakmile v něm chci něco udělat, musím si napsat task v Javě. Pokud chci použí standardní tasky, musím se hrabat ve zdrojácích abych viděl co to vůbec bude nebo nebude dělat. Takže mi nějak uniká výhoda antu...

A tuhle jsem narazil na nějaký nástroj v Groovy, který by měl být "Maven done right", ale teď to nemůžu najít; rozhodně to vypadalo dobře.

Jo, něco takového by to chtělo... Maven 1 s jeho Jelly se mi docela líbil - dal se v něm opravdu psát script.

A nebo starý dobrý Makefile

[Ladicek]

Pravda, dokumentace k antím taskům taky stojí za starou belu. Teda přinejmenším co do rozdílů mezi dokumentovaným a skutečným chováním, které jsou někdy, řekněme, propastné. Ale jednu výhodu bych viděl: Ant je imperativní, čili mnohem přímočařejší.

Jinak psaní skriptů v Jelly, hmm, to fakt není Jim Beam

[Algi]

Asi jde o Seam…

Bože, já jsem trubka Steam je přece v HalfLife

[Daniel Kvasnička ml.]

No alespon je videt, co v ty praci vlastne delas!

[Daniel Kvasnička ml.]

Jo, na Ivy jsem taky nedavno narazil a je fakt, ze mi to pripadlo celkem jako svezi vanek do oblasti dep. managementu...

A v nazoru na "cokoliv těžšího než Tomcat" bychom se asi shodli I kdyz zas nemam tak dalekosahle znalosti treba o EJB, abych se odvazil prohlasit, ze to neni potreba a ze se to da vzdy za neco vymenit.

[Ladicek]

Tak jsem to našel (díky Googlu za skvělé vyhledávání v Readeru!), Gradle. Kdybych měl teď řešit build systém nějakého nového projektu, určitě bych se na to podíval do detailů, protože to na první pohled vypadá moc dobře.

Jinak k tomu Springu, včera jsem to řekl trochu blbě (taky po pěti pivech ), nemyslím, že Spring dokáže nahradit JEE, ale že Spring s Tomcatem a dalšími samostatnými projekty dokáže nahradit normální JEE aplikáč. Mám rád věci pod kontrolou, což mi Spring perfektně umožňuje. A JMS nebo JTA do něj dostanu taky

[Filip Jirsák]

O zbytek se postará Maven sám. Rozhodně doporučuji nastudovat. Ovšem ne v kombinaci s NetBeans. To bys pak mohl Maven začít nenávidět

Obávám se, že problém je spíš v tom Mavenu, protože úplně stejné problémy se projevují i v případě, kdy Maven spouštíte z příkazové řádky. A to „postará se sám“ je trochu nadsazené (a myslím, že hlavní zdroj všech problémů) – postaral by se sám, kdyby všechno na světě bylo ideální a všechno bylo v Mavenu. Jenomže ne všechny projekty a knihovny třetích stran používají přesně ty konvence, které vyžaduje Maven, a s tím je pak problém.

[Algi]

Ano, máš pravdu. Řekl jsem to trochu zjednodušeně. Nicméně, většina projektů je v hlavní repository. Pro ty projekty, které nejsou (nebo nemohou být - viz Oracle), tu existuje Artifactory. To zařídí zbytek. Poté máte vlastní repository a zbytek týmu se nemusí o nic starat. Vše je vyřešeno centrálně.

Problémy s NetBeans + Maven jsou bohužel jiného rázu. NetBeans původně používaly (a stále používají) Ant. Maven je tam dost násilným způsobem naroubován, což poté působí nemalé komplikace při kompilaci programu. Dost častým jevem je neustále používání clean install. Bohužel hovořím z vlastní zkušenosti Btw. situace může být jiná u obyčejných projektů, jenže my používáme to slavné NetBeans RCP, což je tragédie. Kdo nepoužíval, nepochopí. Zkuste si někdy spojit NetBeans RCP se Springem a uvidíte, že horory od Alfréda Hitchcocka jsou vlastně trapné pohádky pro děti

[Filip Jirsák]

Až budete ve firmě, mrkněte se třeba na firemní konferenci k NB a pochopíte, že se vším, co píšete, mám zkušeností víc než dost A zrovna integrace Mavenu s NB je ta nejméně problémová část (pokud tedy pominu, že k Mavenu prakticky neexistuje JavaDoc, takže se proti němu dost blbě něco píše).

[Algi]

Aha. No, já na mailing listu NB nejsem. Už takhle mi stačí cocoa-dev a java-dev na @apple.com na to abych měl furt co číst. Já se naštěstí v tomto procesu moc neangažuju, takže nesleduji dění okolo NetBeans. Ale jak tak na to koukám, tak jsem si docela solidně naběhnul. Já jenom sděluji mé povrchní pocity o používání NB a Mavenu. Možná, že jsem trochu zaujatý proti NB (používám raději Eclipse), ale i tak mi připadá, že NetBeansy mají před sebou ještě dlouhou cestu k tomu, aby byly opravdu "only IDE you need".

[Algi]

Hm, tak teď už chápu, co jsi tím chtěl naznačit - http://wiki.netbeans.org/NetBeansPlatformWithSpring. Zeptám se kluků v práci, jestli o tom ví. Já tomu sám moc nerozumím, ale třeba jim to pomůže...

[Daniel Kvasnička ml.]

Není dokonce Maven nějaká jeho odvozenina?

Spis "inspirovanina" Pokud vim, tak z Antu nevychazi. Spis se obcas Ant targety volaji pri mavenovskem buildu... Nebo obracene.

Me osobne zatim Ant staci, ale u projektu, ktery ma nejaky vetsi pocet zavislosti (knihoven) a dela na nem vic lidi, bych Maven nasadil (v praci ho pouzivame). Mj. je to fajn v tom, ze knihovny se nemusi commitovat do nejakeho VCS, ale commitne se jen pom.xml a ten pri updatu/checkoutu zaridi potrebny ekosystem knihoven z mavenich repozitaru. Ale i vic zajimavosti to ma...

[Algi]

Ale i vic zajimavosti to ma...

Jako například integraci s Continuum?

[Daniel Kvasnička ml.]

Tak s tim jeste zkusenosti nemam

[Algi]

Juj, kontinuální buildování a testování je základem pro každý team. Rozhodně doporučuji. Princip je v tom, že je to server, který provádí (například) každou hodinu build, pokud byla změna v SVN (nebo CVS, apod.). V první fázi si vytáhne všechny zdrojáky zadaných projektů, ty poté přeloží a spustí na nich testy. Pokud něco neklapne, rozešle mail všem vývojářům (jsou uvedení v POM souborech Mavenu). Díky tomu máš jistotu, že každý tvůj commit půjde zkompilovat a nenaruší nikterak funkčnost programu. Continuum je velmi jednoduché nakonfigurovat a při správném použití je to velmi mocný nástroj.

[Daniel Kvasnička ml.]

Tak to nejspis pouzivame. Jde jen o to, ze ja nejsem ten, kdo by to nastavoval a spravoval

[petr_p]

Je možné z Mavenu vytáhnout seznam závislostí? Kdysi jsem potřeboval něco ubalit pro Gentoo a ono to pořád stahovalo a stahovalo knihovny, tak jsem se na to vybodnul. Prostě balíčkovací sytém navíc nepotřebuji.

[Daniel Kvasnička ml.]

No zavislosti pro konkretni projekt se pisi do XML souboru, takze dobre napsanym XSL stylem z toho vytahnete cokoliv do jakekoliv podoby... Tzn. jestli vas dobre chapu, napisete si XSL styl, ktery transformuje data o zavislostech daneho projektu do nejakeho formatu, ve kterem se zavislosti ukladaji v ebuildu...?

Ono to neduplikuje balickovaci system. Jde o to, ze je to naprosto platformne nezavisle a umi vam to postavit potrebne prostredi pro beh/build at ten Maven na tom spustite na windows nebo linuxu...

[podlesh]

Je možné z Mavenu vytáhnout seznam závislostí? Kdysi jsem potřeboval něco ubalit pro Gentoo a ono to pořád stahovalo a stahovalo knihovny, tak jsem se na to vybodnul. Prostě balíčkovací sytém navíc nepotřebuji.

Tam je drobný háček: ty knihovny které to stahovalo v Gentoo pravděpodobně nejsou a nebudou. Ledaže by někdo udělal nějaký frontend, který by je generoval automaticky... hmm... to by možná nebyl zcela marný nápad.

[Algi]

Srovnávat Maven s balíčkovacím systémem je dost zvláštní nápad a svědčí o neznalosti problému. Neber to prosím osobně, jenom ti chci říct, že to jsou docela dvě odlišné věci. Maven je v první řadě buildovací systém. Není určen k tomu, aby řešil instalaci programu. To řešíš ty, například pomocí balíčkovacího systému, atp.

[petr_p]

Konkrétně jsem se pokoušel o dev-java/microemulator (JME VM napsaný v JSE ;) Takže kdyby se někdo hodně nudil… Jen doplňuji, že Gentoo v současnosti podporuje automatizovanou instalaci jen přes Ant. Samozřejmostí je „kompilace“ v sandoboxu a vydefinování a poskytnutí všech závislostí přes systém ebuildů.

[petr]

Já mám NetBeans v adresáři /Applications/NetBeans/NetBeans 6.1.app/ a nějak nemám problém :-/ A abych řekl pravdu, tak s mezerami mám problém vždy opravdu jen na Windows V tomhle mě třeba strašně s*rou startovací skripty (dávky) Antu -- jak je jednou Java v Program Files\ s mezerou namísto PROGRA~1\, tak to prostě nejde a nejede. A což o to. To by nevadilo. Ale problém je, že jak se napíše ten zkrácený název, tak už nefunguje v konzoli doplňování x-( Windows prostě nejsou pro mě

[Algi]

Tak si schválně zkus spustit JBoss v adresáři s diakritikou a s mezerami. Nicméně, to bych spíš viděl na chybu JBossu, protože normálně s nimi Applovská Java nemá problémy.

Svůj stroj v práci jsem však stejně přizpůsobil k lepšímu. Aplikace na kterých mi záleží jsou v C:/Applications, vývojářské nástroje v /Developers. Documents and settings jsem schoval, namísto toho je tam zástupce Users. Akorát to některé javovské programy nepobírají a složky, které jsou pouze zástupce nezobrazují...

[alblaho]

Nabodeníčka neé. Píšu všechno anglicky (a lowercase), takže ten adresář bych nazval "tools".

Ono ta nabodeníčka skoro všude fungují. Ale prostě všude kolem jsou stupidní windoze, co na nějaké utf8 kašlou (naprosto miluju, když mi někdo pošle ZIP a v něm soubory s windowsí diakritikou).

Na druhou stranu, mám rád češtinu a z textu "bez hacku a carek" je mi na blití. Takže píšu všechno anglicky a místo mezer mám _underscore: vypadá to rozumně a mám 100% jistotu, že nenarazím na problémy.

[Ladicek]

_underscore

Jo, jo. Už ani ta nostalgie není co bývala

[frEon]

tak neco podobneho jsem zazil s Lispworks pod windows (v linuxu jsem je celkem bez problemu rozbehnul, ale casto padaly a sekaly se, tak jsem rezignoval a nainstalil sem pro ne windows do virtualboxu), ty neumi otevrit/ulozit soubor ulozeny v ceste s diakritikou.

[Ladicek]

No když jsem viděl tu cestu, tak mi bylo úplně jasno, kde by mohl být zašitý pěkný průser. A byl tam Nicméně souhlasím s tím, že takovéhle problémy by prostě nastávat neměly, máme sakra třetí tisíciletí.

[Bluebear]

Nicméně souhlasím s tím, že takovéhle problémy by prostě nastávat neměly, máme sakra třetí tisíciletí.

Je pravda, že počítačové systémy by už dávno měly počítat s tím, že v názvech souborů se mohou vyskytnout i jiné znaky než anglická abeceda.

Na druhé straně lze argumentovat tím, že všechna ta nabodeníčka a národní abecedy jsou nesmyslný přežitek, který všechno komplikuje - a to nejen v oblasti počítačů, ale všeobecně. Máme desetitisíce znaků (většina lidí umí přečíst jen malou část z nich), přestože základní anglická znaková sada by pro komunikaci úplně stačila. A aby to nebylo tak jednoduché, jeden a tentýž znak nebo sekvenci znaků si mohou různí lidé interpretovat různě podle toho, jakou řečí mluví.

Jednou jsem si na tohle pěkně naběhl, když jsem psal něco v Javě - některé vstupní řetězce, které se (z mého pohledu) skládaly ze samých cizích značek, považoval javovský runtime za čísla, ale jiné ne; následně se to chovalo dost prapodivně a mně trvalo dost dlouho, než mi došlo, že znaky, kterých se to týká, představují číslice v různých neevropských jazycích.

Ještě hezčí to je, když se do toho zamíchá ještě nastavení locale. Při návrhu jedné aplikace typu klient-server se mi server rozhodl, že bude posílat datum psané česky, protože je přece v ČR. Jaký brajgl to udělalo v klientu, asi nemusím říkat.

Řekl bych tedy, že tohle není problém ani tak počítačů, jako náš - kdybychom měli trochu rozumu, sjednotili bychom aspoň to písmo, když už nejsme schopni se dohodnout na jednotném jazyce.

[kavol]

dovolil bych si nesouhlasit - různé příklady nám dokazují, že i přes větší "provozní komplikace" jsou heterogenní systémy z dlouhodobého hlediska výhodnější než homogenní ... nevidím důvod domnívat se, že u jazyků je tomu jinak, zvláště jestliže jazyk do značné míry formuje myšlení

[Bluebear]

jestliže jazyk do značné míry formuje myšlení

To je pravda, ale lidí, kteří myslí, je stejně tak málo, že se to určitě ani nestačí projevit

[Ondrej 'SanTiago' Zajicek]

Ještě hezčí to je, když se do toho zamíchá ještě nastavení locale. Při návrhu jedné aplikace typu klient-server se mi server rozhodl, že bude posílat datum psané česky, protože je přece v ČR. Jaký brajgl to udělalo v klientu, asi nemusím říkat.

Vtipnne take je, ze printf %f s ceskym locale pise desetinnou carku. To pak clovek obcas narazi na chyby v generovanych textovych souborech (XML a jine) z GUI programu.

[petr_p]

A ještě vtipnější je, že když chcete oddělovač tisíců, musíte si to explicintě vyžádat (%'f).

Jinak vámi zmíněnou chybou trpí gnuplot. Autor sice vyprodukoval patch, ale protože to je podle něj ošklivý hack, tak není součástí oficiálních vydání. Zde (gnuplot-*-numeric_locale.diff) jej udržuji, aby fungoval na poslední vydání.

[CEST]

Me zase fascinuje, jak je mozny, ze doma ti to v tom adresari "Nástroje" funguje.

Nicmene, fakt by me zajimal duvod. Pouziva Java (JBoss) jiny kodovani nez (file-)system? Nebo proste neocekava UTF-8 znaky?

[Algi]

Chyba bude spíše v JBossu. Zkoušel jsem to spustit u sebe v adresáři /Users/marian/Destkop/Šíleně žluťoučký kůň úpěl ďábelské ódy/jboss/bin a také to nešlo. Používám Javu od Applu, která (alespoň dle mého názoru) obsahuje méně chyb, než ta od Sunu. Spíše to vypadá, že se v JBossu dějí divné věci

[freshmouse]

Me zase fascinuje, jak je mozny, ze doma ti to v tom adresari "Nástroje" funguje.

Doma jsem to zkoušel v cestě bez diakritiky, tzn. ne v ~/Nástroje.