Výsledky ankety: mezi čtenáři vede klasika – XHTML, PHP a MySQL
Před deseti dny jsme vypsali anketu, v níž jsme se vás, čtenářů, ptali na oblíbené nástroje, postupy a techniky, které používáte při tvorbě webů. Odpovědí došlo přes 1700 – děkujeme. Pojďme se teď podívat na výsledky a probrat se některými zajímavostmi, které se v odpovědích ukázaly.
Nálepky:
Úvod – stručné objasnění situace
Když jsme zvažovali, jak anketu uspořádat, přemýšleli jsme především nad tím, jak hlasovací formulář zajistit. Jak zaručit, aby nikdo neodpovídal víckrát, aby někdo výsledky neovlivňoval, aby, aby, aby… Při zvažování, co vše budeme muset kontrolovat a jak budeme muset ochránit vstupní formulář a jak zajistit unikátní hlasování, se začalo zdát, že takovou anketu pravděpodobně snad nelze udělat bez toho, abychom vyžadovali kopie rodného listu a úředně potvrzené odpovědi… Především pak byly jasné dvě věci: Že nikdy neohlídáme vše, a že čím víc toho budeme hlídat, tím víc otrávíme čtenáře, co by rádi zahlasovali, ale všelijaké kontroly je jen otráví.
Nakonec jsme se rozhodli přistoupit k věci z přesně opačného směru. Protože vítězové ani hlasující nic nevyhráli, odpadl jeden z hlavních důvodů k falšování hlasů. Další důvod, tedy „změřit síly se zabezpečením“, padl tím, že jsme otevřeně oznámili, že žádné zabezpečení není a že spoléháme pouze na fair play. Byli jsme smířeni s tím, že pokud se objeví nějaký exces, tak výsledky zkrátka zahodíme a nanejvýš poděkujeme těm poctivým.
Poměrně riskantní hra nakonec vyšla. Během týdne se v anketě nashromáždilo 1723 odpovědí, a ačkoli jsme, po zkušenostech z komentářů a jiných anket, očekávali leccos, výsledek nás – nutno říci že příjemně – překvapil. Vše se totiž obešlo naprosto bez vulgarit, bez urážek či naštvaných vzkazů, odpovědi dávají smysl a nic nenapovídá tomu, že by jimi někdo záměrně manipuloval. Surová data v té podobě, v jaké jsme je získali, si můžete stáhnout přímo ze stránek Google Docs: HTML, CSV, XLS.
Je tedy na místě poděkovat všem hlasujícím za účast a za přístup. Vysoká účast nás těší a výsledky nás přesvědčují o tom, že naše práce má smysl. Pojďme si teď výsledky projít, ukázat si situaci a vypíchnout některé zajímavosti. Pokud bude situace příznivá, zopakujeme tuto anketu za rok, abychom viděli případné trendy a změny v preferencích.
Technologie: vítězí klasika
V oblasti použitých technologií se žádné překvapení neodehrálo. Mezi hlasujícími suverénně vítězí PHP, MySQL, XHTML. (Na tomto místě je důležité připomenout, že nejde o autoritativní průzkum situace v ČR, ale o hlasování našich čtenářů.)
Po PHP je druhým nejpoužívanějším jazykem Java a JavaScript (graf je zkreslen tím, že někteří hlasující napsali JavaScript do kolonky Další). S lehkým odstupem pak následují Python, C# a Ruby. Stále se poměrně vysoko drží Perl, zbývající jazyky měly zastoupení v jednotkách hlasů.
Mezi značkovacími jazyky pro vytváření prezentační části vede XML serializace HTML4, známější jako XHTML. HTML4 mělo proti XHTML poloviční zastoupení. HTML5 se na HTML4 dotahuje a k naší velké radosti suverénně překonal možnost „nevalidního HTML“. Mezi čtenáři získal Flash 110 hlasů, Silverlight 57, zbytek byly jednotky hlasů pro jazyky jako XUL či SVG.
Naši čtenáři nejčastěji vytváří webové aplikace a prezentační weby. Mobilní aplikace či webové hry tvořily jen zlomek odpovědí. V onom „longtailu“, skrytém v možnosti „Jiné“, se tentokrát objevil velký rozptyl možností, nejčastěji variací na slovo „intranet“, „eshop“ či „CMS“. Zazněly ale i Facebook aplikace, enterprise aplikace, komunitní weby, …
V databázích je stále suverénním vítězem databáze MySQL, následovaná PostgreSQL, MS SQL a Oraclem. V kategorii NoSQL databází jsou síly CouchDB a Mongo velmi vyrovnané – a kupodivu počtem příznivců převažují nad těmi, co používají SQLite (pokud se tedy SQLite neskrývá pod „jiná SQL“.
Frameworky: Nuda, nuda, šeď…
Tedy nikoli že by frameworky byly nudné, ale výsledky byly předvídatelné: V PHP vede u čtenářů Zdrojáku Nette, a nemalou zásluhu na tom má neutuchající evangelizační činnost jeho tvůrce. Druhý nejpoužívanější je Zend, s velkým odstupem pak Symfony, CodeIgniter, CakePHP… Ovšem mezi první Nette a druhý Zend se vklínila možnost „vlastní framework“ a počet lidí, kteří používají „vlastní framework“, je přesně mezi počty uživatelů Nette a ZF. Jako by se potvrzovalo rčení, že každý PHP programátor si vytvoří vlastní framework, a kdo říká že ne, ten ho píše dosud. Mezi dalšími možnostmi se nejčastěji objevoval framework Kohana.
U Pythonu či Ruby je situace podstatně jednodušší. Python rovná se (alespoň v naší anketě) Django. Ostatní frameworky jsou ryze marginální. U Ruby zase skoro „není frameworku kromě Rails“. Ale poměrně výrazné zastoupení má miniframework Sinatra (třetina počtu uživatelů Rails).
V JavaScriptovém světě vede jednoznačně jQuery. Druhý v pořadí, tandem Prototype/Scriptaculous, má pouhou desetinu hlasů oproti jQuery. Následují s mírnými odstupy MooTools, Dojo, YUI – a vlastní sady knihoven.
CSS frameworky moc populární nejsou. Kodéři volí většinou vlastní řešení či používají pouze části (v odpovědích jste uváděli např. „Reset z YUI, grid z 960, zbytek vlastní“. Nejpopulárnější byl jQuery UI CSS (zde jsme na pochybách, zda se jedná opravdu o jQuery UI CSS framework, nebo zda hlasy patří spíš jQuery „jako takovému“). Druhé místo získávají frameworky Blueprint a „vlastní“, na třetím je framework 960. Z možnosti „jiný“ jste nejčastěji jmenovali Hartija a Boilerplate.
Webové služby: vede Google a online repozitáře
Cloudy a online služby jsou jednoznačně tématem současnosti, i když ne nutně v ČR. Takže přes 200 hlasů pro Google App Engine je velmi příznivých a povzbudivých, i když se v celkovém počtu jedná „jen“ o nějakých 12 procent hlasujících. Na druhém místě mezi cloudy skončil Amazon AWS.
U otázky, zda používáte „cloudově hostované javascriptové knihovny“ (tedy nejrůznější CDN pro jQuery a další) jsme očekávali silnou nedůvěru vůči „čemukoli, co nemáme u nás“. Projevila se – téměř 550 uživatelů nepoužívá knihovny hostované v cloudech. Přes 430 hlasů zaznamenala možnost „Používáme Google AJAX API“ – zde je možná na pováženou, zda hlasy opravdu patří hostovaným knihovnám, nebo zda pod označením hlasující nerozuměli např. i Google Maps API a další JS API pro služby Googlu. Pro příště je to pro nás ponaučení: přesněji formulovat podobné možnosti, které mohou svádět k vícero výkladům. Ostatní metody hostování JS knihoven (Yahoo Front CDN, vlastní CDN, …) měly jednotky hlasů, možnost „různé CDN“ pak téměř 60.
Propagátoři Gitu odvádí v ČR dobrou práci. Svědčí o tom nejen druhé místo Gitu mezi verzovacími nástroji, ale i suverénní vítězství GitHubu mezi online repozitáři. Proti Google Code, druhému v pořadí, získal GitHub dvojnásobný počet hlasů. Poměrně slušnou pozici si stále udržuje Sourceforge. Úložiště jako Assembla či Bitbucket skončily až za možností „vlastní“.
V online pomůckách pro prototypování JS kódu získal vítěz, jsFiddle, 89 hlasů – obecně tedy nelze o nějakém masivnějším využívání podobných služeb ani mluvit. Na druhém místě se umístil nástroj Gist z GitHubu. „Ostatní“ nástroje zahrnovaly širokou škálu nejrůznějších webových služeb s jedním, dvěma hlasy pro každou.
Vývojářská práce: konzervativní přístup
Dvě povzbudivá zjištění z kapitoly „Verzovací nástroje“: Git dotahuje velmi výrazně (zatím) první SVN a zastaralý CVS je zjevně na ústupu.
Před samotným psaním si většina dělá klasické náčrtky na papíru. S téměř 1100 hlasy suverénně vedou před jinými (modernějšími) metodami, jako jsou mindmapy, wireframy či „počítačové modely“ – mockups. Dále se v odpovědích objevovala často možnost UML či „mám to v hlavě“.
V oblasti organizace práce, která s předchozí poměrně úzce souvisí, jsme se dočkali překvapení (nebo se žádné překvapení nekonalo, jak se to vezme): naprostá většina respondentů si práci nijak neorganizuje, jejich vlastními slovy „prostě sednou a pracujou“. Téměř stejně velká skupina si dělá poznámky, úkoly, připomínky do kalendářů apod. Metodiky organizace práce, a to jak soukromé (GTD), tak týmové (Agile), využívá jen 15–20 % hlasujících.
Stran používání testovacích nástrojů či obecně nějakých standardizovaných, formalizovaných, strojových či opakovatelných testovacích postupů zvítězil heuristický přístup „přeložím – zkusím – uvidím – opravím“ Sice poměrně těsně (s rozdílem stovky hlasů), ale zvítězil.
Pokud bychom z ankety měli vybrat oblast, kde je nejvýraznější rozdíl oproti současným doporučením, bylo by to právě zde. Podle výsledků ankety je stále valná většina čtenářů nucena pracovat sice „lety prověřenými“, ale neefektivními a zkostnatělými postupy. Návrh vznikne na papíru, pak si „prostě sednou a pracujou“, a to, co udělají, ověří metodou „kouknu a vidím“. Takto jistě lze weby psát, ale člověk se neubrání pocitu, že se přitom mrhá časem a výkonem vývojářů, že se znovupoužitelností takového kódu to nebude až tak horké a s efektivitou práce už vůbec ne. Ostatně nasvědčují tomu i odpovědi, co se v anketě vyskytovaly stran použití cizích knihoven – napíšeme si to všechno sami, máme vlastní knihovny, všechno si vyvíjíme… Jako by vlastní čas byl stále pro velkou část lidí zadarmo.
Licence: stále trochu nejasno
Mezi licencemi zvítězila možnost „vlastní / closed source“. Na druhém místě zůstala GPL, o třetí se dělí Creative Commons s opravdu volnými licencemi typu BSD. Nerozlišovali jsme mezi „nechci používat open source licence“ a „nemohu je použít, protože o licenci rozhoduje zaměstnavatel“.
Na tomto místě je potřeba připomenout, že překvapivě velké množství hlasujících neví, k čemu licence jsou. Odpovědi jako „Licence jsou na nic“ či „Prostě to dám na GitHub a licence neřeším“ svědčí o naprostém nepochopení účelu podobných licenčních ujednání. Proto znovu a opět připomínáme: pokud „jen někam nahrajete kód a licenci neřešíte“, tak pro váš kód, ať se vám to líbí nebo ne, platí autorský zákon, který zakazuje komukoli jinému jeho využití či úpravy. Váš kód tak nebude moci nikdo použít bez vašeho výslovného souhlasu. Vy se, coby autor, svých práv nemůžete vzdát. Pokud chcete, aby vaše kódy mohli ostatní používat, musíte k tomu dát svolení. A právě k tomu slouží otevřené licence: je to svolení, kterým dáváte ostatním právo použít, změnit apod. vaše dílo; svolení, které vyžaduje zákon. Bez tohoto svolení by ten, kdo by váš kód použil, porušil ustanovení zákona.
Ještě jednou: Pro váš kód vždy platí ustanovení autorského zákona, i když vás osobně nějaký zákon nezajímá. Pokud jste přesvědčeni, že dát kód někam na web znamená vzdát se svých práv k němu, mýlíte se, a výsledkem není to, co jste si přáli, tedy aby ho mohl použít kdokoli jakkoli, ale přesný opak – nesmí jej nikdo použít. Teprve licence dává dle zákona svolení k tomu, aby jej mohl kdokoli jakkoli použít. Tak prosím – pokud chcete, aby lidé vaši práci mohli použít, tak řešte licence.
Co se čte?
Mezi zahraničními magazíny vede Smashing Magazine, následovaný NetTuts+ a Ajaxianem. Kromě výběru se nejčastěji vyskytovaly dzone a The Server Side, ostatní měly počty hlasů v jednotkách. Z českých vede Lupa, Živě a osobní weblogy (a Zdroják, ten jsme do výběru nedávali, předpokládáme, že nás čtete, když hlasujete v naší anketě). Z dalších zdrojů pak Root, Weblogy, Vývojář.cz a ABC Linuxu. Zbývající zdroje měly opět jen jednotky hlasů.
Často se vyskytovala i možnost Twitter. Naopak skoro vůbec se nevyskytovaly nástroje pro sdílení odkazů typu Delicious či Reddit.
Závěrem
bychom ještě jednou chtěli poděkovat všem hlasujícím za jejich odpovědi a za jejich čas. Protože jsme tuto anketu vyhlásili poprvé, nelze z výsledků vyčíst nějaké trendy, ale jistě bude zajímavé po čase anketu zopakovat a porovnat výsledky.
Při porovnání výsledků s obdobnou anketou na serveru DailyJS je vidět, že výsledky jsou si poměrně podobné. Zajímavý rozdíl je třeba v preferovaných jazycích: Java, u nás druhá, skončila v jejich anketě na třetím místě, na druhém bylo Ruby – to u nás zůstalo až za Pythonem.
Zájemcům o konkrétní tipy doporučíme projít si výsledky a pročíst odpovědi. I my v redakci si z nich vezmeme tipy a náměty do dalšího roku a o některých zajímavých věcech budeme průběžně psát.
Z clanku bohuzel neni jasne, zda bylo mozne vybrat nejakou odpoved „Zadna“? Napr. v sekci CDN mi nesedi pouzivani Amazonu – tipnul bych si, ze vetsina ceskych vyvojaru nepouziva zadnou CDN?
Bylo, stačilo prostě neodpovědět.
To je dobrá připomínka, do článku doplním informaci o tom, kolik lidí neodpovědělo, protože to grafy nezohledňují… Díky
vyhra triady php, mysql a html se dala cekat. Ostatni technologie jsou totiz relativne malo rozsirene a pravdepoédobnost ze najdu na nejakem foru uspokoéjivou odpoved na muj problem se snizuje.. Navic to podporuje kazdy hosting ..
A je na nas to zmenit ;)
mě se zase stává, že tim jak se kolem PHP motá spousta neumětelů se na různejch fórech objevujou zcestný řešení zcestnejch problémů
Na problemy s kodem jsou stranky php.net. Na nekonzistentni chovani a bugy je tu lamparna a na problemy s frameworkem X strany je jednoducha rada, pokud nejsou hromady tutorialu nebo kvalitni dokumentace, tak se na to nesmi ani sahnout.
Mám trochu chaos v tom, co ještě nazývat Rootem a co už Zdrojákem. V závěru článku se odvoláváte na to, že každý hlasující patrně čte Zdroják, neboť hlasoval v anketě. Já ale čtu jen Roota a samozřejmě některé články ze Zdrojáku – ty, co se na Rootu objeví :)
Taky. Čtu Root, případně co ze Zdrojáku se objeví na Rootu. Takže sem nehlasoval.
U GITu by mě zajímalo, jestli na něj přecházejí lidé ze SVN/CSV nebo jestli se používá spíš na nové projekty. Subjektivně mi připadá, že pro uživatele starších systémů by měl být stravitelnější Mercurial (stejné příkazy, jednoduché rozhraní, bez složitějších funkcí). Navíc spousta lidí(78%) používá Eclipse, Netbeans a VisualStudio, kde podpora GITu není zrovna na nejlepší úrovni(nebo aspoň do nedávna nebyla). Pro mě je právě nejdůležitější integrace v dalších nástrojích a samotné rozhraní a pokročilejší funkce verzovacího systému, už pro mě nejsou moc důležité. Nejspíš to asi souvisí s organizací práce.
PS. Dost smutné je že víc něž polovina lidí netestuje :(
My přešli zhruba před rokem z SVN na GIT a nemůžem si ho vynachválit. Práce s větvema jde překvapivě snadno, každý vývojář si drží svoje větve, na kterých má rozpracované věci a pak master, ze kterého generujeme stable pro nasazení webové aplikace (prostý merge masteru do stable). Napsali jsme si několik malých scriptů, které umožnují mít sdílené větve a automatizují jejich sdílení a aktualizaci mezi vývojáři. Podpora IDE se nám zdá dostatečná, používáme převážne Intellij Ideu a ta to má zmáklé. Po roce už si nedovedeme přestavit práci bez GITu :)
PS: my testujeme, continuous integration server používáme Teamcity (také od Intellij), skvělá podpora jak GITu, tak i IDE, pro menší firmy stačí free verze.
V naší firmě jsme přešli před cca 4 roky (některé projekty později) z CVS.
Už proto, že valná většina programátorů dává přednost svobodě před menší prací. Ono být na něčem nebo na někom závislý může výjit samo dost draho. V knihovně je bug, firma, která ji vydala neexistuje, autor, který to napsal se věnuje něčemu jinému, nebo zmizel, nebo byl odsouzen pro vraždu prvního stupně.
Když k tomu přidám fakt, že knihovny jsou neodtestované, dokumentace neúplná, problémy, které s tím potřebuju řešit jsou řešeny jen z poloviny, častokrát to vlastní řešení vychází mnohem levnější.
„valná většina programátorů dává přednost svobodě před menší prací“ – máte nějaký důkaz pro toto tvrzení, nebo je to vaše přání a pozorování na příkladě vás a vašich kamarádů?
Vše, co píšete, jsou známé „dobré důvody proč nepoužívat cizí knihovny“ – zčásti uměle přifoulknuté, zčásti nesmyslné. Například: Proč si vybíráte neotestovanou, neúplně dokumentovanou knihovnu, co řeší váš problém jen z poloviny? Proč si nevyberete takovou, která vyhovuje líp a je slušně podporovaná? Není? Pak je na místě se zamyslet, proč ji dosud nikdo nepotřeboval.
Ale každopádně platí, že pokud vás netlačí čas, pak si můžete psát sami vlastní knihovny, zopakovat při jejich psaní všechny chyby, kterými si ty už existující prošly, napsat si vlastní dokumentaci, a až jednoho dne půjdete do důchodu nebo vás to přestane bavit, tak si vychovat nástupce, co se ve vašem kódu vyzná.
Mimochodem, víte že jste si tímto komentářem odpověděl velmi pěkně na své vlastní otázky proč někdo používá OpenID a ne vaše řešení, které považujete za technicky lepší? :)
V článku se píše:
„napíšeme si to všechno sami, máme vlastní knihovny, všechno si vyvíjíme… Jako by vlastní čas byl stále pro velkou část lidí zadarmo“
A moje reakce: Jde o to, že buď zaberu čas tím, že budu psát vlastní framework, nebo zaberu čas tím, že se budu učit cizí framework. Když už, tak si to radši napíšu sám a pak mám 100% jistotu, že je to čistě můj kód, který můžu libovolně prodávat, aniž bych musel řešit nějaké licenční podmínky. Navíc frameworky třetích stran bývají dost nafouklé, u svého vlastního mám jistotu, že umí pouze to, co potřebuji a neobsahuje zbytečné kilobajty kódu navíc.
Asi záleží na tom na čem pracujete. Já si naopak nedovedu představit, že si webový framework řeším sám. Nechci se trápit věcma jako je obsluha formulářů, parsování parametrů a podobné low-level problémy. Na spoustu věcí používáme wicket. Kilobajty kódu mě netrápí, efektivita práce je obrovská, hotové řešení nepřeprodáváme, s licencí není problém. Navíc vím že na něm pracuje komunita vývojářů a neustále jej zlepšují. Kdybychom si to lepili sami, půl času zabijem jen údržbou frameworku.
Nikoli. Jde o to, že když práci postavím na nějakém známém frameworku, tak:
– nemusím opakovat chyby, co za mne udělali (a pak vyřešili) už jiní
– snáze seženu lidi, kteří na věci budou pracovat, kdyby se projekt třeba nadmíru zvětšil
A – promiňte, ale „zbytečné kilobajty“? Píšete snad pro jednočipy? Opravdu je pro vás 100kB kódu dražší než třeba týden vlastního času? No, to máte hodně levnou hodinovou sazbu…
Sorry, ale psát si vlastní frmework je luxus, kterej si seriozní developer nemůže dovolit a nikdo mu to nezaplatí. Většina významných frameworků (i některý knihovny) má v sobě roky vývoje a představa „napíšu si něco lepšího“ je směšná. To je jako chtít si postavit vlastní auto.
Ja si zase myslim, ze programator, ktory nedokaze napisat vlastny funkcny framework, by sa nemal castovat pomenovanim seriozny developer.
Tak isto ako kuchar, ktory vam uvari nieco z polotovarov a k tomu spravi zemiakovu kasu z prasku podla mna nie je seriozny kuchar.
Nechcem sa nikoho dotknut, ale moj nazor je ze prave pri pisani vlastneho frameworku, programator lepsie spozna jazyk v ktorom pise. To hovorim z vlastnej skusenosti – pouzival som cakePHP, bol prilis pomaly na vacsie veci, ale velmi sa mi pacil sposob pisania a usporiadania kodu v aplikacii. Tak som si napisal vlastny framework(pisal som ho po veceroch doma, ked som mal cas), ktory ma taku istu strukturu, akurat jeho inicializacia(nacitanie jadra, inicializacia premennych, spojenie z DB, atd…) zaberie pod 0.002sec. Popri tom som sa o PHP naucil dost vela novych veci, na ktore by som neprisiel keby som framework nepisal. Tym som sa stal lepsim programatorom.
Mimochodom to neznamena ze nepouzivam dalsie frameworky, napr svoj vlastny JS som „zahodil“ a presiel na jquery….
>Ja si zase myslim, ze programator, ktory nedokaze napisat vlastny funkcny framework, by sa nemal castovat pomenovanim seriozny developer.
Je rozdíl v tom „umět napsat“ a „stavět na tom projekt“.
Seriózní vývojář jazyk umí a neučí se ho za pochodu při práci na projektu. U vývojářů v PHP je ale značně oblíbené, že když se dostanou na nějakou úroveň tak si „musí“ napsat svůj CMS/framework. Když je to baví, tak proč ne, ale na větší projekt bych na tom nestavěl.
„Seriózní vývojář jazyk umí a neučí se ho za pochodu při práci na projektu.“
:-)
>Seriózní vývojář jazyk umí a neučí se ho za pochodu při práci na projektu.
S tým súhlasím – určite by som nezobral zakázku v nejakom jazyku, ktorý neovládam s tým, že sa ho naučím počas písania aplikácie.
Ale ide o to že praxou sa človek zoceluje a nadobúda skúsenosti.
Napríklad – niekto vie postaviť búdu pre psa, niekto dom, niekto panelák a niekto stavia mrakodrapy. Keď chce človek dosiahnuť úroveň staviteľa mrakodrapov, musí najskôr byť dobrý v tých predchádzajúcich úrovniach. A keď bude stavať prvý mrakodrap, možno nebude taký dobrý a taký veľký ako napríklad desiaty.
Zakázku nejspíš na základě okolností. Ale faktem je, že na ničem jiném se nedá programovací jazyk naučit, než na ostré aplikaci. Představa, že se lze jazyk naučit ve škole je směšná a hraní si „tak tuhle věc teď vyzkouším“ vede k tomu, že se zkusí nějaká část jazyka, ale většinou bez kontextu. Jedině ostrý projekt skutečně naučí programátora, jak používat jazyk, jak slučovat jeho jednotlivé části dohromady….
S vlastní praxe vím, že nejlepší je, když se programátor učí nové jazyky/jejich nové části/zdokonaluje v tom, co trochu umím tak, že napíše ostrý (veřejný), ale soukromý (ne pro cizího klienta) projekt. Nebo pracuje společně s někým, kdo zkušenosti s jazykem má a za běhu ho učí.
To je dobrá připomínka. Ano, máte pravdu, člověk se při psaní vlastního frameworku naučí spoustu postupů a zdokonalí se v daném jazyce, ale jak píše tady kolega – je bláhové na tom pak postavit projekt.
Kdysi jsem na svém webu citoval esej Steve Yeggeho The Next Big Language: Ovšem za sebe bych chtěl povzbudit lidi, aby si udělali vlastní programovací jazyk, protože tím ze sebe udělají programátora světové úrovně. Opravdu. Ne jen „lepšího programátora“, ale „nejlepšího“. Jak jsem už řekl, a trvám si na tom: Velmi dobré porozumění kompilátorům je to, co odděluje zrno od plev. (…) Váš jazyk je odsouzen k neúspěchu s pravděpodobností 1 mínus epsilon. Když padáte z třicetipatrové budovy, tak můžete přežít, ale vyhlídky jsou prakticky nulové.
Je to přesně tak. Navrhnout si vlastní jazyk či vlastní framework je intelektuální výzva, která programátora naučí mnoho věcí. Ale pokud se z jazyka / frameworku nějakým zázrakem nestane obecně přijímaná platforma, nemá v reálném použití z mnoha důvodů co dělat…
1) Na tuto otázku nelze obecně odpovědět. Ano, cizí knihovna může být mizerná, může obsahovat chyby, nemusí mi vyhovovat… stejně tak ale můžu najít knihovnu, která mi vyhovovat bude a ušetří mi spoustu práce.
2) Podle mých zkušeností (a to jsem dělal v relativně velkých týmech/firmách) má málokterý tým kapacity/schopnosti k vytvoření (a udržování) skutečně kvalitní knihovny nebo frameworku. Většinou to pak dopadá takhle: žalostná dokumentace (nebo spíš nulová – „máme přeci kód, ne?“), sice je to naše a můžeme si to jakkoli ohnout, ale návrh se tvořil často ve spěchu, v rámci nějakého projektu, není tolik promyšlený, univerzální, flexibilní. A jedna z největších nevýhod, hlavně pokud jde o uzavřený software: jsme jediní uživatelé, jakékoli řešení problémů stojí firmu peníze (buď můj čas že se budu hrabat ve zdrojácích, nebo čas jiných kolegů, kteří to psali, které budu otravovat), nestačí zadat dotaz do Googlu (protože nikdo jiný ten software nepoužívá) nebo do veřejného fóra (kde by mi pomohli cizí lidi zadarmo – ale nepomůžou, protože ten software neznají/nepoužívají).
Shrnuto: vždy je potřeba zhodnotit kvalitu konkrétní knihovny, náklady na učení, spolehlivost a perspektivnost „dodavatele“, náklady na napsání vlastního kódu, požadavky… Jakýkoli obecný flame na tohle téma nemá smysl.
P.S. k tomu „nafouknutí kódu o zbytečné kilobajty“ – souhlas, psal jsem to např. tady: Spring JdbcTemplate? (Velikost frameworku), ale je to kus od kusu – vždycky si člověk musí spočítat, kolik mu to dává a kolik ho to stojí – to je individuální.
Java na druhem miste je prekvapeni.
Ne, ze by to davalo nejake statisticke informace o Jave v CR ale dava to velmi dobre statisticke informace o Jave na zdrojaku. Nezaslouzila by si Java vice clanku/pozornosti ? Myslim ze tim vic ziska Zdrojak nez komunita Javistu. (a pak take zamestnavatele protoze to zvysi pocet potencionalnich zamestnancu)
Z mnoha důvodů jsem přesvědčen, že se Javě na Zdrojáku dostává tolik pozornosti, kolik si na Zdrojáku zaslouží, a informaci čtu přesně opačně: Nebudeme krmit syté! Benefity, které získá Zdroják tím, že se bude věnovat Javě, jsou pro mne zčásti nezřetelné, zčásti až „malefity“. Naopak vím o mnoha pozitivech, které získá komunita Javistů, když bude číst Zdroják, na kterém nebudou články o Javě… :)
Napriklad by zdrojak ziskal citatelov a prijmy z reklamy, ale o to zdrojaku zrejme nejde.
Jsem javista a na zdrojak nechodim kvuli clankum o Jave. Webu a blogu o jave jsou hromady.
Řekl to kolega Jehovista zcela přesně, dokonce i statistiky návštěvnosti a zájmu inzerentů to potvrzují. Navíc se zkuste zamyslet: Co bychom asi vydávali o Javě, aby to Javisty zajímalo a nebylo to:
– pro jedny příliš amatérské a pro druhé příliš náročné
– popsané v knihách
– sepsané v programátorských weblozích
a o čem by si v takovém článku početli ostatní webaři? (Protože i kdyby Zdroják začali z ničeho nic číst hromadně ševci, tak zůstane orientovaný na web a webové technologie.)
Viem si predstavit ze by claky o webovych technologiach v jave boli:
a) prehladove.
b) o inovaciach, ktore vznikli prave v jave.
c) o moznostiach hostingu aplikacii pisanych v jave.
Ostatni by ziskali:
a) nahlad do javy
b) informacie o novych napadoch. Dobry napad je dost casto platformovo nezavisly.
Ale ok, uznavam, smerovanie zdrojaku je zrejme ine, zelam vam vela uspechov ;)
Budete se možná divit, ale souhlasím s vámi: určitě rádi vydáme články přehledové, o možnostech hostingu, o inovacích, aby čtenáři získali náhled a informace o nových nápadech. V tomhle je směřování Zdrojáku jasné a nijak se v názoru nelišíme. :)
autorstvi se sice nelze vzdat a je dobre, ze to v clanku zaznelo, ale pokud neni zalobce, tak neni soudce…
To je sice pravda, ale – opravdu se na to spolehnete, že „nebude žalobce“? Demonstrační situace: Píšete projekt a použijete nějakou „opuštěnou“ knihovnu, kde sice není explicitně dán souhlas s volným použitím, ale vy ji použijete v dobré víře, že „je to na webu, a kdyby to nechtěl autor dát volně k použití, tak to nedává na web, ne?“ Váš projekt se stane úspěšným, oblíbeným, vás čeká sláva a obdivné dopisy – a jednoho dne se to domákne autor, hne se v něm ješitnost a žalobce se objeví. Co budete dělat?
Chci tím říct, že to tak sice často bývá – „není žalobce…“ – ale pokud to chcete použít někde „vážně“, tak je spoléhání na to vyloženým hazardem. V takovém případě je na místě se autora minimálně zeptat – a jeho odpověď (byť i „dělejte si s tím co chcete“) lze už považovat za souhlas s užitím. Bez toho bych opravdu silně váhal, jestli něco „bezprizorného“ použít – může to „otrávit“ celé dílo.
+ bych dodal, že „není-li žalobce, není soudce“ znamená pouze a jenom to, že programátor/firma není popotahován(a), stále ale platí, že porušuje platné zákony.