tech

There are 5 posts filed in tech ().

Linux na Windows

Neptejte se mě proč, sám z toho občas nejsem nadšený, ale jako jeden z posledních lidí na světě jsem stále na Windows. V praxi se s nimi dá žít, ale nebudu zastírat, že souhlasím s filosofií “čím linuxovatější, tím pro vývoj lepší“. Dobře to uchopil Mac, kterému se historicky podařilo skloubit dobrý hardware, použitelné uživatelské prostředí a unixový základ systému. Pro mě osobně je pak ještě lákavější Linux, zvlášť v době zařízení typu Dell XPS 13 Developer Edition, ale případné úvahy na toto téma nechme na jindy. Teď bych se chtěl podívat na to, jak jsou na tom Windows s linuxovými nástroji dnes.

“Linux” jde do systému dostat třemi základními způsoby:

  1. Cygwin nebo MSYS2, v podstatě emulace UNIX-like / POSIX prostředí. Mimochodem, v MSYS2 je plný pacman, package manager z Arch linuxu, takže je to docela ‘real deal’.
  2. Git for Windows, se kterým přijde “Git Bash”. Do začátku dobrá a jednoduchá možnost, založená na MSYS2 (zde jsou detaily).
  3. Windows Subsystem for Linux (WSL), známý především skrze “Bash on Ubuntu on Windows” (Microsoft pojmenování vždycky uměl!).

První dvě možnosti jsou dobré v tom, že z cmd.exe lze snadno dělat věci jako rm -rf nebo grep, aktivně to využívám a už to Windows povyšuje na jinou úroveň.

Hodně zajímavá je ale třetí možnost, WSL. To je totiž (zjednodušeně řečeno) plné Ubuntu běžící “nativně” ve Windows. WSL emuluje Linux kernel a umožňuje spouštět normální Linux binárky, takže třeba když donedávna pro Windows chyběl kubectl klient, šlo ho doinstalovat pomocí apt-get install a frčet. Další důležitý use case je výkon, např. přefiltrovat Git historii je daleko rychlejší ve WSL než v Git for Windows. Nevýhodou pak je, že je to v podstatě systém v systému: binárky se instalují dvakrát, sync mezi počítači si jinak řeší Windows a Ubuntu, apod.

Windows (včetně WSL) mají ještě jeden zásadní problém, a to je výkon. Např. Git operace jsou na čistém Linuxu rychlejší minimálně o řád. Nevím, jestli to je pomalostí NTFS nebo je něco špatně v jádře Windows, ale zatímco lehký opruz se zpětnými lomítky, tupým základním shellem apod. se dá řešit, výkon bohužel ne.

Naštěstí se poslední dobou dějí v Microsoftu věci. Pro samostatný blog post si nechám to, co dělají kolem Gitu, a zatím postnu toto:

NTFS změny v příštích Windows

Nebo se podívejte na tento komentář na GitHubu. V Microsoftu vědí, že mají problém, a snaží se. Celkem nemám pochybnosti, že technicky se stanou velké věci: např. nativní běh Dockeru na WSL je IMO jen otázkou času (a byla by to pecka!). Pak je ještě otázka, nakolik se podaří propojit historicky dva oddělené světy, například bych si ve svém oblíbeném klikacím Git klientovi rád nastavil git binárku tu z Linuxu, půjde to? A kde se bude ukládat klíč k GitHub účtu, ve Windows Credential Storu nebo v Linuxovém ekvivalentu? Frikci bohužel očekávám a “Mac je stále Mac”, ale za posledních mnoho let je zrovna teď čas, kdy je naděje na vývojářsky silné Windows asi největší.

VersionPress na WordCampu v Praze

Minulou sobotu proběhl WordCamp v Praze, kde už docela tradičně ukazujeme progres VersionPressu za poslední dobu a kde mi taky pravidelně failují dema 🙂

Moje prezentace (spíš doprovodná k obecnému povídání; co na plat, když mě dali do místnosti pro uživatele):

A skvělá technická prezentace Honzy Voráčka:

Mimochodem, zrovna dneska je pro VersionPress velký den, na hostovaném prostředí s pracovním názvem ‘versionpress.com’ běží první externí web, a to hned pořádný: GripTV. Někdy o tom napíšu víc.

Monorepo

Dva týdny zpátky jsme ve VersionPressu přešli na monorepo, tj. jedno velké repo namísto řady menších. Byl to interně trochu kontroverzní krok a i na webu se najdou silné názory na obě strany, tak sem hodím pár našich poznámek a zkušeností. (Ahoj Alice!)

Proč monorepo?

Jednou větou hlavně proto, že nás už štvala režie kolem správy více repozitářů. V reálu jen jejich kombinace reprezentovala projekt jako celek, jedna logická změna byla často v několika pull requestech v různých repech, nebylo vždy jasné, kde vůbec založit issue, atd.

Zbytečný overhead.

Na co myslet

Monorepo některé věci komplikuje. Konkrétně:

  • CI je náročnější na správně nastavení. Např. zbuildit je potřeba jen změněné věci a detekce toho je složitější.
  • Labely u issues potřebují víc struktury a disciplíny.
  • Emailové notifikace jsou komplikovanější. GitHub umožňuje sledovat jen mentions, assignments apod., ale úplně srovnatelné se sledováním samostatného repa to není.
  • Sdílení repa se subkontraktory budeme muset nějak pořešit, nejspíš subtree splitem a manuální synchronizací; nemám s tím zkušenost a trochu tady očekávám opruz.

U opravdu velkých rep pak může být problém s jejich škálováním, ale tam ještě zdaleka nejsme a kdoví, jestli vůbec někdy budeme. Zajímavé by bylo slyšet od Jakuba Vrány, jak jim to funguje v Googlu (tam je nejen monorepo, ale i single line of history).

Po dvou týdnech jsme zatím spokojení.

Jak mergnout repa

Tady je skript, který jsme několikrát použili (jsem Bash lama, ale funguje to):

Push je normálně do branche, otevřeme k tomu (trošku větší 🙂 ) pull request, můžou se pak udělat ještě nějaké dodatečné úpravy např. v README a nakonec merge.

Máte někdo s monorepem zkušenosti a dobré rady pro nás ostatní?

WordPress

Tento blog běží na WordPressu. Kvůli VersionPressu vlastně “nemám jinou volbu”, ale ani ji mít nechci – to je koneckonců konečným cílem našeho snažení. Přesto je pro mě vždycky zajímavé zažít WordPress od začátku, jako běžný uživatel.

Zabrouzdal jsem do archívů a tohle jsem psal čtyři roky zpátky:

Redakční systém, do kterého bych se zamiloval, jsem ještě nepotkal, takže bylo potřeba vybrat nějaký “špatný”. Volba padla na WordPress hlavně proto, že jsem si s Drupalem dostatečně užil na svém předchozím blogu a Joomla je principiálně podobná.

WordPress je bastl, ale velmi úspěšný bastl. To má své výhody, např.: na skoro cokoliv seženete plugin (je jich snad až moc), existuje nepřeberně témat vzhledu, pro WordPress existují komerční hostingy, Android aplikace, importéry / exportéry do jiných systémů atd. atd.

Pak ale začnete narážet na realitu, která úzce souvisí s tím, že WordPress je uvnitř jeden velký bordel. Například: pluginy jsou v různé kvalitě a různě (ne)kompatibilní. WordPress neřeší testovací prostředí. Tím, že je něco v souborech a něco v databázi, je sync mezi testovacím a živým prostředím komplikovaný a žádný pohodlný postup nebo plugin na to není.

Navzdory tomu všemu, navenek je WordPress docela hezký a příjemně použitelný software, ačkoliv si pořád někde vzadu říkám – to vážně v roce 2012 neexistuje pořádný CMS?

Pořád překvapivě platné, akorát na testovacím prostředí se pilně pracuje 🙂 Nemůžu říct, že by experience s WordPressem byla dnes nějak dramaticky lepší než pár let zpátky.

Přesto, nebo právě proto, je fascinující, jak se WordPressu daří. Je na 27 % webu a stále roste, navíc nejvíc ze všech platforem. Taky je pravda, že užitečných věcí vzniklo dost:

  • WordPress má krásné CLI rozhraní, např. wp post create namísto klikání v UI.
  • Od čerstvě vydaného WordPressu 4.7 je každý web malým REST API nodem v distribuované síti čtvrtiny webu. Tohle ještě bude zajímavé.
  • PhpStorm má špičkovou podporu WP. I PHP samo za poslední roky udělalo slušný pokrok, ačkoliv TypeScript to pořád není, no.
  • Docker a podobné věci dávají nové možnosti, jak WordPress hostovat (tohoto se jako firma brzo začneme účastnit).
  • Celkově WP komunita hodně vyspěla, jsou zde specializované “managed hostingy”, agentury, konference apod.

Přesto pro občasného WP uživatele celkový gut feeling zůstává dost podobný: brouzdání miliardou polofunkčních a polohezkých témat je vyčerpávající, úpravy webu člověk nejradši sfoukne klikáním na živém webu nebo přes FTP (brrr, ale o moc líp to nejde), atd. Nebyl jsem z budování tohoto jednoduchoučkého blogu vůbec nadšený, a ani výsledek není moc super, ale už se mi tím nechtělo trávit víc času. A to je blogování pořád jedním z hlavních use casů pro WP…

Pokud WordPress používáte a trochu trpíte v podobném stylu, co vám vadí / chybí nejvíc?

Git a konce řádků

Věčný boj, částečně daný Windows, ale především nějakým dobrákem Git-vývojářem, který se snažil být nápomocný. Co je verzovacímu systému po konci řádků? Tady jsou poznámky, co jsem si udělal asi před půl rokem (v “originále”; občas prosím omluvte jazykovou rozpolcenost):

  • this is really fucked up
  • CRLF is fucked up
  • core.autocrlf false is fine until you want to enforce LF in the repo using * text=auto
  • when you do that, Git ignores core.autocrlf and will look at core.eol to see how to handle files on checkout, and it will use native by default which will convert LF to CRLF
  • there is NO WAY to tell Git “leave files alone on checkout” if you have .gitattributes. this is really sad
  • * text=auto eol=lf is fucked up too because for some reason, the eol=lf will also be applied to binary files.
  • (Git cannot force CRLF in the repo, only LF.)
  • (!eol – http://blog.subgit.com/tag/lf-will-be-replaced-by-crlf/)
  • Good read: http://www.hanselman.com/blog/YoureJustAnotherCarriageReturnLineFeedInTheWall.aspx

Naštěstí to vypadá, že Git 2.10 to opravil! Mělo by tak fungovat jednoduché * text=auto eol=lf v .gitattributes. Hurá!