Borek Bernard se představuje

Vývojář, školitel, pisálek. Na Twitteru jako @borekb, více info na borekb.cz.

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.

Nový .NET – promarněná příležitost?

Pokud jste nebyli poslední dva dny kompletně offline, nemohlo vás minout, že Microsoft oznámil “nový .NET” – plně open source (MIT licence), na GitHubu, rozběhatelný na Linuxu a Mac OS, k tomu Visual Studio zdarma atd. I z programátorského pohledu začínají konečně fixovat roky staré bolístky a například ASP.NET 5 bude hezký, moderní stack se vším všudy (příčetný projektový systém, o hodně vylepšený vývojový i deployment model a podobně).

Tohle všechno je paráda, a třeba to Visual Studio zdarma jde podle mě daleko za očekávání, přesto jsem si uvědomil jednu věc, když jsem koukal na parádní integraci C# do Sublime Textu: není to všechno jen svým způsobem promarněná příležitost? C# v Sublime Textu skoro včetně refaktoringu, wow, ale je C# ten jazyk, který dlouhodobě chceme? Je .NET a jeho BCL a jeho konvence a jeho všechno to, co dlouhodobě chceme? Celý příspěvek

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 :) Celý příspěvek

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. Celý příspěvek

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ě. Celý příspěvek

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.

Celý příspěvek

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í. Celý příspěvek