Za těch zhruba dvacet let co programuju jsem si osedlal už ledacos - rozkoukával jsem se někdy v pravěku v Basicu a Logu na osmibitech, pod lavicí četl komentovaný výpis disassamblované romky Atari 800, hádal se, jestli je lepší Atari nebo Commodore, přiživoval se programováním ve FoxBase (a s oblibou měnil jejich reklamu "nic neběží tak jako liška" na "nic nekličkuje jako liška"), napsal bambilión řádků zdrojáků v céčku na Amize, v DOSu i všech Windows od Win3.11 až po současnost; prošel javou i .netem; programoval pro maličké zákazníky i seděl přes rok ve vývojovém centru velké telekomunikační korporace, kde jsem dělal na systémech velkých a složitých jak smečka přerostlých mamutů, cítil se jako nejlepší coder na světě i jako naprostá lama.
Prostě programátorský dinosaurus :-)
Ze všech vývojářských prací které jsem ozkoušel mne ale pořád nejvíc baví motat se kolem vývoje .NETových komponent a piplání webu s jejich prezentací.
Proč když vývoj komponent je jen pro silné povahy?
Aki neustál nároky kladené na vývojáře komponent...
Co je na vývoji komponent tak neobvyklé? Čím to, že mne to nepřestává bavit? Kouzlo nového v tom nejspíš nebude - první komponentu jsme vypustili před šesti lety. A přitom je vývoj komponent něco hrozného. Posuďte sami:
Programátoři jako klienti
Mít za klienty programátory je děsná řehole. Na codery nefungují výmluvy jako "tohle počítače neumějí", "to není chyba, takhle to funguje už tři roky, věřte mi; a starší verzi už nemám - na mou duši". Sice povětšinou používají mozek podobným způsobem jako vy (takže jim obvykle nemusíte vysvětlovat, že komponenta pro sshčkovou komunikaci funguje lépe když počítač připojíte k síti), ale má to i stinné stránky. Typický code warrior je totiž ve své schopnosti nebývale pyšný a vy musíte být po čertech dobří, aby vás uznávali a brali vaše rady vážně. A což teprve když ho musíte diplomaticky vyvést z nějakého fatálního omylu, o kterém je skálopevně přesvědčen. To už vyžaduje vysoká diplomatická studia. Žádná zašívárna. Nic nedostanete zadarmo, ale zase vás nutí se neustále zlepšovat. Na druhou stranu elegantní kód či neočekávaný trik ocení a patřičně komentují.
Nekonečné debaty o veřejném API a kvalitě kódu
Koho by to bavilo? Člověk by si občas chtěl ubastlit nějaký quick-and-dirty-hack a nechce se mu moc do hloubky řešit architekturu, hlavně ať je rychle hotov a může se vyrazit na oběd. Pokušení pojmenovávat proměnné vtipně naštěstí odolává už od doby, kdy mu jeden klient ze Švýcarska položil při code review záludnou otázku "One more question comes to my mind: what does this variable called "prdelka" mean?".
Ale kdo by se měl zabývat tím, jestli je kód nejen funkční, ale i krásný? Ten, kdo ponese příštích pár let důsledky toho, že případný refaktoring veřejného rozhraní znamená změnu v aplikacích pěkných pár stovek či tisíců programátorů kteří to API používají? Pak místo oběda následují debaty s kolegy, jestli je v tomhle případě lepší mít společného předka, nebo raději interface nebo jestli předka udělat pro jistotu abstraktního. A řešit, který ze tří možných názvů metody bude působit problémy nejmenšímu počtu uživatelů a vedle čeho se při intellisense bude ukazovat. Někdy si už říkám, ať mi s tím dají pokoj. Stejně tak jako s ukeceným FxCopem.
Mailová technická podpora a blogování
Většina supportových požadavků přichází mailem - prostě vám čas od času někdo předloží hádanku k vyřešení. Co lepšího může být pro grafomana? Budu přispívat do mailing listu, kasat se, jak jsem dobrý (a poprávu, protože o svých komponentách vím víc než kdokoliv jiný a když nevím, tak se zeptám kolegy který psal příslušnou část kódu) a ještě mne za to budou platit. Placený diskutér na něčem podobném Builderu nebo EMWACU - nezní to hezky? Zní. Ale občas ty hádanky začnou být pěkně zapeklité. Třeba když s klientem přijdete na to, že komunikace s jedním FTP/SSL serverem funguje krásně, jen když NEJSTE připojeni příliš rychlým drátem. Po pár desítkách minut s Wiresharkem zjistíte, že na ten server nesmíte mluvit příliš rychle, protože obsahuje drobnou chybku. Když totiž poslední dvě sekvence při navazování šifrovaného spojení přijdou v jediném paketu, tak se dotyčný server zakucká a druhou část odpovědi zahodí a vy musíte do komponenty přidat workaround, který na toho zvrhlíka mluví pro jistotu pomalu, jak na starou babičku. To by šlo, ale když narazíte u stejného FTP serveru během dvou let na pátou podobnou chybku, tak už vám začíná vrtat hlavou, proč ho vlastně někdo používá.
Kdyby to bylo jen to. Jindy někdo nahlásí chybu, kdy komponenta vrací zápornou délku souboru u serveru, který běží na nějaké IBMce. Po pár vyměněných mailech zjistíte, že server ... opravdu vrací zápornou velikost, protože mu někde něco přeteklo. Nebo klient z domény jedné americké vládní organizace, která má na homepage webu něco o tom, že "zajišťujeme národní bezpečnost vývojem a výrobou jaderných zbraní" reportuje, že se vaší komponentou nemůže připojit ke vzdálenému FTP serveru. Podrobným výzkumem zjistíte, že se připojuje ke stroji na kterém běží War FTP server, který uživatele připojené z domény .gov automaticky odmítá, protože (jak tvrdí jeho autor v FAQ):
"Version 1.7 does have these settings hardcoded, partly because governments sucks, and partly to demonstrate the feature.".
Dotaz z Bangalore, který je formulován v jazyce ne nepodobném angličtině, už přijmete s radostí. Ještě, že dotazy z technické podpory se dají použít jako inspirace pro návody do blogu nebo položky FAQu, takže na stejný dotaz nemusíte odpovídat stále dokola.
Vývoj pro .NET Compact Framework
Všechny (no dobrá, v současné době skoro všechny) komponenty vypouštíme pro všechny existující .NET i .NET Compact Frameworky. Desktopové frameworky nedělají výrazné problémy. Pro .NET 1.x stačí skoro vždy jen podmíněná kompilace a noční automatické buildy se postarají o zbytek. U .NET CF ovšem zlé jazyky tvrdí, že jde o platformu, která je jen tenkou obálkou kolem PlatformNotSupportedException. Je obdivuhodné, kolik funkcionality se do kapesních počítačů a .NET CF podařilo dostat. Stejně vás ale naštve, když zrovna ta funkce, kterou potřebujete v kapesním počítadle chybí. Značnou část bezpečnostní infrastruktury jsme si museli pro .NET CF implementovat sami. Nu - alespoň to bylo zajímavé a časem se z toho osamostatní separátní komponenta - už teď to obsahuje pár věcí, které nejsou ani v .NET 3.5.
Další úskalí jsou unit testy. Na desktopovém frameworku požíváme už roky klasický nunit. Pro .NET CF ale nic takového neexistuje. Záminka pro vlastní port nunitu pro netcf spojený s dispatcherem, který se stará o stádečko emulátorů kapesních počítačů, rozděluje jim práci a vrací výsledky unittestů sestavovacímu systému, je na světě. Implementace trvala kupodivu jen pár dní a jistě by ještě šla vylepšovat, ale i tak šetří neskutečné množství ruční práce. Kdyby se toho někdo chytil a dotáhnul to do publikovatelného stavu, dal by se ten port vypustit jako opensource, zatím ale dáváme energii jinam a tak tahle věc čeká na někoho nového.
Technické podmínky - xakru - už ani na tohle se nedá hudrat
Je třeba věnovat pozornost každému aspektu zabezpečení offsite záloh nočních buildů
Kde jsou ty časy, kdy člověk mohl hudrat na pomalý a nefukční počítač, kterému se nevejdou do paměti ani tři virtuální stroje. Typický komponentový vývojář v Rebexu má Dellí notebook Lattitude nejvyšší řady s hromadou paměti a nejrychlejším diskem co je k dostání, zhusta pro lepší umělecký dojem doplněný pořádným externím LCDéčkem. Debaty u recepce na hrozné pracovní podmínky v openspace odpadají, protože nemáme žádný openspace ale kanceláře v činžáku na Vinohradech s výhledem do udržované zahrady se psem a hrušní; kanceláře s bohatým výběrem blízkých hospod.
Na chybějící software se také hudrá blbě, protože předplatné MSDNka má samozřejmě každý, VS.NET v něm obsažený je nejlepší IDE široko daleko, místo SourceSafe máme Vault a pro bugtracking FogBugz - zatím nejlepší software tohoto typu co znám a že jsem jich vyzkoušel hromadu. Na tupý topmanagement který nerozumí potřebám programátorů se mi nadává také blbě, protože to bych musel nadávat sám sobě :-). Nezbývá tedy, než příležitostně hudrat na politiku a daně...
Co na to ostatní?
Ptal jsem se svých kolegů, se kterými v Rebexu vyvíjíme komunikační komponenty pro .NET a .NET CF, co je na jejich práci nejvíc baví a co je nejvíc štve.
| Top Good |
Top Fuj |
| Kontakt s klientama - programátorama. Chválení docela potěší. |
Bambilión nutných unittestů |
| Je dost času dělat to nejlepší coderské řemeslo co umíme - konec šibeničním lhůtám vývoje na míru |
Nemilosrdný build server |
| Zajímavé související projekty - třeba port nunitu pro .NET CF |
Indičtí programátoři (přinejmenším někteří) |
| Stádečko zelených semaforků v ccnet |
Klienti, kterým něco nefunguje na .NET Compact Frameworku |
"Tak si to zkus sám, dyž seš tak chytrej!"
Ještě tu někdo zůstal? Někdo, koho jsem neodradil? Někdo, kdo by si to chtěl dokonce zkusit? Neuvěřitelné, a já se tolik snažil :-)
Právě teď máte příležitost - hledáme posily do týmu pro vývoj komponent. Máme na příští rok či dva docela zajímavé plány a potřebujeme pomoc s jejich realizací... Ze zkušenosti vím, že software světové kvality se dělá nejen v Redmondu či Silicon Valley ale i v české kotlině, a vy můžete být u toho. Zkušené veterány uvítáme, těm méně okoralým dáme prostor k růstu a dostatek tréningového materiálu. Říká se, že klidné vlny nevychovají dobré námořníky. Něco na tom bude. Pokud máte zájem o solidní vlnobití tak se mi ozvěte na mail: martin.vobr@rebex.cz