Docela nedávno jsem si uvědomil jednu zajímavou věc. Když se začíná nový projekt nebo přede mnou stojí nějaký netriviální programátorský úkol, často se mi stane, že se přistihnu jak jen tak nečinně sedím a lámu si hlavu nad tím, jak já to jenom vyřeším. Nakonec to samozřejmě všechno dobře dopadne. Nicméně proces, který vede k úspěšnému konci, stojí za popis.
Nedávno jsem měl s Rikim zajímavou debatu o manažerech. Jsou to důležití lidé. Vidíme se s nimai každý den a mají podstatný vliv na náš každodenní pracovní život. Podle nějaké manažerské teorie existují dva typy manažerů. Hands-on manažer je ten, který je s týmem pořád a na problémy reaguje hned jak nastanou. Zato hands-off manažer je ten, který nechává tým být a jednou za čas se nechá uvést do obrazu. Takový člověk má potom docela zkreslený pohled na projekt, ale zase zdravější nervy. Podle mě existuje ještě jeden typ manažera, kterého v žádné manažerské příručce nenajdete.
Pokud v Rails testujete fakt důkladně, tak stejně jako já občas narazíte na záludnosti, které není jenom tak jednoduché vyřešit. Testování chybobých stavů je dobrý příklad a vede ke spoustě zajímavých závěrů.
Nechápu jak je možné, že ve stavu absolutního myšlenkového vyčerpání jsem schopen ještě něco tady psát. Asi setrvačnost. V poslední době jsem si osvojil jednu praktiku známou hlavně na open-source projektech a rád bych se o ni podělil.
Test Driven přístup diktující psát první testy a pak kód je sice skvělý, ale zatím se mi této mety nepodařilo dosáhnout na sto procent. Nicméně se tomu snažím maximálně přibližovat. Dnes ale chci psát o něčem jiném. Stará dobrá programnátorská mýlka říká, že z toho že máme testy vyplývá, že naše aplikace funguje dobře. Vedle jak ta jedle, testy testují jenom to co se po nich chce a vždy (ano vždy) se najde škvírka, kterou testy nepokryly a objeví se chyba.
Murphyho zákon o bezchybném programu:Postup, který jsem na začátku slíbil je jednoduchý. Nejlepší dokumentací chyby je test, který chybu odhalí. Najdu-li v kódu chybu, první co dělám je, že píšu test, při kterém se chyba projevuje. V dalším kroku se chyba odstraní a je po problému.
Celé se to dá rozepsat ještě dále:
Bod 3 je velmi zajímavý okamžik procesu. Někomu by se mohlo zdát zlé, že build spadl, ale je to naopak velmi dobré. Od toho máme kontinuální buildy, abychom byli upozorněni když se objeví chyba.
Tedy nejsem příznivcem kopírování došlých mailů na blogy, ale jednou ža čas je třeba udělat vyjímku. Takže tady to máte:
Jistá žena v balónu ztratila orientaci. Spustí se níže a na zemi zahlédne chlapa. Spustí se ještě níže a volá na něj: “Promiňte, nemohl byste mi prosím pomoci? Slíbila jsem příteli, že se před hodinou setkáme a teď nevím, kde jsem.”
Phishing, Identity theft a další nové kybernetické zločiny jsou v poslední době hitem internetu. Když se na nějakém webu objeví díry typu SQL Injection a XSS tak je to odborníkům spíše k smíchu, protože moderní vývojářské technologie proti těmto praktikám bojují samy od sebe a v drtivé většině jenom neznalost základních faktů a hloupost umožňují, že se neustále objevují.
Je to pár dní co mi několik nezávislých zdrojů přes RSS čtečku sdělilo, že Ruby 1.9.0 je na světě. Jelikož tento release nese označení development release nechával mě úplně klidným, protože to znamená, že pro proukci je nepoužitelný a na testování nových fíčur nějak nemám energii. Čláky jsem nicméně pročetl a nové Ruby se změnami, o kterých se píše už měsíce, jsem ignoroval. V podstatě pro mě tento release nemá žádný význam.
Odborná fóra jsou skvělá věc. Osobně mám radši pozici odpovídajícího než tazatele, a proto se taky ptám až v mometě kdy jsem přesvědčen, že na problém jsem krátký a prostě s tím nepohnu. Velmi jsem si oblíbil čeksé rails fórum. Otázky ostatních uživatelů jsou často vítaným impulzem k rozšiřování znalostí o rozličných zákoutích Ruby on Rails. Najdou se ovšem i off-topic dotazy. Jeden takový dotaz, zastrčený ve špatném tématu a totálně off-topic, mě inspiroval k napsání tohoto článku.
Pokud vám toto uniklo, tak důrazně doporučuji obětovat tři čtvrtě hodiny a předášku si poslechnout. Je to podobné kvality jako většina věcí vycházející z dílny ThoughtWorks a Martina Fowlera.
O agilní metodiky se zajímám už nějakou tu dobu, ale tato přednáška mě hodně nadchla i pro opomíjené praktiky jako pair-programming a test first, code after. Celkové statistické zhodnocení vlivu Ruby a Agile na průběh projektu sice nelze brát na 100% (je to pořád jenom statistika), ale závěr je nevyvratitelný. Agilní metodiky v kombinaci s dynamickými jazyky jsou dobré nejenom pro vývojáře (práce je zábavnější), ale i pro manažery a byznys jako takový (projekty jsou úspěšnější a výdělečnější).
Dostal se ke mě popis servisního požadavku zadaného klientem dodavateli, který mě přivedl k hlubšímu zamyšlení. Obě strany pro jistotu zachovám v anonymitě, jejich identita pro tento článek beztak postrádá významu.
Zmíněný požadavek měl zhruba následující znění (pokusím se převést na jiný, ale podobný příklad):
Prosim o zmenu typu u 2 poli v nasi databazi:
1) tabulka Automobily – pole Otacky motoru – zmenit z typu Integer na String (zachovat jiz zadane hodnoty)
2) tabulka Motory – pole Otacky – zmenit z typu Integer na String (zachovat jiz zadane hodnoty)
Dále je potřeba upřesnit, že ke každému Automobilu je v databázi přiřazeno více motorů (mapř. různé výbavy) a Otáčky jsou u Automobilu i přiřazených motorů vždy stejné.
Centi mi doporučil k přečtení článek dxg o frameworku Ruby on Rais a jeho nevýhodách a hrozbách. Tímto bych si dovolil s ním krapet polemizovat.
pokračování na AcidLogu