Projekt GripTV

S Filemonem a bratry Semlbauerovic rozjíždíme web GripTV.cz .Web pro fanoušky motorsportu v jehož hledáčku jsou také disciplíny a šampionáty „mainstreamovými“ médii opomíjené (drifty, menší okruhové šampionáty, motokros a free MX, plochá dráha a další).

Atraktivní jsme tím, že informace o dění v dané disciplíně či šampionátu zprostředkují pečlivě vybraní členové našeho Grip Teamu. Hvězdnou sestavu si můžete prohlédnout zde – griptv.cz/team

Kdo je v týmu?

  • Lukáš Pešek,vítěz závodů v mistrovství světa silničních motocyklů MotoGP
  • Michal Indi Dokoupil– největší hvězda českého roadracingu (vítěz 300 zatáček, účastník Isle of Man Tourist Trophy v Irsku)
  • Matěj Kůs – špička české plochý dráhy (speedway), účastník závodů SGP.com
  • a další … 

Členové GripTeamu vám zprostředkují také záběry ze všech možných úhlů pomocí našich GoPro kamer, které po geniálním Patrickově střihu mohou vypadat třeba takhle:

Grip Trip Czech Drift from GripTV on Vimeo.

nebo takhle, kde na videu jedu i já 😉

Tak nám s GripTV držte palce a pokud mi chcete udělat radost, šiřte jméno GripTV dál! 😉

Deployment Tracking Tool

Let me ask you a question. Are you using any kind of a software tool to track deployments of builds, configuration changes (both SW and HW), software updates in your corporate environment?

If so, then can you give some recommendations? If not, would you be interested to use such tool?

Some use cases I foresee:
  • you have multiple HW machines available for your project
  • you release builds every couple weeks or months, builds are from multiple branches (some are planned to be deployed to Production system soon, some are planned only for QA system, for example)
  • in case of Production-level build, the build must follow path Dev -> QA -> Staging -> Production
  • for every build, you need to keep associated files: deployment checklist, release notes, build file etc.
  • every change in the environment should be audited (author, timestamp, etc.)
  • when moving build from environment to environment (QA to staging), it should be possible to easily reuse some of the artifacts (check list, release notes, but possible to change them)
  • this tool should hold all artifacts (documents), links (bug tracker, source code repository, link to build, etc.) 
  • this tool should allow easy collaboration
  • this tool could allow easy creation (editor) of deployment checklists, based on history etc.
  • I could found more and more…

From my experience, there are many projects that require some tool like this. Some projects are using excels stored locally in user machines, some are smarter and are using for example google doc spreadsheet for easy collaboration.

Thanks

Nevyhazujte testery!

Po precteni clanku Vyhodte testery od Jirky Hradila mi to nedalo, abych se neoHradil 😉 a nezastal testeru.

Myslenku clanku zcela jiste chapu a souhlasim, ze na ni neco je. Problem je, ze kazde tvrzeni ( obzvlaste tvrzeni kontroverzni) by melo byt zasazeno do kontextu.

Ihned se mi vybavilo, co rozebiral Joel Spolsky v postu Five Worlds. Ve zkratce – ja i ty delame sofwarovy vyvoj. Jenze tento pojem je hrozne siroky a zahrnuje nekolik svetu. A kazdy svet funguje jinak a jsou v nem jina pravidla. A ma sve vlastni problemy. Zakazniky. Ekonomiku. Proste svoje specifika.

Je jednoduche rici „zruste QA“, testovat bude zakaznik.

Ale, zde zalezi:

Priklad 1: Pokud jste webova aplikace, prikladem treba, Facebook nebo Good Data, testovat muze Vas „crowd“. Pokud release rolloutujete novy release treba 5% uzivatelu, muzete je pouzit k otestovani nove feature. Kdyz fungovat nebude, udelate rollback. Pokud to ovsem. Par uzivatelu nastvete, ale reputaci muzete dohnat rychlou reakci na jejich feedback a napravou.

Ale i tak, pokud to myslite vazne, je pro Vas vase reputace natolik dulezita, ze QA team si budete hyckat. Takze sef QA by podle me mel mit unikatni pozici ve firme, na stejne urovni jako sef vyvoje.

Priklad 2: Pokud vyvijite webovou aplikaci jako treba my – JetMinds a Vendavo – ktera rekneme spada do kategorie „enterprise“ aplikaci (slovo pouzito bez jakehokoliv citoveho zabarveni – chapu ze pro nekoho to slovo ma negativni nadech, ale ja tim oznacuju software, ktery meni fungovani firem, velkych firem, stovek a tisicu jejich uzivatelu, ktery vyzaduje ‚change management‘, tedy software/projekt, ktery neco stoji(>1M+ USD) a je zde oduvodneny predpoklad, ze se v dohledne dobe investice vrati, nedokazu si predstavit vynechani QA teamu ze hry.

Napr. jeden Vendavo modul se pouziva pro zavedeni procesu pro globalni stanoveni cen produktu, jejich optimalizaci, pravidel kterymi se pak budou ridit ceny v ramci vsech regionu a statu a sales officu.

Mozkem za timto procesem je vetsinou Global Price Manager a jeho par blizkych souputniku. GPM je vetsinou i de facto i sponsorem celeho projektu. On je i koncovy uzivatel tohoto Vendavo modulu.

Nekolik jsem jich potkal a i kdyz jsou to sympaticti lide, jedno vim jiste. Nechci plytvat jejich cas. Kdyz potrebujem jejich cas, chci aby to bylo opravdu neco podstatneho a ne aby z letiste v Hong Kongu mi hlasili, ze po kliknuti na tento dropdown aplikace spadne na NPE nebo ze Volume Rebate se pocita ze zakladu z Net Price a ne Invoice Price. Na to je jejich cas prilis drahy.

A jsou to veci, ktere QA hrave odhali podle funkcni specifikace, ktera sice nikdy nebude uplne idealni, ale svuj ucel plni. Problemy, ktere QA neodhali, byvaji specificke zakaznikovi, procesu, systemum z kterymi se integrujeme apod. a casto maji sve koreny ve fazi ziskavani pozadavku. Pak ale reseni techto problemu nevidi nepovazuji GPMs za ztratu casu.

Je dulezite si uvedomit, ze pokud nekomu dodavate software, z pohledu zakaznika se snazite vyresit svuj problem/bolest. A tito lide, kteri tento problem maji, maji na 99% malo casu. Z me zkusenosti je to tak, ze lide z tymu zakaznika, kteri s nami resi projektove veci, maji stale full time povinnosti ve svych funkcich. Price Manageri porad musi pricovat, Analytici analyzovat, Controlleri kontrolovat. Pro implementaci jsou cenni, protoze znaji realitu, ale jako testeri jsou prilis drazi.

Tecka.

Proto k nasi praci patri spickove fungujici QA, tym ktery musi mit autoritu, respekt a podporu (zdravim JetMinds QA crew).

Pokud je pro zakaznika ekonomictejsi pouzit „vlastni testery“, budiz. Ale je spousta pripadu (podle me vetsina), kdy to nejde a nedava to smysl.

A ted trochu off topic:

Existuje kupa metodologii, frameworku a literatury, ktera rika „delejte TO TAKHLE“, ale nerika co je to „TO“. Na toto tema doporucuju jiny clanek od meho – jak je jiste patrne – oblibence Joela Spolskeho, Top Five (Wrong) Reasons You Don’t Have Testers. Obzvlaste

Zdravim od Lago di Garda.

– Posted using BlogPress from my iPad

Let s Airbus A380

Minulý týden jsem absolvoval spolu s filemonem a jirkou píšou z JetMinds další příjemnou pracovní cestu do USA, opět Kalifornie a Silicon Valley. Z Paříže do San Francisca jsme letěli s Air France a to novým dvoupatrovým Airbusem A380, největším dopravním letadlem současnosti.

Inženýři Airbusu byli asi trochu hračičkové, protože každý pasažér má kdykoliv během letu možnost si na displeji na svém sedadle volit pohled ze tří kamer na letadle, které poskytují žívý obraz z letu:

Pohled z kamery na „ocase“ poskytuje uklidňující přehled situace, i když nesedíte u „okénka“ 🙂

A finále, těsně před přístáním na SFO – San Francisco International Airport:

U letadla je to taková „nice-to-have“ feature , ale potěší 😉