JIRA -> GitHub Issues

S VersionPressem silně zvažujeme přechod z Bitbucketu + JIRY na GitHub + GH Issues, což je docela zajímavý střet světů. Mám k tomu pár postřehů a i by mě zajímal váš názor, zkušenosti nebo případné komentáře.

Proč přechod

VersionPress, nebo minimálně jeho části, budou v dohledné době komunitní projekt a nedá se svítit, vývojáři jsou dneska na GitHubu. Tím jdou v podstatě všechny ostatní argumenty stranou, čímž neříkám, že GitHub nemá další pro – např. je cloud-hostovaný, rozumně levný, s plným API apod. Ale komunita je to, co nás “nutí”.

Přejít z JIRY je radost, ne?

Nevím. JIRA má z mého pohledu jen dva nedostatky: je pomalá a je pomalá. Jinak je to jednoduchý systém, s kanban boardem, logickým uspořádáním, moc toho v základu nechybí ani nepřebývá, zkrátka o JIŘE tak trochu platí, že pokud jste si na ni udělali špatný názor před deseti lety, dneska byste se divili.

Spolu s Bitbucketem, který používáme na pull requesty a code reviews, je to harmonický celek, který nás celkem ničím (kromě pomalosti) neštve a funguje dobře.

GitHub

Příslibem a současně problém GitHubu je, že by měl zvládnout roli JIRY, Bitbucketu a možná i ještě něčeho dalšího (lidi to např. často berou jako support kanál, viz label “question” v GH Issues). To je obecně velká výzva a je celkem jasné, že ji GitHub může v plné šíři zvládnout jen těžko.

Mé postřehy jsou následující:

1) Issue tracker doplácí na klasické “jednoduché neznamená nutně dobře použitelné”. V podstatě jediným kategorizačním mechanismem jsou labely, což by i mohlo stačit, kdyby byly udělané dobře. Ale přejmenovat label znamená udělat si v trackeru bordel (labely nemají identitu, v historii ticketů zůstanou jen jako string odkazující se na stránku k ničemu), z toho plyne nutnost je dobře navrhnout už od začátku, ale jak to má člověk bez zkušeností udělat, že jo, apod. Tohle je zcela proti konceptu don’t make me think a znovu, stačilo by, aby labely byly udělané dobře, ve stylu polí v jiných issue trackerech. Ale nejsou.

Plus to kupu věcí neumí, například varovat uživatele, že vkládá issue, která už pravděpodobně existuje, nebo ukládat historii editů, nebo přikládat libovolné soubory (docela nově umějí vedle obrázků aspoň DOCX a PDF). Něco z toho jsou menší věci, ale některé podle mě docela zásadní.

2) Issues používají stejnou číselnou řadu jako pull requesty. To je obecně hrozně zajímavý koncept – ne ta čísla, ale že PRs jsou v podstatě issues. Není to tak dávno zpátky, co mi tohle dávalo velký smysl. U nás se totiž běžně stávalo, že se ticket založil v JIŘE, nějak se tam lehce podiskutovalo, ale jak se začal psát kód a otevřel se PR, tak se komunikace přesunula tam. Ale jen částečně – pořád ještě šly nějaké komentáře k issues. Takže to bylo zbytečně a otravně rozdvojené a říkal jsem si, jak by bylo fajn, kdyby celý issue tracker byl jeden PR za druhým. A asi si to řekli i v GitHubu.

Jenže to nefunguje. Přišli na to sami, když před časem zakázali konvertovat issues do pull requestů – přinášelo to víc zmatku než užitku. Chtě nechtě, issues a PRs jsou dvě různé věci, ač relativně úzce propojené, a mělo by to být v UI i v číselné řadě oddělené. Mimochodem, na JIŘE zpětně oceňuju, že projekt má svůj klíč a číslo issue vypadá např. VP-123. Jak vidím něco takového kdekoliv (ve wiki, v mailu, …), okamžitě vím, že se jedná o VersionPress issue. #123 mi bez kontextu neříká nic, a ani v rámci kontextu projektu nevím, jestli to je PR nebo ticket :) #cognitiveLoad

3) Pull requesty by měly být pýchou GitHubu, ale upřímně, Bitbucket je má zas tak nějak ošklivější, ale funkčnější. Tam založím PR, přidám své kolegy jako reviewery, oni mi buďto dají fajfku jako že vše OK, nebo napíšou komentář, a z jedné stránky přehledně vidím, jak jsou všechny PR na tom. Dead simple. Na GitHubu to jde nasimulovat palcema nahoru nebo kdovíjak všelijak, ale podobně jako u issues, tam, kde mě tool Atlassianu vede a po applovsku mi nedává moc šanci udělat chybu, na GitHubu musím být kreativní a po androidovsku si to tak nějak vykoumat. To je přísné hodnocení, co? Zvlášť když vizuálně GitHub vypadá tak jednoduchý a cool…

Nicméně…

Statisticky na GitHubu projektu prostě fungují v pohodě. Je tam Facebook, Microsoft, Automattic (WordPress company) a mnoho dalších. Půjde to i u nás, jen asi musíme rezignovat z “čistoty” současných postupů. Ono se to asi stejně stane, až nám do našeho “svatého” issue trackeru začnou lidi valit jednu duplicitu za druhou. Jak už to bývá, u issue #5 zamrzí, že je zabraná nějakým blbým pull requestem, ale u issue #2617 je to už úplně jedno.

Prosba – zkušenosti s OSS projekty

Na závěr bych vás moc rád požádal o jakékoliv tipy, které máte k provozování OSS projektů na GitHubu, hlavně z pohledu autora / maintainera. Pro nás to bude nová zkušenost, a pokud by se daly ušetřit nějaké starosti, určitě by to neuškodilo :) Díky a konec úvahy.

VersionPress – seznamte se

Dnes spouštíme crowd-funding kampaň pro náš asi nejambicióznější projekt, VersionPress. V jádru nabízí plnohodnotné verzování WordPress webů (souborů i databáze), v důsledku ale umí o dost víc. Plný popis najdete na oficiálním webu, tady na blogu bych se chtěl trochu soukromější formou podělit o to, co k VersionPressu vedlo a proč je to taková bomba :) Continue reading

IntelliJ IDEA – kovbojské IDE

Zkouším pro Flexový vývoj přejít z Flash Builderu (IDE postavené nad Eclipse) na IntelliJ IDEU, což je obecně nástroj vynášený do nebes a i kupa Flexařů přešla a přechod doporučuje. Tak to zkouším a je to hodně zajímavá zkušenost.

Na jednu stranu, a to o nástrojích JetBrains platilo vždy, jejich IDE je velmi inteligentní a dobře rozumí kódu. Flash Builder v tomto taky není úplně špatný a o vztahu různých symbolů v projektu má slušnou představu, ale IDEA je určitě dál. V praktické rovině je například daleko pohodlnější se z deklarace rozhraní prokliknout na jednotlivé implementace (ve Flash Builderu nutno neohrabaně přes Find References), lze udělat rychlý diagram závislostí mezi projekty atd. atd. Tohle je, hádám, hlavní důvod, proč tolik (nejen Flex-) vývojářů IDEU vynáší do nebes a fakt je příjemné v tom kódit, pokud všechno ostatní funguje.

Jenže v tom je ten háček. Už u JavaScriptového vývoje ve WebStormu u mě zhruba platilo, že co hodina práce v IDE, to jeden reportovaný bug. Trochu jsem doufal, že u silně typového Flexu, kde kompilátory i debugger jsou odladěnou součástí Flex SDK a IDE je tak vlastně jen malou slupkou nad nimi, to bude lepší, ale už jen import našeho projektu do IDEY byl docela dílem a dokonce se muselo čekat na opravný setinkový release, aby náš projekt vůbec bez změny kódu fungoval. A potom mám ohromný problém s použitelností toho IDE – ne se vzhledem, ale s fundamentální použitelností na mnoha místech. Continue reading

Webdesign z pohledu programátora, vol. 2014

Po delší době jsem se dostal ke kódování HTML/CSS a jsem překvapen, ne, doslova šokován, jak se věci posunuly dopředu. Pro mě jako pro programátora bylo dělání webů vždycky spíš za trest – když člověk nežil kódováním každý den, bylo docela peklo vyhnout se všemožným záludnostem a doručit výsledek, který by nebyl vyloženě pro ostudu.

V roce 2014 jsou ale věci jinak. Zmíním hlavní věci, které mě zaujaly; některé evidentnější, některé méně. Continue reading

IdeaPaint – vyplatí se?

Někdy mám pocit, že my ajťáci jsme trochu posedlí bílými tabulemi, respektive čímkoliv, k čemu se dá na chvíli vstát a čmárat na to jakože užitečné věci. Já tímto postižením trpím, a když jsem proto před rokem zjistil, že po přestěhování do nové pracovny se mi tam moje tehdejší tabule nevejde, začal jsem pátrat po alternativách. Narazil jsem na IdeaPaint a znělo to opravdu skvěle. Jaká byla realita, popisuje tenhle zápisek.

Continue reading

Co mi vadí na Visual Studiu

Jarda Jirava se před nedávnem na Twitteru zeptal, jestli máme nějaké připomínky k Visual Studiu, a ať mu případně dáme vedět. Nu, máme :) K Visual Studiu jsem se už mnohokrát vyjadřoval (např.), ale nikdy jsem nešel moc do hloubky. Protože má ale Jarda jakožto MVP možnost setkat se přímo se zodpovědnými lidmi z Microsoftu a tedy aspoň teoretickou šanci věci ovlivnit, budu tentokrát konkrétní. Continue reading

Zoufalý stav JavaScriptových IDE

Už pár let je ve světě “běžného” softwarového vývoje jasné, že se JavaScriptu nedá a nebude dát vyhnout. Máme teď v Agiliu rozpracované tři projekty a každý z nich JavaScript víc nebo míň používá, ať už na klientu (a tady nejde jen o browsery, ale i o instalované aplikace) nebo na serveru (Node.js). JavaScript je už dneska skoro všude a ani do blízké budoucnosti to nevypadá, že by se trend měl nějak otočit.

Proto jsem čekal, že pro něj budou existovat dobré nástroje. A když říkám dobré, tak nemyslím editor, který podbarví kód a trochu tuší, co v kódu je identifikátor kvůli snazší navigaci. Myslím tím normální IDE, jako existují snad pro každou jinou technologii, tj. kontrola kódu, vychytaná navigace po symbolech, mechanismy pro dělení větších projektů na menší celky (knihovny), ladění atd.

Jaká je realita v roce 2012? Upřímně, docela zoufalá. Continue reading

WebExpo 2012 – Nepoužívejte Git jako SVN!

Na začátku tohoto týdne zde na DevBlogu Michal Špaček představil témata, která si přihlásil do letošního ročníku konference WebExpo a zároveň vyzval ostatní, aby zveřejnili ty své. Jak ale ukazuje hledání #webexpo #ukazprihlasku, tak se k iniciativě zatím zřejmě nikdo nepřihlásil.

Nechci v tom Michala nechat samotného, a tak jsem také přispěchal se svojí troškou do mlýna. Přijde mi, že se nám tu v poslední době rozmohl takový nešvar – za posledních několik let se stal Git velmi populárním, ale pozoruji, že ne každý si je jistý, jak tuto technologii uchopit. Pracovní název zmíněný v titulku tohoto článku je poněkud bulvární, SVNkem se ve své přednášce zabývat nebudu, budu povídat čistě jen o Gitu.

Moje přihláška není zdaleka tak zábavná, jako ta Michalova, ale doufám, že se mi v ní podařilo dobře zachytit mojí motivaci a připravované téma. Záleželo mi na tom dokonce natolik, že jsem přihlášku odeslal 2 dny (!) před deadline.


Čím se nyní zabývám?

Pracuji v Medio Interactive jako senior vývojář. Starám se především o kvalitu vývoje – jak z pohledu dodržování správných programátorských postupů, tak i určitého pracovního workflow. Dále se zabývám analýzami projektů, tvorbou wireframes a vedením projektů. V rámci Medio Akademie vedu školení Gitu a pokročilého vývoje a testování aplikací. Studuji magisterské studium na ČVUT FEL OI.

Čeho si z toho, co jsem dosud dosáhl, nejvíc vážím?

V Mediu jsem prakticky od vzniku firmy a už od začátku jsem začal prosazovat, abychom dělali věci “správně”, tak, aby se nám to z dlouhodobého hlediska vyplatilo. Myslím, že se mi to povedlo, protože nyní je u nás radost vyvíjet. Neřešíme problémy s programovacím jazykem jako takovým, ale můžeme se soustředit čistě na řešení projektu. Projekty, na kterých pracujeme, jsou relativně velké, ale díky našim postupům a zázemí není složité je udržovat.

Čeho bych chtěl dosáhnout?

Když jsem začínal, dělal jsem klasicky vše okolo webů – programování, kódování, “grafika” a spol. Poté jsem se začal specializovat čistě na programování, ale nyní se od něj zase trochu vzdaluji. Snažím se mít přehled a být otevřený novým technologiím a možnostem. Zároveň je ale posuzuji z kritického hlediska praktičnosti. Přehled se snažím mít obecně dost široký na úkor hluboké znalosti jednotlivých záležitostí. Jako každý samozřejmě do některých věcí “vidím” více a do některých méně.

Na co se na Webexpo těším?

Jako každý rok se na Webexpo těším především z pohledu networkingu, je to skvělá příležitost pro setkání s kamarády a “kolegy”, se kterými se člověk přes rok běžně nevidí. Letos se těším ještě více než jindy, protože jsem se bohužel loni zúčastnit nemohl kvůli zdravotním problémům, letos si to hodlám plně vynahradit!

Kvalitní přednášky pak už beru jako samozřejmost, slouží mi především k rozšíření obzorů a jako podnět, jaké zajímavé věci bych mohl dále zkoumat. Vítám také přednášky zahraničních speakerů, protože není tolik příležitostí si tyto lidi u nás poslechnout. Ještě zajímavější je pak možnost si s těmito lidmi osobně promluvit.


O čem to bude?

Chtěl bych promluvit o workflow vývoje projektů pro firmy, kde používají (nebo chtějí používat) Git. Spousta firem začala používat Git místo SVN nebo CVS, nové firmy sahají po Gitu (nebo Mercurialu) skoro automaticky, ale většinou nejsou úplně schopné využít všech jeho možností. Git díky svojí flexibilitě nikomu žádné konkrétní workflow nenutí, což je obrovská výhoda, ale je potřeba si nějaká pravidla stanovit samostatně. Během přednášky bych rád představil několik možných přístupů a srovnal jejich dopady na vývoj projektu. Představím jednak workflow, které jsme vymysleli cca před rokem v Mediu a od té doby prakticky beze změn velmi úspěšně používáme, tak některé jeho varianty, které mohou sedět lépe dalším firmám. Mezi tyto varianty určitě patří i Git-flow, které mohou někteří znát.

Co z toho návštěvníci získají?

Přehled o možnostech Gitu a různých přístupech k jeho využívání v rámci různých typů firem. Na začátku probereme určitě i best-practices pro práci s Gitem, protože to s workflow a jeho snadným udržováním velmi souvisí.

Ukážeme si tedy klasické problémy, které vznikají v různých fázích vývoje, a jak na ně vhodně reagovat. Tzn. jednak, jak kód integrovat a koordinovat práci v týmu, tak i části, které ovlivňují deployment.

Pro koho to je?

Pro návštěvníky z malých či středních firem, kde se řeší, jakým způsobem má spolupracovat více (2+) lidí na jednom projektu. Na toto téma se mě v poslední době ptá čím dál tím více lidí. Při přípravě přednášky budu vycházet z těchto otázek od konkrétních lidí a projektů – jsou si dost často velmi podobné.

Přednáška bude zajímavá jak pro vývojáře, jejichž denním chlebem by používání verzovarcího systému mělo být, tak i pro další členy týmu jako jsou kodéři a grafici. Pro vedoucí projektů může být přednáška určitě také zajímavá, protože odhalí možnosti Gitu, které napomohou řešení nebo v ideálnějším případě předcházení krizovým situacím.


Doufám, že vás toto téma alespoň trochu zaujalo, pokud ano, budu rád za jakýkoliv feedback. Podoba výsledné přednášky zdaleka není stanovená, takže vaše komentáře mi mohou pomoci ještě rozšířit spektrum problémů, které budu při přípravě prezentace uvažovat (nebo mi naopak dovolí koncentrovat se na několik skutečně nejčastějších případů).

Markdown a jeho využití při vývoji

V projektech bývá dobrým zvykem mít nějaké “README” nebo obecně informační soubory, a ty se pořád ještě často ukládají jako *.txt. Výhodou je, že takový soubor se otevře a zedituje kdekoliv, na druhou stranu je škoda používat soubory bez formátování, když se formátovaný text čte o tolik líp. Proto jsem viděl “README” soubory v RTF (fuj), v HTML (daleko lepší) nebo jiných formátech (radši pomlčet), ale pokud jste v poslední době navštívili nějaký projekt na GitHubu, mohli jste vidět něco takového:

github-markdown

Díky GitHubu (ač ten sám podporuje formátů víc) i několika dalším velkým webům (např. Stack Overflow) se zdá, že se de facto standardem stává Markdown. Pokud jste ještě nikdy Markdown neviděli, jakkoliv je to nepravděpodobné, vypadá takto:

Welcome to the psake project.
=============================

psake is a build automation tool written in PowerShell.
It avoids the angle-bracket tax associated with executable XML
by leveraging the PowerShell syntax in your build scripts...

## How to get started:

**Step 1:** Download and extract the project

...

Jedná se tedy pouze o drobně naformátovaný textový soubor, který má tu výhodu, že při zachování určitých pravidel ho lze převést na hezky naformátovaný, dobře čitelný výstup.

Osobně nemám Markdown příliš v lásce, některé věci v syntaxi chybí, jiné by mohly být elegantnější a třeba odsazování bloku kódu čtyřmi mezerami mi vyloženě vadí, přesto se zdá, že tento formát “vyhrál”. Podporují ho velké weby, existují pro něj editační nástroje, převaděče v celkem libovolném jazyce apod. Ačkoliv se mi tedy třeba syntaxe Texy! líbí stokrát víc, Markdown je dnes, zdá se, nejpraktičtější volbou.

Co se nástrojů týče, Markdown je tak jednoduchý, že se dá v pohodě psát ručně, přesto bych na pár zajímavých pomocníků rád upozornil.

markdownpad

Předně doporučuji MarkdownPad – jedná se o malou Windows aplikaci, kde vlevo píšete Markdown a vpravo se rovnou zobrazuje výsledek. Fungují tam všechny obvyklé klávesové zkratky (Ctrl+I, Ctrl+B apod.), výsledek se dá snadno vyexportovat do HTML souboru a předně je možno s MarkdownPadem asociovat přípony *.md, *.markdown apod., což značně usnadní editování lokálních Markdown souborů.

vs-markdown-plugin

Podobná věc existuje i jako plugin do Visual Studia, která je navíc zajímavá tím, že zvýrazňuje strukturu už na úrovni zdrojového souboru (nadpisy tak stále obsahují formátovací znaky, ale jsou vyrenderovány větším písmem, nebo třeba odkazy jsou zvýrazněny jinou barvou apod.).

Editory existují i na webu, např. Online Markdown Editor nebo prostě začněte psát text do nějaké textarey, která Markdown podporuje, např. na Stack Overflow. Koneckonců, i tento blog v komentářích Markdown podporuje…

Zkrátka pokud děláte softwarový vývoj, může se Markdown stát sice malým, ale milým společníkem.