Sw Engineering

Střípky z prototypování II: WebSockets

V úvodním díle jsme se dívali na jednoduchý prototyp - jak spojit dvě etablované webové technologie: Wicket a Spring. Bylo to takové zahřívací kolo, ještě o nic nešlo. Spíše o to, připravit si prototypovací platformu, než vyřešit zapeklitý technický problém. V dnešním díle se podíváme na prototyp, jehož negativním výsledkem mohla být výměna GUI technologie, což by vedlo k refaktoringu cca 13 aplikace. Kontextπάντα χωρεῖ καὶ οὐδὲν μένει ~ ἩράκλειτοςJak říká Hérakleitos z Efesu: “

Střípky z prototypování: Wicket, Spring, REST

Měl jsem to štěstí, že jsem se teď mohl několik týdnů věnovat prototypování. Štěstí, protože je to jeden z mých nejoblíbenějších aspektů softwarového inženýrství. Všechny prototypy vedly k cílovému, zbrusu novému řešení. V kontextu naší firmy, by to normálně dělalo oddělení R&D, ale z kapacitních a projektových důvodů to skončilo v našem delivery týmu. Rád jsem se toho ujal. Vzhledem k tomu, že by popis řešení a implementace zabraly mnoho článků, rozhodl jsem se vytáhnout jen několik zajímavějších fragmentů z následujících témat (a i ty rozdělím do dvou-tří zápisů):

Šest ctností softwarového inženýra

Čteme teď s dětmi výbornou knížku Buddhovy pohádky na dobrou noc. Kromě pohádek samotných je v úvodu knihy několik krátkých kapitol o tom, co je to Buddhismus, kdo byl Buddha apod. Tam mi padla do oka kapitola Šest ctností (pāramitā) a okamžitě mi začaly naskakovat paralely ze softwarového inženýrství. 1. DánaTouha dávat každému, aniž bych očekával odměnu.Moje subjektivní zkušenost bloggera je, že máte jen minimální zpětnou vazbu na své psaní a když už nějaká je, tak je neobjektivní - pokud nepíšete úplné blbosti, tak vás (zlomek) lidí buď pochválí, sem tam nějaký ten troll, nebo spam a občas vás někdo upozorní na chyby a nesrovnalosti.

Programátor -> Vývojář -> Software Engineer

Source: WikipediaJak léta jdou, přemýšlím kontinuálně o cestě, kterou jsem urazil a kam směřuju. Jeden takový pohled na část takové cesty naznačuje titulek. Dneska už jsem na té cestě dál - jsem v bodě, kdy už pár let “stavím” týmy. A byť nehledám lidi, kteří jsou mým odrazem - naopak, mám rád diverzitu a plánovaně, podvratně :-) ji aplikuju - podvědomě vybírám lidi, kteří na podobnou cestu aspirují a berou ji jako součást týmové kultury.

Software Engineering, má rozumné paralely?

Konstantou Software Engineeringu (SE) je jeho dynamika. Snad právě proto hledáme paralely a podobenství v jiných oblastech lidské činnosti - abychom lépe porozuměli jeho zákonitostem, uchopili jeho abstraktní nehmotnost a někdy ;-)  i jen našli pevnou půdu pod nohoma. Nejčastějšími doménami, kam se sahá pro inspiraci a popis jsou: “klasická” architektura a stavebnictví (stavíme sofware), strojní výroba (vyrábíme software) a automobilový průmysl (procesní a automatizovaná výroba od designu po prodej). Tyto paralely jsou hodnotné, protože umožňují průmět, projekci něčeho obecně známého do něčeho, o čem někdy tušíme pouze fuzzy obrysy.

Mercurial, strategie branch-by-feature

Mercurial je skvělý, distribuovaný Version Control System (VCS, či DVCS), který nabízí velkou míru volnosti, jak s nakládat s verzováním zdrojových kódů. Svobodu většinou chápeme jako pozitivní věc, někdy je ale přílišná nespoutanost na škodu. A tak definování nějaké verzovací strategie prospěje týmu i projektu. Proč mít verzovací strategii?Verzovací strategii branch-by-feature jsme s úspěchem použili na stávajícím projektu. Důvody, proč jsme si něco takového definovali byly dva:Když jsem se mihnul na předcházejícím projektu (taky Mercurial), žádná strategie, či konvence definovaná nebyla .

Kanban, zprávy z fronty II

Máme za sebou, s týmem, další, úspěšnou implementaci Kanbanu. Projekt pomalu končí, je čas se ohlédnout. Jak to vypadalo, co fungovalo, co je potřeba zlepšit? O projektuVzhledem k tomu, že z bezpečnostního hlediska se jedná o citlivé téma, nebudu psát nic o architektuře a technologiích. Což ale nevadí, protože z pohledu Kanbanu je obsah a typ projektu nepodstatný. Ale ať nám to povídání nevisí ve vzduchu, nastíním business case. Výsledkem projektu je/bude webová aplikace, s jejíž pomocí si zájemci mohou online zažádat o různé typy víz a povolení (pracovní, k pobytu apod.

Code review checklist

Nedávno jsem v práci prezentoval, jaké přínosné věci používáme na aktuálním projektu. Vyzkoušeli jsme si spoustu zajímavých nástrojů a praktik a v podstatě to byla taková laboratoř, kdy ty funkční záležitosti použijeme na dalším projektu. Mind mapa níže shrnuje přehled prezentovaných témat. Jedním z nejcennějších realizovaných konceptů pro mne je, že se nám podařilo naimplementovat funkční a efektivní code review. (Doufám, že kolega Banter o tom brzy napíše článek.) A co čert nechtěl, po zmiňované prezentaci se nejvíc diskutovalo právě code review.

Kanban, lehký úvod

Rok se sešel s rokem (skoro), takže je nejvyšší čas, říct si zase něco o Kanbanu :-)  Přiznám se, v těch minulých článcích jsem to trochu flákal, moc se mi nechtělo do popisu, co to vlastně Kanban je. Tak to napravím. Co je to Kanban?Když mám definovat Kanban jednou větou, obvykle říkám: Kanban je metoda-nástroj na zefektivnění procesu. Kdybych měl přidat druhou: Kanban lze aplikovat na libovolný proces - je jedno, jestli jde o Scrum, nebo vodopád.

Joel test, má ještě smysl?

Jste vývojáři? Pak už jste se možná někde setkali s Joelovým testem. Možná jste to zaslechli někde na internetu, možná se vás na to ptali na pohovoru (nebo vy jich) a možná jste to dokonce sami ve firmě zaváděli. Joelův test je skvělý. Když jsem na něj cca před osmi lety narazil, bylo to pro mne jako zjevení. Měl jsem tehdy tři, čtyři roky zkušeností s PHP a začal jsem pronikat do enterprise Javy.