Monthly Archives: February 2014

Můj toolchain

Poměrně často se mě lidi ptají co používám za nástroje, proč AppCode a ne Xcode, apod. Nemám čas reagovat na všechno (sorry) a tak to shrnu v tomto příspěvku. Později se na jednotlivé nástroje podíváme detailněji a přidám více ukázek, které dají odpověď na otázku – proč?

Celkový přehled vám dá následující obrázek, který ukazuje úplně všechno – od začátku až do konce. Zelené čáry / šipky představují automatizované procesy a červené označují věci, které se ještě dělají ručně.

YouTrack

YouTrack je mozkem celého projektu. Obsahuje úplně všechno a celý projekt se tím řídí. Používám Agile Boards (sprinty, swim lanes, …) a co není v YouTracku, jako kdyby neexistovalo. Proč tak striktně? Problém je, že ve všech těch emailech, Skype hovorech, HipChatu, … se nedá hledat, je v tom bordel a pokud to není na jednom místě, s největší pravděpodobností na to zapomenu, ztratí se to, už to nedohledám, … Další věc je, že potom se dá předejít hádkám o tom co kdo řekl, neřekl, slíbil, … Takže pokud něco dělám, mám to v YouTracku. Sebemenší blbost a to i když si to zadávám sám sobě.

Zkoušeli jsme všechno možné. Od Basecampu, Unfuddle, GitHib Issues a všechno to jsou nepoužitelné hračky pro děti. Nedá se to pořádně automatizovat a nic to neumí. Když už má být všechno na jednom místě, musí to být mocný nástroj a musí to být automatizovatelné, filtrovatelné, …

YouTrack otvírám v prohlížeči pouze v případě, že připravuju sprinty nebo dělám další věci související s managementem projektu. Jinak není potřeba, viz. AppCode.

AppCode

Nemám rád Xcode a vůbec se tím netajím. Je to pěkná sračka. Preferuji AppCode. JetBrains má na webu napsáno Objective-C IDE done right. A to přesně vystihuje moje pocity. Xcode obsahuje spoustu serepetiček, ale věci, které denně potřebuji (refactoring, …) prostě pořádně neumí. Interface Builder mě nezajímá (nepoužívám, jinak JetBrains vydal early preview pro UI Designer) a tak mě vůbec nic nenutí Xcode používat. Jasně že bych kecal, kdybych řekl, že z Xcode nepoužívám nic. Občas ho pustím na editaci modelu pro CoreData (to AppCode neumí), používám ho na release aplikací do App Store a také používám nástroje jako Instruments, apod.

Nejen, že AppCode umí spoustu věcí lépe, ale umí i něco navíc. Například se krásně integruje s YouTrackem. Naprosto geniální je funkce Tasks & Context. Když chci něco dělat, otevřu přímo v AppCode task, který je založený na issue v YouTracku. AppCode si ty issue sám načte, vytvoří branch, přepne context, nastaví issue na In Progress a já můžu v klidu pracovat aniž bych pouštěl prohlížeč a tam hledal issue, měnil stav, … Když práci dokončím, AppCode issue nastaví na Fixed (takže QA hned ví, že v dalším buildu může testovat a nastavit na Verified nebo Reopened) a mergne můj branch do masteru. Task & Context si pamatuje branche, otevřené soubory, … Takže když mě někdo vyruší, že něco potřebuje, přepnu Task / Context a potom se vrátím tam kde jsem byl. Jednoduché, geniální a dost to šetří čas.

A JetBrains má otevřený YouTrack, takže cokoli se mi nelíbí, můžu nareportovat a oni na to promptně reagují. Není větší pruda než popisovat bugy Xcode do černé díry jménem Radar. Nejvíc mě irituje fakt, že u Applu nevidím kdo co reportoval, takže spousta lidí smolí popis stejných bugů, … Reakční doba příšerná, občas žádná, … Zlatý JetBrains a jejich YouTrack, fakt.

GitHub

Z něho se používá pouze git repo. Většina nástrojů (jako třeba Travis CI) se s ním umí integrovat a tak nemá smysl zkoušet něco jiného. Ztráta času. Na to jsme měli čas na vysoké na kolejích, ale teď se musí makat a neřešit nepodstatné ptákoviny. Když to funguje, neměň to.

Travis CI

Travis CI celý proces vývoje zjednodušuje a zrychluje. Pro veřejná repa je for free, pro privátní je to placená služba. Každá nová featura, bug fix, … má svůj branch. V něm se vyvíjí, zkouší a testuje. Jakmile provedu merge do masteru, k lizu se dostává Travis. Vezme branch master, zkompiluje, spustí testy a pokud je všechno okay, vytvoří build a nahraje ho rovnou do HockeyApp. Tam si ho vezmou testeři, klienti a můžou si hrát.

Když sečtu všechen čas, který jsem trávil buildama, uploadem, testama, … je to dost velká úspora. A to nemluvím o tom, že jsem línej a jsem rád, že už to za mě dělá Travis. Jestli build prošel, nebo neprošel, jsem informován na HipChatu a emailem. Možnosti jsou nepřeberné.

Proč jenom branch master? Platí pravidlo, že než člověk odejde domů, rozdělená, nedokončená, … práce je pushnutá do separe branche. Takže to nemá smysl testovat. Vznikl by větší overhead z failnutých buildů a to nikdo číst nechce. To by se dalo nějak filtrovat, řešit, ale další problém je, že git má občas (dost často 🙂 problémy s mergováním XML balastu jménem project.pbxproj. Takže i kdyby se udělal automatický test branche a jeho automatický merge, s největší pravděpodobností to failne a stejně by nastoupila ruční práce. A pokud používáte Interface Builder, je merge ještě větší peklo a dobře vám tak. Takže je to taková zlatá střední cesta.

HockeyApp

HockeyApp používám na distribuci mezi testery, pro klienta, … Dále mi ukládá crashe, takže vím co se děje a mnohem důležitější je fakt, že HockeyApp všechny crashe automaticky reportuje do YouTracku. Takže odpadá další ruční práce s procházením crashů v HockeyApp, tříděním, …

Proč HockeyApp a ne třeba TestFlight? Nemám odpověď. TestFlight nepoužívám, protože všechno co chci umí HockeyApp. Možná je v něčem lepší, možná horší, nevím a je mi to fuk.

HipChat

HipChat je docela cajk. Je to postavené na Jabberu, ukládá to historii, můžu vyhledávat. Lze se přihlásit i v prohlížeči a pokud nechci jejich nativního klienta, použiju jiného. Stačí aby uměl Jabber. Je to pracovní nástroj, komunikují přes něj všichni a tak nemusím mixovat soukromý Skype a další věci s prací. Historie na webu, vyhledávání, funguje to, netřeba měnit.

Release

Finální verzi releasuju pořád ještě ručně. Dalo by se to zautomatizovat, ale tohle si raději ještě sám prověřím. Takže pustím Xcode, vytvořím archiv a vyzkouším to na telefonu / počítači / … Pokud je to okay, tak nebuildím novou binárku (to nikdy nedělejte, vždy uploadujte stejnou binárku, jenom jinak podepsanou), ale tu archivnutou podepíšu jiným certifikátem a rovnou z Organizeru ji pošlu Applu na review. A modlím se, že se kluci dobře vyspí.

Velmi hrubý a odlehčený pohled na můj toolchain a způsob práce. Příště se k jednotlivým nástrojům vrátím s podrobnějším komentářem a ukázkama jak to reálně funguje.

Stay tuned! 😉

DISCLAIMER – Je to jen můj osobní názor na výše uvedené produkty. Nikomu to nenutím, používejte si co chcete. Jen po pár letech plácání jsme našli obstojné nástroje, které zdá se fungují a splňují všechny požadavky. A nesnažte se mě přesvědčit, že Xcode je dobrý nástroj. Stejně jako třeba GitHub Issues. Není. Tečka.

P.S. Píšu sice mě, já, …, ale takhle to děláme v té nejlepší firmě na světě – v Tapmates, Inc. 😉

Braintree a prapodivné requesty na doménu example.com

V jedné z aplikací na iPhone jsme implementovali platební systém Braintree. Vcelku pěkná věc a jednoduchá na implementaci. Jak na straně klienta (iPhone aplikace), tak na straně backendu (Ruby). “Neřeší” se security, nikde se nic neukládá, všechno je v režii Braintree a my jenom posíláme speciální tokeny. Fakt pěkný. Po otestování jsem zavřel ticket a po pár dnech mi to QA hodilo zpátky na hlavu. Že se objevují zvláštní requesty na doménu example.com.

Continue reading