Archiv pro měsíc October, 2007

Potřebujeme silné nástroje aneb vyvíjet kvalitní aplikace je stále stejně těžké

V tomto článku chci zachytit jenom několik myšlenek, které mě napadly při čtení článků od Potřebujeme silné nástroje. a Potřebujeme domyšlené nástroje a některých dalších komentářů.

Úvaha 1 – Mění se způsob práce, komplexnost zůstává

Dnes sice existují silné IDE, které začátečníka odstíní od elementárních úkonů, ale také je k dispozici více informací (článků, knih, kurzů, výuka ve škole) o daných tématech.

Myslím, že je situace uplně stejná jako před léty kdy sice člověk musel kompilovat zdrojáky javy z příkazové řádky, ale to byla jiná doba – méně informací, jiné nástroje jednoduše nebyly. Začátečníkovi je jedno jestli má IDE nebo příkazovou řádku – obojí je pro něj tako nové, nepochopitelné, že v prvních dnech nachápe aní jedno. Ortodoxní zastánce Assembleru může ohrnovat nos nad jazyky jakými je např. java, které jsou proti Assembleru „abstraktní“.

Když jsem před mnoha léty byl na setkání obchodních reprezentaců ČMSS mluvili spolu dva účastníci o tom, zda je bylo těžší schánět lidi, kteří by byli ochodní uzavřít smlouvu o stavebním spoření, před léty – když se stavební spoření v ČR rozjíždělo, nebo teď když už to všichni znají – odpověď byla zajímavá – je to pořád stejně těžké. Dřív byl větší trh (10 milionů potenciálních klientů) ale malá důvěra. Dnes je důvěra velká, ale trh se zmenšil na zlomek (mnoho lidí už stavební spoření má uzavřeno).

Myslím, že tento příklad snese srovnání i se světem programátorským – být dobrým programátorem (vyvíjet kvalitní aplikace) je pořád stejně těžké.

Úvaha 2 – Programujeme nebo lepíme?

V úvaze Programujeme nebo lepíme jsem se dočetl že:

Ale napadlo mě, že dneska už vlastně tolik neprogramujem, spíš skládáme (lepíme) dohromady existující kousky. Však se potichu šušká, že vše už bylo alespoň jednou napsáno.

A jaký je tedy závěr? I nadále programujeme, ale stále více se uchylujeme k lepení. A zda lepíme pomocí GUI klikátek nebo ne, to si musí každý rozhodnout sám, ale já jsem se rozhodl: „Raději ne, děkuji“.

Můj názor je ten, že je zatraceně jedno, jestli klikáte nebo programujete zdrojáky přímo. Používat by se měl ten způsob, který nás co nejrychleji pusune k cíli. Někdy je ten způsob naklikání a jindy ruční nakódování (zpravidla je to kombinace obou přístupů).

PS: Nejlepším lepidlem posledních let jsou anotace. Abychom se do toho lepidla, ale nezalepili sami.

Zalepit se lze od anotací i od XML konfigurace. Dobré je navrhovat architekturu aplikace tak, abychom toho lepidla potřebovali co nejméně – jednoduše nelepit jen proto, abysme ukázali, že umíme lepit.

Úvaha 3 – Stop pokročilým IDE pro začátečníky?

V jednom příspěvku na konferece (at) ja­va.cz jsem se dočetl:

Silna podpora v IDE? Ano, to je presne to, co NESMIE mat zaciatocnik, ktory potrebuje najskor pochopit, co presne musi implementovat, konfigurovat, ako to prelozit a ako to deploynut. Ked vsetko toto vie urobit rucne, moze pouzit vykonnu podporut v IDE aby robil veci rychlejsie a nezatazoval sa „reziou“ frameworku. Ak mu polovicu veci skryjete za IDE, tak ten framework nikdy nepochopi.

Tak s tímhle nesouhlasím. Pro začátečníka i pokročilého uživatele je důležité mít možnost si kostru aplikace naklikat. To jestli se začátečníka stane skutečný znalec dané technologie vůbec nezávisí na IDE, ale na člověku samotném.

Z vlastní praxe – PHP jsem se učil na jednoduchých „IDE“ – například Ultraedit. C# jsem se učil v plnotučném Visual Studiu, Javu jsem začal dělat v Eclipse. Naučil jsem se dobře všechny zmiňované jazyky – a IDE v tom nehrálo žádnou roli.

A ještě jeden příklad z praxe – na semináři o PHP byl představen framework Symfony – dva přednášející začali výklad přehledem možností spouštění frameworku z příkazové řádky, dál se vysvětlovala konfigurace v YAML souborech. To trvalo asi 45 minut – poté se někdo ze sálu zeptal jestli se při práci se Symfony ještě taky vůbec programuje v PHP. Další připomínka byla, že než se dostanu k psaní samotného kódu aplikace strávím několik dní vytvářením konfigurace.

Je krásně vidět, že tazatelé ani v jednom případě nepochopili výklad. YAML soubory nahrazují vlastní kód aplikace. Proč za každou cenu kódovat podobný kus kódu znovu a znovu? Symfony obsahuje defaultní konfiguraci a v té vygenerované jenom přepíšeme hodnoty, které chceme v našem projektu změnit (convention over configuration). Ve druhém případě tazatel nepochopil, že konfigurační soubory jsou vygenerovány automaticky – a je zcela jedno jestli je vygenerován automaticky YAML soubor nebo PHP třída. Co tím chci říct? Že i když se přednášející snažili předvést sílu frameworku na jednoduchých utilitách (příkazová řádka), tak to přesto nebylo částí obecentstva pochopeno. Věřím tomu, že kdyby existovalo IDE s podporou Symfony, tak by jeho skvělé schopnosti byly demonstrovatelné mnohém lépe – a o to pří seznamování s novým frameworkem jde.

Závěr

Myslím, že (stejně jako v ostatních aspektů života) nemusíme mít strach, že ke zlepšováním IDE nebude docházet. Pokrok a konkurence jsou úžasně zdravá věc.

Celý článek 5 komentářů 28. October 2007

PHP seminář podzim 2007 (a moje první přednáška) je za námi

Unikátní akce v českém PHP světě PHP seminář podzim 2007 (PHP workshop autumn 2007) je již minulostí. Václav Stoupa uspořádal k akci, na které bylo představeno několik PHP frameworků:

Jsem nadšen tím, že jsem mohl PHP komunitu seznámit se Zend Frameworkem. Moje přednáška trvala celkem 2,5 hodiny – trochu se protáhla z původně plánovaných 50 minut (resp. 1,5 hodiny po odpadnutí přednášky Michala Tilla).

Celé setkání trvalo od 9.00 do 19.00 a pokud mohu mluvit za sebe myslím, že se jedná přesně o typ akce, která je pro českou PHP komunitu hodně prospěšná.

Myslím, že by bylo dobré založit českou PHP user group – sdružení lidí, kteří budou sdílet svoje znalosti i PHP. Například ve světě Javy existuje od 12. září 2006 CZJUG (Česká komunita Java programátorů).

Činnost user groupy by spočívala v tom, že by jednou měsíčně uspořádala setkání, kde by proběhly dvě prezentace v trvání cca 2 hodin (dohromady).

Další možností je nahrávat PHP podcasty. Podcasty jsou zvukové záznamy s nahrávkou rozhovoru odborníků na dané téma. Opět si sáhnu pro příklad do českého javovského světa – CZ podcast volume #1 – Vývojová prostředí v Javě.

Materiály ke stažení k přednášce o Zend Frameworku

Závěr

Pokud by měl někdo jakékoliv dotazy k příkladu nebo k ZF samotnémá ať mě neváhá kontaktovat e-mailem nebo (ještě lépe) napsat svůj dotaz jako komentář k článku.

Celý článek 14 komentářů 28. October 2007

Programování řízené testy

Mám to potěšení napsat pár řádků o knize od Kenta Becka s názvem Programování řízení testy (v anglickém originálu Test Driven Development: By Example).

Každý programátor má své návyky, které aplikuje pří vývoji softwaru. Klasický přístup vypadá tak, že identifikujete systém a jeho use casy, naprogramujte část systému a pak vyzkoušíte zda se chová tak jak má.

Odlišný přístup se jmenuje programování řízené testy (test driven development). Pracovní postup je zde odlišný – před psaním samotnéhé kódu napíšete testy – sadu podmínek, které musí výsledná aplikace splňovat.

Pokud tímto způsobem ještě neprogramujete může být pro váš těžké si to představit v praxi. A právě k tomu je výborná kniha, o níž pojednává tento článek.

Obsah knihy

Kniha je rozdělena na tři velké části:

Část první – Příklad s penězi

V této části, která tvoří polovinu celé knihy, autor prochází od samého začátku příkladu s finančními operacimi ve více měnách. Na začátku práce je virtuální list papíru, na který si píšeme požadavky na výsledný program. Poté se započne s napsáním testu na tu nejjednodušší funkčnost. Slyšíte správně – nepíšou se žádné třídy – rovnou testy, ve kterých se s klidem odvoláváme na neexistující třídy a metody.

Následuje spuštění testu – test samozřejmě neprojde. Dalším krokem je sprovoznění testů – s nejmenším možným odporem. Pokud tedy máme mít metodu na sčítání dvou čísel a test vypadá takto:

public void testFoo() {
     this.assertEquals(3, myClass.foo(1, 2);
}

Tak nejjednodušší implementace metody foo pro projití testem bude vypadat:

public void foo(int a, int b) {
     return 3;
}

Možná si řeknete, že je tento postup hloupý, ale jedním z pravidel TDD je psát pouze kód, který projde testy. Nic navíc. Když přidáte další testy bude samozřejmě potřeba metodu foo upravit. Vývoj pomocí TDD má následující cykly:

  1. Napsání nového testu a jeho spuštění
  2. Úprava kódu programu tak, aby nový test prošel (a s ním samozřejmě všechny předcházející)
  3. Refaktorizace kódu (např. kvůli odstranění duplicit)

V první části je v použit programovací jazyk Java.

Část druhá – Příklad s xUnit

xUnit je název pro testovaný rámec, který se v příkladu vytváří. Tentokrát je použit jazyk Python. Obsah kapitoly je podobné té první – opět návrh programu from scratch pomocí TDD.

Část třetí – Vzory pro vývoj řízený testy

V této části autor mluví o návrhových vzorech, refaktorizaci, testovacích vzorech atd.

Na závěr krátký citát z knihy:

Jednou z velkých frustrací mého života mladého inženýra bylo zahájit projekt s obrovským nadšením a pak sledovat, jak se kód během doby hatí. O rok později jsem si už nepřál nic jiného, jen ten teď už smradlavý kód zahodit a dostat nový projekt. TDD vám umožní získat během času důvěru ve váš kód, Jak se testy hromadí (a vaše testování zlepšuje), získáváte důvěru v chování systému. Jak vylepšujete návrh, můžete dělat stále více a více změn. Mým cílem je, abych se po roce cítil ohledně projektu lépe, než když jsem nadšeně začal s růžovými brýlemi na nose.

Závěr

Věřím, že hodně z vás už tuto knihu četlo – často bývá zmiňována jako základní publikace z této oblasti. Útlá knížečka je psaná čtivým (a srozumitelným) jazykem. Je to čtení na pár večerů.

Informace o knize
Název
Test Driven Development: By Example
Autoři
Kent Beck
Vydal
Addison-Wesley Proffesional
ISBN
0321146530
Datum vydání
2003
Počet stran
204

Celý článek 7 komentářů 11. October 2007

Zajímavé linky 11 - Spring IDE, Ruby vs PHP, DynaTrace Diagnostics

Architektura DynaTrace Diagnostics

Celý článek Přidat komentář 11. October 2007

Používání proměnných v Zend_Config

V našich PHP projektech s úspěchem používáme Zend Framework a také jeho část Zend_Config.

Zend_Config je třída umožňující přístup k konfiguračním souborům. Do něj je vhodné ukládat si například nastavení databáze apod. V současnosti existují dvě implementaci (adaptéry):

Zend_Config_ini
Slouží pro práci s konfiguračními daty, která jsou uložena a php ini souboru.
Zend_Config_Xml
Slouží pro práci s konfiguračními daty, která jsou uložena XML souboru.

Současná implementace Zend_Config neumožňuje používat proměnné v konfiguračních souborech. Na příkladu vysvětlím o čem je řeč:

[default]
foo = bar
foo2 = #foo#
var = World
foo3 = "Hello #var#"

Výše uvedený kód je ukázkou ini souboru, ktery lze načíst pomocí Zend_Config_Ini třídy. Použítí jenásledující

$config = new Zend_Config_Ini('config.ini', 'default');
$el = new Venturia_Config_ElEvaluator($config);

echo $config->foo; // vypíše bar
echo $config->foo2; // vypíše #foo#
echo $el->evaluate($config->foo2); // vypíše bar
echo $config->foo3; // vypíše Hello #var#
echo $el->evaluate($config->foo3); // vypíše Hello World

Třídy Venturia_Config_E­lEvaluator tedy funguje tak, že projde daný string a zamění výskyty znaku #nazev_promenne# za její skutečnou hodnotu (dělá to rekurzivně).

K napsání této třídy mě vedla skutečnost, že se hodnoty různých proměnných opakovaly. Typicky to byla hodnota e-mailové adresy.

Závěr

Doufám, že tato triviální třída může někomu pomoci s lepším uspořádám jeho konfiguračních souborů. Dříve než jsem se do jejího psaní pustil pátral jsem po webu, ale nic podobného jsem nenašel…no možná mě vyvedete z omylu.

Zde je odkaz na stažení třídy a testů – Venturia_Config_E­lEvaluator + testy.

Celý článek 1 komentář 9. October 2007

O zaměstnancích a kontraktorech

Už delší dobu se chystám napsat tento článek a po přečtení článku A zase freelancerem jsem se konečně rozhoupal.

V následujících řádcích bych chtěl zhodnotit výhody a nevýhody kontraktora a zaměstnance.

Kontraktor

Jako kontraktor pracuji už více než šest let. Zde jsou moje poznatky.

Výhody
  • V naprosté většině případů máte mnohem volnější časový fond než zaměstnanec
  • Není problém si z práce (po dohodě) odskočit něco vyřídit. Nemáte to sice zaplaceno, ale není to problém
  • Jste placeni fixní hodinovou sazbou a tak nevznikají dohady zda vám zaměstnavatel např. neproplatí přesčasy z důvodu vaší údajné neschopnosti (měli jste to stihnout v pracovní době)
  • Víte, že se s vámi firma může velmi rychle rozloučit, když nebude s vašimi službami spokojena (tohle bych zařadil jednoznačně do výhod). Už jsem slyšel o případech kdy není možné neschopného zaměstnance vyhodit protože jednoduše výrazně neporušil pracovní kázeň a svoje povinnosti nějak zvládá.
  • Tím, že na sobě musíte sami pracovat, se učíte samostatně uvažovat.
  • Možnost pracovat z domova.
Nevýhody
  • Nikam nepatříte (být zaměstnancem úspěšné firmy – cítit se její součástí – může být velmi povznášející.
  • Nemáte žádnou dovolenou.
  • Menší jistota toho že budete mít stále práce.
  • Musíte na sobě pořád makat – co se sami nenaučíte to neznáte. Tím, že denně nesdílíte svoje zkušenosti s ostatními žijete v částečné izolaci.
  • Možnost poznat fungování více firem a odnést si z toho zkušenosti.

Zaměstnanec

I se životem zaměstnaců mám svoje zkušenosti. Část z firem, pro které jsem dělal (dělám) a zčásti od kamarádů programátorů.

Výhody
  • Jak už jsem napsal výše – pocit že někam patříte, že jste součástí špičkové firmy k oboru je k nezaplacení.
  • Máte dovolenou a další výhody (bonusy, různé firemní spořící programy).
  • Pokud jste součástí skvělého kolektivu dává vám to úžasné možnosti osobního růstu (mluvím o nabytých znalostech).
  • Možnosti profesního růstu v rámci firmy.
Nevýhody
  • Často nízká motivace zaměstnanců (setkal jsem se s tím, že je v praxi úplně jedno, jestli zaměstnanec pracuje 2 nebo 8 hodin denně (ano, mluvím o programátorovi) – nikdo ho nekontroluje).
  • Pokud nejste součástí prograsivního kolektivu (dynamické firmy) znamená to pro vás profesní hrob – ustrnete na současných znalostech.

Už jsem se setkal s několika nadanými programátory, které nedostatek motivace dovedl k tomu, že tráví velkou část dne bezcílným bloumáním po internetu a tu zbývající řečmi o „gamesách“.

V současnosti se pohlížím po nové práci a moje zkušenost je taková, že naprostá většina firem chce mít svoje zaměstnance místo lidí na kontrakt. Má to svoje důvody – proč investovat (čas, peníze, školení) do někoho, kdo nezůstane ve firmě delší dobu.

Závěr

Můj názor je, že jedinec nemůže nikdy v oblasti IT ničeho významného dosáhnout. Ideální je podle mého názoru být zaměstnancem v dynamickém kolektivu, který se nebojí zavádění nových věcí a tvrdé práce. Že to zní jako klišé – máte pravdu:) A nebo je tu vlastně ještě jedno řešení – otevřít si vlastní firmu, najmout zaměstnance a dělat to podle svých představ.

Celý článek 7 komentářů 8. October 2007

Kalendář

October 2007
M T W T F S S
« Sep   Nov »
1234567
891011121314
15161718192021
22232425262728
293031  

Články podle měsíců

Kategorie

Locations of visitors to this page