Vývoj ASP.NET (Core) aplikací na MacBooku, velké shrnutí zkušeností
Článek se vztahuje k verzi produktu MacBook Pro 2017, 13"
Tento článek byl napsán v roce 2018. Vývojářské technologie se neustále inovují a článek již nemusí popisovat aktuální stav technologie, ideální řešení a můj současný pohled na dané téma.
Posledních několik měsíců jsem viděl mnoho .NET vývojářů pracovat s MacBookem a přirozeně mě zajímalo, zda je MacBook pro .NET vývojáře vhodnou lopatou či nikoliv. Před dvěma měsíci jsem cestou z Malajsie koupil nový MacBook Pro (model 2017) a po mém návratu do Česka jsem začal podrobovat MacBook zkouškám. Jak to dopadlo se dočtete v tomto článku.
Proč uvažovat nad změnou?
To je věc osobních preferencí. Mně osobně Windows nesedí, nelíbí se mi a práce s tímto systémem je pro mě spíše nepříjemná povinnost než zábava. Windows se za posledních několik let posouvá zvláštním směrem, snaží se být univerzálním systémem ačkoliv to dle mého názoru není žádoucí. Systém jako takový není pěkný (vlastně je čím dál hnusnější), ovládání není intuitivní a i když je to systém mocný a nabízí plno užitečných funkcí, většina z nich se ztrácí v záplavě zbytečných nabídek. Užitečné funkce uživatel neovládne, dokud se o ně nezačne aktivně zajímat a aktivně se je učit. Propojit Windows s dalšími zařízeními lze prakticky jen volbou správných cloudových služeb (například desktop + telefon). Dobré to není ani s hardwarem, protože Windows jakožto UNI systém je dodáván na plno zařízení (hlavně tabletů), kde je prakticky nepoužitelný. Dokonce ani v případě Surface Book 2 není situace z mé cca 2 měsíční zkušenosti používání o moc lepší.
Je macOS lepší desktopový systém?
Myslím, že nejen v subjektivní rovině je macOS lepším systémem. Apple vyvíjí od počátku věků čistě desktopový systém a neustále jej inovuje. Má zcela odlišnou strategii než Microsoft, který cca každé 2 roky přijde s velkou senzací a něco z gruntu předělá. Revoluce se koná vždy spíše v Microsoftu než u konečných uživatelů. Ti jsou totiž citliví na změny a potřebují, aby se do nich novinky vpravovaly s chirurgickou opatrností a železnou pravidelností. Je to dle mého názoru klíč k tomu, aby uživatel pomalu vstřebával nové funkce a přirozeně se je učil. Strategie Applu a stabilita platformy dává příležitost ke vzniku dobrého účelového softwaru odladěného pro úzkou skupinu zařízení, který se neustále inovuje. Aplikace na macOS jsou stabilnější, lépe spolupracují a při práci s nimi má uživatel dobrý pocit. To je něco, co jsem z Windows vůbec neznal.
K macOS neodmyslitelně patří i fungující kus hliníku. Pokud má někdo estetické cítění, MacBook (jakýkoliv) je zařízení, které člověk používá rád, ke kterému rád usedá a u kterého si může být jistý, že když otevře víko, může za 2 sekundy pracovat. Stejně pohodlně lze kdykoliv víko zavřít a uložit MacBook do tašky. Ne, nemusíte se bát jako u Windows, že vám bude topit na zádech, protože se začal instalovat update nebo "aplikace xxx neodpovídá" a počítač se nevypl. Přesto co se týče MacBooku, určité výhrady mám. Jestliže je MacBook pro esteticky laděné jedince, jak mohl Apple dopustit přítomnost pouze dvou Thunderbold portů? Je přeci jasné, že každý k němu bude mít připojený hnusně zející adaptér. Konektorová výbava je naprostý výsměch modernímu světu. Další výtku bych měl k chlazení MacBooku. Za normálních okolností je totiž MacBook zcela tichý a nemáte šanci ani poznat, že je zapnutý. Jakmile ale začnete MacBook zatěžovat (v mém případě asi 5 z 8 hodin), stane se z něj nejhlučnější stroj na této planetě, který dost možná odfoukne i vašeho kolegu sedícího na druhé straně místnosti. Nepříjemné jsou co se designu týče i hrany notebooku, o které si člověk div nepořeže ruce.
Vývoj webových aplikací v macOS
Protože jsem zaháčkovaný na .NET platformě, je pro mě důležité být schopen vyvíjet webové aplikace postavené na .NET Frameworku. Ke štěstí potřebuji jednak dobré vývojářské prostředí a druhak samotný .NET Framework. Vzhledem k tomu, že .NET Core je multiplatformní, předpokládal jsem, že přesedlání na macOS by mohlo být jednoduché. Ale pojďme popořadě.
Vývojářská IDE
Pro vývoj .NET aplikací na Mac existují v současné době 3 významnější hráči a pak sada alternativ, které nebudu zmiňovat. Tradiční Visual Studio pro Windows není pro macOS k dispozici, tudíž je otázka volby IDE docela důležitá a nejde odbýt tím, že bych automaticky použil ten nejsofistikovanější nástroj na planetě.
JetBrains Rider
Zřejmě nejlepším IDE je prostředí Rider od JetBrains, které poslední měsíce používám experimentálně i na Windows. Ačkoliv je nástroj placený, poskytuje přibližně stejný arzenál funkcí jako Visual Studio s Resharperem. Resharper je totiž integrován do IDE a velmi výrazně zpříjemňuje vývoj aplikací. Rider má výtečnou podporu verzovacích nástrojů, front-endu, je rychlý a podporuje většinu typů aplikací napsaných v .NETu. Na rozdíl od dospělého Visual Studia na Windows mu sice chybí tooling kolem Azure, na druhou stranu zde nechybí podpora VSTS, TFS, GITu, Mercurial, SVN, integrace s Dockerem a další užitečnosti. I když vývoj aplikací v Rideru mi nečiní větší potíže, občas narazím na nějaký drobný problém, který by mě za normálních okolností ve VS neobtěžoval.
Visual Studio for Mac
V první řadě se nejedná o klasické Visual Studio jak jej známe z Windows. VS for Mac je zcela odlišný produkt (v podstatě rebrandované Xamarin Studio), který umožňuje vývoj (ASP).NET Core aplikací, aplikací pro macOS a mobilních aplikací. Pro vývoj poskytuje dostatek komfortu, intellisense a všechny běžné vymoženosti, které vývojář potřebuje k životu. Pro člověka přecházejícího z Windows a Visual Studia však působí bez dodatečných nastavení neohrabaně a neintuitivně. Ty funkce tam jsou, jen je těžké je uchopit. V praxi je například nutné vybrat si jedno schéma klávesových zkratek a to následně přizpůsobit svým potřebám. Pro vývojáře používající VS Code je příjemné, že je k dispozici stejné schéma. Oproti Rideru nabízí i drobný tooling kolem Azure, takže lze například publikovat aplikace do App Service nebo snadněji psát Azure Functions. Podporuje rozšíření, která průběžně přibývají a nabízí lepší práci s NuGet balíčky, konverze PCL na .NET Standard 2.0 a plno dalšího. Mně osobně chybí nejvíce funkce "Go To Implementation" a vestavěný terminál.
Visual Studio Code
Třetí hráč zaujme především front-end vývojáře, kteří sice do styku s ASP.NET Core přijdou, není to však jejich denní chléb. VS Code podporuje rozšíření, díky kterým je možné vyvíjet (ASP.NET) Core aplikace, jen už mi to osobně nepřijde jako vývojářské prostředí jako spíše inteligentní editor. Chybí zde velké množství toolingu, auto-discover při vývoji, podpora ASP.NET Core specifik (Razor), tooling kolem Azure, refaktoring, inteligentnější chování (například ctor TAB generuje balast) a intellisense nabízí nesmysly v porovnání s Riderem. Na druhou stranu VS Code nabízí vynikající rychlost, integraci GITu a jednoduchý debugger.
Shrneme-li si možnosti, jediná rozumná volba je pro vývoj .NET aplikací použít placený Rider, který je relativně schopen konkurovat klasickému Visual Studiu, které známe z Windows.
Vývoj .NET aplikací
Od IDE se přesuňme k samotnému vývoji webových aplikací. Uvažovat lze nad třemi oblastmi:
- Vývoj ASP.NET Core aplikací nad .NET Core a .NET Core obecně
- Vývoj ASP.NET Core aplikací nad tradičním .NET Frameworkem
- Vývoj toho ostatního (WinForms, WCF, WPF)
Vývoj ASP.NET Core a .NET Core
V případě ASP.NET Core aplikací běžících nad .NET Core nebo .NET Core aplikací má vývojář k dispozici podporu všeho, co je v NET Standardu. Záměrně tu zmiňuji .NET Standard, protože samotný .NET Core je multiplatformní jen do určité míry. Některá API jsou dostupná jen pro systém Windows a v budoucnu se dá předpokládat, že takových specifických API bude více. Pokud mě tedy nelimituje .NET Standard jako takový, mohu bez problému psát aplikaci bez jakýchkoliv omezení. V reálném životě a světě webového vývoje se s takovými aplikacemi vývojář zatím moc nesetká. Když už někdo píše ASP.NET Core aplikaci, většinou ji totiž targetuje na tradiční .NET Framework (viz. druhá možnost níže). Využití tohoto stacku tak zatím spíše zůstává vhodné pro menší projekty, osobní aplikace, malé webové zakázky, mikroslužby nebo dema na přednáškách.
Vývoj ASP.NET Core nad tradičním .NET Frameworkem
Tím se dostáváme ke stacku, který je aktuální pro současné webové projekty a vzhledem k pesimismu vývojářů i pro mnoho projektů nově vznikajících. Jedná se o vývoj aplikací nad novým ASP.NET Core frameworkem verze 2.0+ targetovaným na tradiční .NET Framework (4.6+). Suplovat .NET Framework musí v takovém případě na MacOS / Linux tzv. Mono.
Mono 5.4 již sice implementuje .NET Standard 2.0, v praxi to však nestačí k tomu, aby bylo plně použitelné pro plnohodnotný vývoj aplikací. Už samotný .NET Standard 2.0 mnoho 3rd party knihoven nesplňuje a targetuje na staré verze .NET Frameworku. Přinutit k poslušnosti například klasický Entity Framework je peklo na zemi. Logicky vzato není ideální ani myšlenka vyvíjet nad Mono frameworkem aplikace pro zákazníky, kteří hodlají hotovou aplikaci hostovat na Windows serveru nad .NET Frameworkem.
Vývoj tradičních .NET aplikací
A pak tu jsou tradiční .NET aplikace, kterými mám na mysli například WinForms, WPF, WCF nebo klasické ASP.NET Web Forms / MVC aplikace, které běží nad tradičním .NET Frameworkem. Tady má vývojář absolutní smůlu a to i s výhledem na budoucí .NET Core 3.0, který sice bude podporovat WinForms a WPF, ale pouze na platformě Windows.
Jak tedy z popisu všech tří možností vyplývá, vývoj webových .NET aplikací přímo na macOS je utopie, v lepším případě hudba velmi vzdálené budoucnosti nebo spíše paralelního vesmíru. Aby to však nebylo málo, pojďme se podívat na další aplikace.
Další aplikace pro vývoj
Pokud máte totiž ambice zůstat u moderních technologií, nejlépe kombinace ASP.NET Core nad .NET Core, pak stále zbývá dořešit podporu souvisejících aplikací pro vývoj.
SQL Server
Samozřejmě největší výzva je zajistit aplikacím podporu SQL Serveru. Aktuálně jediné rozumné řešení, které jsem našel a funguje velmi dobře je varianta Docker + SQL Server on Linux. Instalace je otázkou pár minut a pro běžnou práci je SQL Server on Linux dostačující. Popis jak tuto mašinérii uvést do pohybu popisuji ve samostatném článku. Je třeba si uvědomit, že virtualizace sežere značnou část výkonu počítače, což zrovna macBooku dokáže pořádně roztočit větráky.
Management SQL Serveru
Dále potřebuje vývojář managovat lokální SQL Server, vzdálený server nebo SQL databázi na Azure. Na počítačích s Windows toto kompletně splňuje SQL Server Management Studio. V případě MacOS je k dispozici zdarma nástroj SQL Operations Studio, který je mimořádně pomalý a neskutečně nešetrný na množství spotřebované operační paměti. Lepší alternativou je SQLPro for MSSQL, který však stejně jako první zmíněný nabízí jen základní množinu funkcí pro správu databáze. Jediné z mého pohledu dobré řešení je opět Rider od JetBrains, který má vestavěný Database Explorer + na exekuční plány použít SQL Operations Studio. Pořád se ale bavíme o dost slabých alternativách v porovnání s SSMS. Chcete-li například profilovat dotazy pomocí SQL Server Profileru, máte smůlu.
Redis, Memcached atd.
V případě Redis a Memcached je situace velmi dobrá. S nainstalovaným správcem balíčků Homebrew stačí jedním příkazem nainstalovat Redis nebo Memcached. Kdo si nevystačí s CLI, má k dispozici různá GUI, například Fasto Redis.
Azure Storage Explorer
Zde je situace příznivá, existuje stejná aplikace pro MacOS jako pro Windows poskytující stejné funkce i rozhraní.
Azure Storage Emulator
Oficiální aplikace neexistuje a osobně bych to asi řešil testovacím účtem přímo na Azure. Zatím jsem emulátor nepotřeboval.
Front-endové nástroje
Není o čem, absolutně všechno co jsem zkoušel funguje jako víno. Front-end vývojáři mohou počítače s Windows rozsekat do posledního tranzistoru.
Specializované nástroje
V případě intenzivnějšího vývoje .NET aplikací jsou často potřeba různé memory profilery, nástroje pro debugging, profilování SQL dotazů atd. A tady sranda definitivně končí, protože v současné době na platformě macOS téměř žádné specializované nástroje neexistují.
Virtualizace a RDP
Když to všechno shrneme, macOS je absolutně nevhodný systém pro .NET vývojáře, kteří by chtěli využít možnosti samotného systému. Zítřky jsou sice docela světlé (narážím na .NET Core), nicméně technologie dneška a údržba legacy systémů je s macOS neslučitelná. Většina vývojářů tak nakonec sáhne po virtualizaci a rozjede si Windows například v Parallels.
Virtualizace může být díky Coherence režimu příjemná v tom smyslu, že Visual Studio nebo SSMS se tváří jako samostatná aplikace včleněná do macOS (Windows si šlape na pozadí) avšak už v základu se jedná o přístup náročný na systémové prostředky. Ve chvíli, kdy je vývojář nucen používat paralelně například SSMS a Visual Studio se práce radikálně zpomaluje, MacBook začíná hučet jako turbína a s připočtením swapování mezi dvěma systémy s odlišným ovládáním jde produktivita výrazně dolů. Každý systém má svou vlastní klávesnici, která se od té druhé výrazně liší a v každém systému fungují odlišné klávesové zkratky až na úroveň 3rd party software (například Google Chrome). Chcete-li prodloužit stroji život, neusmažit si ruce o hliník a použít RDP, najednou se systémy od sebe o další krok vzdalují a vzniká nepříjemná závislost na konektivitě. Pokud nainstalujete Windows přes bootcamp jako druhý systém, absolutně tak zabijete smysl macOS, nehledě na to, že Windows na MacBooku fungují velmi zvláštním způsobem (v tom špatném slova smyslu).
Dovolím si tedy hluboce povzdechnout nad tím, že svět .NETu byl dlouhou dobu izolován alternativním platformám a současný technologický stack si prochází teprve jakousi pubertou v novém prostředí, které není na příchod velikána zatím připraveno.
Závěr
Po dvou měsících testování s politováním docházím k závěru, že macOS je po všech stránkách systém nepoužitelný pro průmyslový a efektivní vývoj .NET aplikací. Paralelní běh dvou systémů vyžaduje vysoké hardwarové nároky, MacBook se stává hlučným krámem a produktivita práce je výrazně narušena neslučitelným chováním dvou operačních systémů. V současné době se vracím primárně k mému Thinkpadu 13 s tím, že na MacBook sáhnu občas za účelem nějakých .NET experimentů.
Extras: co jsem do článku nezakomponoval
Článek jsem sepsal na základě řady poznámek, které jsem si vytvořil. Některé jsem do článku nezakomponoval, protože nejsou tak podstatné, nicméně proč je nezmínit na samotný konec:
Obecné poznámky
- připojení myši přes redukci = 4 cm trčí ven z MacBooku
- česká klávesnice na MacBook a v parallels se liší některými tlačítky
- sjednocení klávesnic možné vytvořením custom klávesnice v macOS
- problém custom klávesnice v macOS - v RDP není podpora, nejde otočit ctrl/cmd
- scrollování opačné u myši, u win, u touchpadu - srovnání pomocí aplikace Scroll Reverese
Práce s Windows v bootcampu
- klávesy ALT a WIN jsou otočené
- touchpad funguje podivně, klikání jen někdy, velmi problematické
- scrollování opět opačné (nepřirozené)
- nefungují žádná gesta na touchpadu - ani ta, co jindy jdou na Thinkpadu (precision)
- zamčené windows = absolutní přetížení, větrák naplno, zřejmě běží indexace čehosi
- rozlišení displeje není pro mě úplně ideální - screencasting, youtube, standard je 16:9
- chybí klávesy END a HOME, v macOS se to supluje CTRL + šipka, ve Win není řešení
- nefunguje DELETE
- display občas problikne a změní jakoby barevnou teplotu
- Windows v bootcampu mě nutí instalovat znovu všechen software, co mám i na macOS
- připojení více monitorů problematické, občas se jeden úplně vypne (problém adaptéru to není, ověřeno)
- nemám PrtSc, v macOS na to je zase zkratka, nutnost donastavení jiné obskurní zkratky
- zkouším Win aplikaci lístečky, absolutní shit, většina textu mizí při psaní pod rukama
Macbook a macOS, poznámky při práci
- rider pro vývoj dost problematický, stále přeskládává layout, náhodně nefunguje build projektu
- skvělý displej, velmi dobře se píše na klávesnici
- občas hučí, prakticky bezdůvodně (kopírování souborů, instalace sw atd.)
- zlobí synchronizace s iphone, sms se nejednou nechtějí zorazovat v macBooku
- každou chvíli zapomenu adaptér nebo nějakou redukci (kterou přirozeně široko daleko nikdo nemá)
- připojení vlastní klávesnice je šílenost, zase otočené znaky, zase všechno jinak
- google drive od počátku chybuje, zobrazuje se dvakrát, nefungují tagy ve Finderu v google file stream
- google file stream se odhlašuje (opruz opakovaného přihlašování speciálně u 2 faktor auth)
- nutnost migrace OneNote bloků do online, nepodpora lokálních files
- větší OneNote bloky se mi neotevírají (nekonečná synchronizace)
- po 2 měsících si nezvykám na finder, divné chování enter, delete, create folderů a files
- neexistuje dobrá alternativa k total commander, ani v případě DCommander
- velikost parallels roste závratnou rychlostí, jsem na 70 GB