To neprojde...

Taková malinkatá celebritka mezi .NET vývojáři Jeff Atwood se rozhodl, že si na svůj blog vpustí reklamu a zisky z ní utratí na sponzorování open source (OSS) projektů vyvinutých pro .NET (viz Supporting Open Source Projects in the Microsoft Ecosystem. Vcelku nic moc zajímavého.

Zajímavé jsou ale některé komentáře pod jeho textem. Třeba ten od Franse Bouma:

In fact, the whole MS platform eco system isn't suitable for open source tools to become very effective. As soon as they do, MS will come with an equivalent, and what's worse: large droves of developers don't even know how to spell open source, left alone that they're even looking for open source projects, they simply look at Redmond and wait till MS comes with something.

In the Java community, things are completely the opposite. The whole eco-system around Java is simply build on top of the open source model: libraries and tools are very often free and open source. The business model of java oriented companies is build around providing services, not by selling licenses. On the MS platform this is the opposite.

Vcelku s tímto popisem situace souhlasím. Také používám (soukromě i pracovně) několik OSS produktů, jako je třeba MbUnit (na kterou jsem přešel z NUnit, protože MbUnit má spoustu sexy vlastností, které NUnit nemá), nebo ZedGraph (vážně lepší než drtivá většina placených komponet pro kreslení grafů, distribuovaná pod LGPL), nebo #ziplib (a asi i další).

Nicméně je fakt, že většina těchto komponent dříve nebo později dojde do situace, kdy si Microsoft všimne, že mu někdo loupe perníček, a buď si koupí (rozuměj zaměstná) přímo vývojáře té které komponenty, nebo vymyslí něco vlastního, skoro stejného, ale ne tak úplně kompatibilního, a přibalí to k Visual Studiu, nebo to vydá jako nějakou zdarma stažitelnou komponentu, na což vývojáři většinou reagují tak, že převedou své aplikace na věci od Microsoftu. Podívejte, jak nepotřebné jsou k Visual Studiu přibalené Crystal Reports od doby, kdy Microsoft distribuuje svůj vlastní ReportViewer (pro jednoduché reporty, samozřejmě).

Já to Microsoftu nezazlívám: je to firma, jejímž cílem je znásobovat investice do ní vložené, která potřebuje růst na trhy na kterých zatím není a tak dále. Microsoft je trochu jako hypermarket: všechno co potřebujete byste měli najít pod jednous třechou, aby vás ani nenapadlo dívat se jinam. Na druhou stranu se pak nemůže nikdo divit, že některé lidi takový přístup znechutí, a že začnou raději věnovat něčamu jinému než je .NET. Něčemu, co jim přinese nehynoucí slávu a uznání, a ne jen temný kout v domě zapomnění.

Říkám si: v čem je ten rozdíl, mezi vývojáři opravdového OSS, kteří se věnují Javě, nebo Ruby, nebo něčemu podobně zajímavému, a vývojáři kteří se spokojeně rochní v teplé náruči Microsoftu?

Napadlo mě tohle: zatímco všichni ti opravdoví OSS vývojáři tělem i duší, sní o tom, že jejich produkt (jeden z mnoha ve stejné kategorii na Sourceforge) napraví svět a tak dále, a že když budou dost dobří, tak je nakonec zaměstná Google nebo nějaká podobně trendy firma, snem vývojářů pro Windows (nebo platformy Microsotu obecně) je opustit řeholi zaměstnání, stát se nejprve MicroISV a pak třeba i regulérním ISV (tedy že naberou zaměstnance, kteří budou makat za ně). Rozdíl je totiž v tom, že zatímco pro osvědčené OSS platformy (Linux, Java, atp.) jsou věci zadarmo, pro ty, co se tak či onak spolčili s Microsoftem je naopak normální za věci platit. Takže stačí, když vyvinete nějakou sadu dostatečně kulatých a gradientních tlačítek, vyrobíte si stránku, zaspamujete pár diskusních fór (nebo nabídnete svůj "produkt" pro nekomerční využití zdarma), a díky té mase vývojářů se docela slušně uživíte.

Jistě OSS produkty se živí službami. Ale množství počátečního kapitálu a výše rizika pro zaběhnutí produktu založeného na službě jsou úplně jinde než u balíku ovládacích prvků, který lze vyvinout poměrně dobře i u práce (dokonce i když máte rodinu) a riziko je vcelku nulové.

Chci tím říct: myslím si, že lidem, kteří obcují s produkty Microsoftu současný stav vcelku vyhovuje. Dává jim totiž naději, že jednoho dne budou pracovat na svém, a že zvyk Microsoftích nohsledů nakupovat licence, jim umožní zbavit se jha práce pro někoho jiného. To, že v okamžiku, kdy se stanou příliš úspěšnými, vrhne Microsoft na stejné pole několik set ze svých tisíců vývojářů, kteří je o jejich malý kšeft zase připraví, je nevzrušuje, protože se ukájejí tím, co tvrdí Paul Graham a Tim O'Reilly: totiž že jsou pod radarem, že na ně není vidět, že jim se něco takového prostě nemůže stát.

Proto si myslím, že podporovat finančně OSS projekty pro .NET je jen takové plácnutí do vody, které stejně nikam nepovede. Aby to bylo k něčemu, musel by se změnit přístup Microsoftu, a to se nestane, protože Microsoft potřebuje růst a nemůže si dovolit, aby místo, kam by se mohl natlačit on sám, zabírala nějaká pochybná skupinka předstírající filantropii, či co.

Tak tohle mě napadlo.

Flyboy

Já vím, já vím. Ještě před nedávnem jsem tu lkal nad nedostatkem inovací vycházejících z Microsoftu (a taky jsem se zařekl, že nebudu jejich hlásnou troubou, když už mi to BVer vyčetl) a teď tohle. Pardon, tohle.

Prohlédl jsem si screencast v sekci Overview, a na to, že celá ta věc běží v prohlížeči, je to dost zajímavé.

Nicméně nějak se nemůžu přinutit Popfly vyzkoušet osobně, protože to vyžaduje Windows Live Id. A posledně, když jsem si generoval Live Id (které jsem už samozřejmě zapomněl), přesměrovávaly mě microsoftí servery od čerta k ďáblu, a potvrzoval jsem několik nechutně dlouhých licenčních ujednání, či čeho.

Nevím, jestli seberu odvahu pustit se do něčeho takového podruhé.

Chtěl jsem říct: takhle je to s Microsoftem u všeho...

WT^hPF

Tak. Tímto textem bych chtěl na nějakou dobu uzavřít diskusi o Microsoftu, Apple a podobných věcech.

Když teď nedávno Microsoft přejmenoval WPF/E na Silverlight, a všichni bloggeři se kolem této události začali rojit s tím, jestli Silverlight převálcuje Flash nebo ne, také jsem cítil potřebu se k tomu nějak vyjádřit. Nakonec jsem se rozhodl to neudělat, protože je podle mě na nějaké hodnocení brzo. Jednak Microsoft chystá ještě nějaké šokantní oznámení (bude Silverlight open-source? Tak ta velká novina je platformě nezávislá implementace CLR pro prohlížeče.), jednak mě vývoj webových aplikací tak úplně nezajímá. (Nicméně jsem chtěl poznamenat, že už delší dobu si myslím, že Apollo je ten Next Big Language, o kterém mluví Steve Yegge. Beru zpět. Teď myslím, že myslel JavaFX.)

Nicméně jsem se chtěl otřít o WPF, kterou se teď snažím nějak sestudovat (samozřejmě to jde pomalu, ale snažím se). Takže co je to WPF? Windows Presentation Foundation. (Pokud jde o mě, klidně bych celou tu věc pojmenoval Avalon i oficiálně, ne jen krycím jménem, ale jak známo, pojmenovávání věcí v Microsoftu je sofistikovaný proces, který vyústí v použití slova Microsoft nebo Windows v názvu, ať to zní jakkoliv pitomě -- tedy kromě sady programů Expression, které se, nějakým záhadným způsobem, tomuto jevu vyhnuly.) Pokud jste tenhle pojem ještě neslyšeli, určitě si přečtěte článek Windows Vista: more than just a pretty face, který poskytuje velmi slušný úvod do problematiky.

Takže ještě jednou: co je to WPF? Podívejte, všichni víme, že GDI(+), je zastaralá záležitost, že ji Microsoft držel při životě především proto, že si nechtěl utnout kus trhu s kancelářskými počítači, ve kterých ještě donedávna byly opravdu hloupé integrované grafické čipy, které neuměly nic, než převést kus operační paměti na analogové úrovně na D-SUB konektoru. Ovšem, doba se změnila, a i ten nejhorší integrovaný grafický čip dneska disponuje nějakou tou 2D/3D akcelerací, kterou je velká škoda nevyužít.

Takže se Microsoft rozhodl, že ve Windows Vista, bude 3D akcelerace tak nějak vyžadována, a že na ní bude postaveno celé zobrazování systému. A jelikož perspektivním vývojovým prostředím je .NET, vznikl .NET Framework 3.0 (který by ve skutečnosti spíše měl mít číslo 2.5, ale přeci nelze nový nablýskaný operační systém distribuovat s nějakou polovičatou verzí frameworku), který obsahuje, mimo jiné, WPF.

WPF je především prostředek, jak co nejvíce oddělit uživatelské rozhraní aplikace od výkonného kódu, a to tak, že uživatelské rozhraní bude definováno pomocí XML, respektive jeho "dialektu" XAML, který umožňuje popsat UI do takové hloubky, že pro řadu jednoduchých aplikací opravdu není potřeba psát skoro žádný kód (vážně -- poměrně sofistikovaný textový editor vygenerujete pomocí prvku System.Windows.Controls.RichTextBox a nějaké té bižuterie, s použitím asi 50 řádků kódu, které se starají o uložení a tisk dokumentu).

Kromě onoho zřejmého požadavku na oddělení kódu a uživatelského rozhraní z důvodu znovupoužitelnosti obého, je tu ještě bonusová možnost nechat nějakého grafika pracovat na rozhraní v poměrně sofistikovaném programu Expression Blend bez toho, aby něco věděl o programování (samozřejmě musí něco vědět o aplikaci a její struktuře, ale nemusí být seznámen s její vnitřní mechanikou). Také lze takový popis uživatelského rozhraní v XAML snadno vyměnit za jiný (třeba podle velikosti displeje, zvoleného režimu funkce programu, nebo cílové platformy).

WPF tedy umožňuje rozdělit vývoj logiky programu a jeho prezentační vrsty jak je to jen možné.

Současně s tím ovšem nabízí velmi vypečený způsob jak se zbavit všech těch problémů, které vznikají se stále rostoucím rozlišením displejů (písmenka jsou příliš malá!), nebo potřeby předělávat uživatelské rozhraní pokaždé, když program lokalizujete do nového jazyka, který místo textu o šesti znacích potřebuje znaků dvacet, protože všechny souřadnice jsou relativní a při změně velikosti ovládacího prvku, nebo okna, se umí dobře přizpůsobit novým podmínkám.

Dále je tu hierarchičnost prvků uživatelského rozhraní. Ve WinForms (tedy rozhraní, které používá GDI ve Windows do verze XP bez WPF), jste museli podstoupit bolestivý proces vlastního vykreslování, když jste chtěli do tlačítka dostat obrázek nebo dva řádky textu. S WPF napíšete něco ve smyslu <tlačíko pozadí="obrázek"><popiska text="hlavní"/><popiska text="vedlejší"/></tlačíko> a je to! A samozřejmě můžete definovat co se stane, když nad tlačítkem bude myš, včetně různých animací.

Čili variabilita je o několik řádů dál, než s použitím WinForms a GDI (a to vás nechci zdržovat básněním o tom, že takové tlačítko můžete namapovat na libovolný 3D povrch, takže pak můžete vytvářet skoro stejně sexy uživatelská rozhraní jaká používají Hollywoodské trháky).

Nějaké nevýhody? Ó jistě: použití WPF znamená, že se vaše aplikace na starších počítačích (řekněme starší než tři roky) zpomalí zhruba dvakrát (především na Windows XP je to hodně znát). A dále: dokud nevyjde nové Visual Studio (kódové označení Orcas, v současné době ve stádiu Beta 1), neexistuje nějaký spolehlivý nástroj, ve kterém by se dalo s WPF pracovat. Existují sice nějaká rozšíření Visual Studia 2005, ale věřte mi, pořád bude řešit nějaká neopodstatněná varování, IntelliSense funguje jen částečně a tak dále. Expression Blend už by měl být ve stavu RTM (Release To Market), ale jde o placený nástroj, a věřte, že XAML není myšleno jako jazyk, který budete psát ručně (i když leckdy nic jiného nezbývá).

Sečteno podtrženo: WPF je skvělá věc, která ovšem pro produkční aplikaci bude zajímavá někdy v půlce příštího roku, až budou všechny nástroje připraveny a penetrace Windows Vista dosáhne nějaké smysluplné úrovně.

Kde jsem to začal? Aha, Silverlight (podmnožina WPF) versus Flash. Upřímně: když jsem se tak díval na vývoj jmenných prostorů v .NET frameworku, domnívám se, že v Microsoftu opravdu existuje nějaký grand plan, ve kterém se dříve nebo později objevuje lehkotonážní managed framework pro prohlížeče -- to znamená, že bude notně ořezaný, třeba jako Compact .NET Framework (PDA a smartphones) nebo XNA Framework (XBox 360), ale nebudete muset stahovat 60MB záplat, které vám umožní jej provozovat, který umožní vyvíjet pro prohlížeče v C#, nebo jiném .NET kompatibilním jazyku.

Jak pak bude vypadat sronání Flash/Apollo a Silverlight/.NET? Který z těchto balíků zvítězí? Myslím si, že ten, který bude nabízet více zajímavých aplikací. Pokud Google začně vyvíjet v Appolo (což by se náramě hodilo třeba pro GMail, který by mohl stažené e-maily skladovat lokálně a odesílat odpovědi až se obnoví připojení k Internetu) a bude Flash aplikace tlačit svým zákazníkům, bude pozice Microsoftu jistě mnohem horší. Pokud se něco zlomí v Microsoftu a začne vyvíjet věci dost zajímavé na to, aby uživatelé počkali těch několik sekund než se stáhne pár mega Silverlight (nebo jej budou distribuovat jako doporučenou aktualizaci Windows), není výsledek vůbec jistý.

V každém případě bude pár následujích měsíců zajímavých. Uvidíme, jestli strategie vnucování se na obsazený trh skrze Windows Microsoftu tentokrát vyjde nebo ne.

Pokud ne, má pravdu Paul Graham, a Microsoft už je opravdu mimo mísu, ať má finanční výsledky jekékoliv.

PS: A ještě bych si dovolil doporučit vaší pozornosti starší podcast s Robertem Scoblem, který přináší mnoho zajímavých poznámek k tomu, jak funguje Microsoft uvnitř.

PPS: Ta věc s grafickými kartami mi připoměla, proč je dobré mít managed framework běžící na virtuálním stroji. Představte si, že Microsoft portuje CLR (Common Language Runtime, tedy virtuální stroj, na kterém běží .NET aplikace) na grafické procesory, takže aplikace mohou běžet paralelně nejen na hlavním procesoru (procesorech) vašeho počítače, ale i, na jinak zahálejícím, GPU...

Kakao

Před časem jsem tu hovořil o společnosti Apple. Jelikož jsem tehdy neměl čas udělat si domácí úkoly pořádně, a ověřit si co by bylo záhodno ověřit, snažil jsem tyhle resty dohnat a podívat se především na Cocoa a Objective-C, abych tak trochu věděl jak vlastně vypadají.

Takže po krátkém zkoumání musím uznat, že Cocoa je opravdu pěkně navržená. Je to objektově orientovaný framework se vším všudy, vypadá docela konzistentně a když si na něj člověk zvykne a trochu ho sestuduje, určitě se v něm dobře pracuje (což je nakonec vlastnost všech slušně navržených frameworků). Oproti tomu Objective-C není úplně můj šálek čaje, a i když všechny ty věci se zprávami okoukané ze Smalltalku vypadají docela rozumně, není to syntaxe, která by mě nějak oslovila. Sympatické je, že do definic uživatelského rozhraní se nedá psát kód (jak je dobrým zvykem všech programátorů ve Visual Basicu), ale jen se připojují objekty, do kterých se pak nasměrují příslušné zprávy (jako že uživatel někam kliknul myší a tak podobně). A pokud tomu dobře rozumím, tak k Mac OS X se dodává zdarma vývojové prostředí Xcode, která rovněž vypadá (pro člověka odkojeného Visual Studiem) zajímavě.

Prostě se zdá, že vývoj pro Mac OS X je docela příjemná záležitost.

Přemýšlel jsem: proč vlastně Microsoftu trvalo tak dlouho, dát dohromady slušný vývojový rámec (myslím .NET), když na Macu existuje (sice ne managed, ale objektový) takový rámec už drahně let? Ano, tušíte správně, jde o to, že zatímco Microsoft se koncem osmdesátých a začátkem devadesátých let bahnil na platformě PC, Jobs, odejitý z Apple, založil firmu na luxusní pracovní stanice NeXT, ve které si mohl dovolit navrhnout takový počítač, že vedle něj tehdejší PC vypadaly jako chudý příbuzný.

Dalším problémem je zpětná kompatibilita. Microsoft je jí posedlý, a je fakt, že když jedno procento zákazníků, kterým přestane něco fungovat proto, že jste porušili kompatibilitu s předchozí verzí, je nějakých 10 miliónů lidí, tak není snadné něco měnit. Poučné jsou v tomto ohledu texty Raymonda Chena (ano, to je ten, nad jehož příspěvkem o [ne]kompatibilitě SMB jsme tu před časem diskutovali), který se snaží vysvětlit, že někdy se chyba změní ve vlastnost, protože programátoři jsou čuňata, a chybu nelze opravit, protože na ní spoléhá příliš mnoho lidí.

Dobrá, to vysvětluje, proč je Win32 API takové jaké je (14000, slovy čtrnáct tisíc funkcí), ale nevysvětluje to, proč MFC (Microsoft Foundation Classes, tedy, vulgárně řečeno, objektový obal kolem Win32 API) musely být, ve srovnání s Cocoa, takový hnus. Asi by se daly najít nějaké argumenty ohledně výkonu, dědictví operačního systému založeného na zprávách, a tak dále, ale opravdu neznám nikoho, kdo by si pochvaloval jak dobře je to MFC vymyšleno, a jak dobře se v něm pracuje (tedy kromě třídy CString, ta se docela povedla).

Nicméně. Nicméně jsem chtěl říct, že další zajímavé materiály ke studiu lze nalézt na CocoaLab, nebo na stránce věnované historii Apple Orchard (to je opravdu zajímavé čtení -- jakkoliv nevím na kolik validní; třeba texty o Pixaru a NeXTu jsou vážně poučné).

Tak pěkné čtení...

Trocha poctivé demagogie

Takže další kolo. (Než se pustíte do dalšího čtení, doporučuji vaší pozornosti poměrně zajímavý komentář uživatele Q, který jste třeba přehlédli.)

Problém s celou věcí je v tom, že naprostá většina lidí se otázkám, v nichž nějak figuruje Microsoft, nedokáže vyhnout zpolitizování věci, a tak, místo abychom se tu bavili o tom, jak obecně přistupovat k podobnému druhu chyb, kterým se někdy prostě nedá vyhnout, a může se s nimi setkat každý vývojář, řešíme nějaké zbytečné spory ve smyslu katedrála vs bazar, uzavřený vs otevřený, Microsoft vs Samba. Uznávám, mám na tom svůj díl viny, protože jsem si nedokázal odpustit trochu té infantilní jedovatosti (a protože je mi bližší Joel Spolsky než Paul Graham, jsem nutně vychýlený na stranu -- jak to bylo? -- jedné dominantní firmy).

Co mě osobně na celém problému nejvíce zaujalo, je to hledání metody, jak s podobnou chybou naložit. Upřímně řečeno -- nevím. Myslím si, že uživatelé mají právo na zpětnou kompatibilitu, současně ale souhlasím s tím, že zrychlení operací FindFirstFile, FindNextFile je žádoucí, a že po něm korporátní zákaznící Microsoftu touží, a neměli by o něj být připraveni. Myslím, že není správné vyhazovat message box u takových operací jako je vylistování obsahu adresáře, ale přitom chápu, že spamování error logu není řešením pro domácí uživatele, kteří najednou neuvidí své soubory, a kteří nevědí (a nechtějí vědět) nic o tom, co je to nějaká Samba, nebo jakým způsobem Explorer zjistí které soubory jsou ve kterém adresáři. Souhlasím s tím, že nejlepším řešením je opravit instalace vadné Samby, ale nejsem si úplně jistý, jestli je to realizovatelný požadavek u jednoúčelových fileserverů, které firmy (s Linuxem ve ROM/flash paměti) chrlí po desítkách tisíců.

Jak říkám -- nevím jak takovou situaci řešit. Proto mě celý problém zaujal, protože jsem si myslel (a pořád si to myslím), že se dovím, jak se v takové situaci zachovají (ať už se to někomu líbí nebo ne) ti nejlepší programátoři a softwaroví obchodníci na planetě.

Pokud jde o to, jestli samba-team musel nebo nemusel reverzně inženýrovat (ha!) protokoly Microsoftu: Microsoft má svaté právo nechat si své protokoly pro sebe. Nejsem tak kovaný v historii operačních systémů, abych to mohl říct určitě, ale domnívám se, že snahou MSFT v době, kdy "SMB" vznikalo, bylo primárním úkolem zlikvidovat konkurenci ztělesňovanou firmou Novell. Myslím si, že v té době, nikdo nezveřejňoval specifikace svých protokolů, protože se to prostě nedělalo, a jejich utajení a vzájemná nekompatibilita byly považovány za konkurenční výhodu (jako tomu donedávna bylo -- a leckde stále ještě je -- u instant messaging aplikací a protokolů). Od těch blažených devadesátých let se lecos změnilo, a dnes se naopak protokoly zveřejňují a velké firmy se stávají členy konsorcií, kde se protokoly a formáty domlouvají ke všeobecné nespokojenosti. Je to jako s programováním -- od rigidního stylu vše bude naplánováno, pak implementováno, nakonec otestováno, a co si zákazník nevymyslí hned zkraje, to mít nebude se postupně přechází k extrémnímu programování, které říká neplánujte nic, napište pár testů a uvidíte co z toho vzejde.

Stejně jako se za těch deset patnáct let změnila představa ideálního programovacího stylu, změnila se i představa ideálního přístupu k protokolům. Dříve nepředstavitelné zveřejňování obchodních tajemství se dnes stalo všeobecným standardem, a firmy sázejí víc na to, že nabídnou synergické řešení všech problémů, které bude zákazníky demotivovat od nákupu produktů konkurence (pravým důvodem proč používat Outlook není příjem pošty, ale propojení s Exchangem a zbytkem balíku Microsoft Office, důvodem proč nepoužívat OpenOffice.org není těch 1397 funkcí, které má Excel navíc, ale absence návaznosti na Exchange a další produkty Microsoftu).

Abych to shrnul: Vývojáři Samby v diskusi pod Chenovými příspěvky sami přiznali, že chyba nevznikla proto, že by neznali protokoly Microsoftu (který je prý už docela obstojně dokumentuje a s týmem Samby snad i spolupracuje), ale proto, že prostě udělali normální stupidní chybu (nějaký ten zapomenutý case ve příkazu switch()). Údajně zabrala oprava chyby (včetně testování) asi tři minuty. (Což mi připomíná, že, pokud jsem to správně pochopil, problém není v tom, že by listování adresáře nevyhodilo chybu. Problém je v tom, že ji vyhodí i když nemá!)

Blog Old New Thing se problémem zpětné kompatibility zabývá poměrně často. I proto ho čtu -- protože mi stále připomíná, že opravit chybu někdy nestačí...

Hlas z druhého břehu

Tento BVerův text se objevil pod přispěvkem Malinkatá chybička. Myslím, že si že zaslouží širší pozornost, takže jsem z něj udělal příspěvek. --objektivní editor-- (alias jIRI)

Jsa vhozen do jedné škatule k militantním linuxářům, nemám jinou možnost než na tento emocemi nabitý post odpovědět. Konečně, Festivalu už by po čase prospěl nějaký slušný flamewar, tak rád plním jIRImu jeho nevyslovené přání :-)

Předně: v dané kauze vystupuje všemi dlouho očekávaný operační systém od dominantní firmy na jedné straně a souborový server, jenž je k dispozici zdarma se zdrojovými kódy, na straně druhé. Dále je třeba zmínit, že oné dominantní firmě už samotná existence serverového projektu vadí -- tento software umožňuje běžným uživatelům přistupovat ze stanic vybavených operačním systémem dominantní firmy k souborům uloženým na jiných systémech (zvláště pak k souborům těch operačních systémů, které dominantní firma považuje za svoji hrozbu). Daný souborový server tím podstatně zvyšuje použitelnost a užitnou hodnotu konkurenčních systémů a dovoluje tak vzájemné soužití různých OS na jedné lokální síti a tím původně dokonalou dominanci firmy narušuje. Pro úplnost je ještě třeba zmínit, že dominantní firma detaily svých síťových protokolů původně nezveřejnila, takže serverový projekt vznikl na základě zpětného inženýrství a neúplných informací o chování a analýzou síťového provozu klientů dominantního výrobce.

Řekl bych, že toto uspořádání věcí situaci značně komplikuje, protože původně ryze technický problém je posouván do roviny obchodní, filozofické, až nábožensky fundamentalistické.

Pokusím se od vyšších rovin oprostit a hodnotit otázku na ryze systémové úrovni:

Každá jednotlivá komponenta tak komplikované věci, jakou je (jakýkoliv) operační systém, by měla dělat svoji práci v rámci celku čistě, jednoduše, logicky a bez zbytečných vedlejších předpokladů. Pokud tomu tak není, je její chování komplikované, pro ostatní komponenty obtížně předvídatelné a hůře abstrahovatelné -- bezprostřední okolí, které s komponentou komunikuje, se musí jejímu chování přizpůsobovat a to vede ke zbytečným složitostem a dalším nadbytečným předpokladům. Každá složitost pak zvyšuje šance zákeřných chyb a zhoršuje efektivitu (rychlost a paměťovou náročnost). Snahou architektů je tak samozřejmě udržet systém na všech úrovních co nejjednodušší. Proto například jedno z navrhovaných řešení "systém se postará sám o chybové hlášení k směrem k uživateli a zobrazí dialog s varováním" je vadné -- síťový subsystém by tak musel mít těsné vazby na nějaký zobrazovač událostí (jenž je zodpovědný za zobrazování GUI hlášek v daném rozlišení, barvách, jazyce, atd...) a tato vazba může být zdrojem komplikací, protože cílem síťového subsystému je být efektivní a cílem zobrazovacího subsystému je být komfortní. Je evidentní, že síťová komponenta OS má problém detekovat, obejít, hlásit a zaznamenat tuto událost co nejjednodušším zůsobem (např. návratovou hodnotou volání, zápisem do systémového logu, atd.), je pak pouze a jen věcí aplikace, jestli a jakým způsobem varování prezentuje. Tedy: model toho, jak se zachovat, je plně v kompetenci softwarové vrstvy NAD síťovou komponentou OS, tedy konkrétně souborového prohlížeče. (Poznámka na okraj: Je smutné, že i technicky orientovaní lidé už dnes nedokážou rozlišovat mezi operačním systémem a jeho aplikacemi -- slíbil jsem ale, že se nyní budu držet ryze technických aspektů, takže nechci toto téma rozvíjet.)

Tolik tedy k tomu, proč "podobné workaroundy jsou cestou do pekel, a že jakékoliv jiné řešení než to "čisté" zalogování a vrácení chyby, je projevem opravdového zla", doufám, že je jasné, proč a z jakých důvodů hájím toto stanovisko.

Nyní k vyšším úrovním problému: Operační systém je v konečném důsledku komerční produkt a jako takový vzniká díky značnému úsilí technického a obchodního týmu. Obchodníci stanovují priority, celkové zaměření, look´n´feel celého produktu, měli by dobře znát cílovou skupinu zákazníků, atd. V reálném světě jsou pak požadavky dané obchodním týmem často v rozporu s prioritami technickými -- v daném případě je obchodním požadavkem zpětná kompatibilita: síťové aplikace musí fungovat úplně stejně jako na předchozí verzi operačního systému, jenž je ale zcela technicky odlišný od vyvíjeného systému. Podobný požadavek, je-li prosazen, vede k tomu, že v nenarozeném dítěti vzniká slepé střevo (bug v serverovém projektu byl už odstraněn a za několik měsíců bude workaround v OS úplně nepotřebný, zatímco OS bude udržován dlouhou řadu let, je mylné předpokládat, že uživatelé budou vadnou verzi serveru používat dlouhodobě třeba kvůli firmware v ROM). Stručně řečeno, má být odstraněna jen původní chyba a na místě, kde vznikla.

Vybalancování technických a obchodních požadavků je nelehkým úkolem hlavních šéfů -- jen oni rozhodují o tom, zda je důležitější mít technicky dokonalý OS s drobným nekomfortem, jenž časem donuti určité procento správců serverů k upgradu, nebo to, aby současní zákazníci měli snadný přechod na operační systém, jenž je vnitřně zaneřáděn od samého začátku.

Celková politika dominantní firmy je dlouhodobě zvýhodňovat obchodní priority před technickými -- jen tak dosáhla své dominance. Tato jistě úspěšná strategie nicméně vysvětluje i fakt, proč technické parametry produktů, APIs a protokolů oné dominantní firmy jsou vždy podřízeny momentálním krátkodobým trendům, proč jsou výrobky uváděny na trh se zpožděním a proč je jejich údržba často problematická.

Tímto se dostávám k předposlednímu argumentu (pokrytectví a "dělání blbců" z uživatelů): každá úspěšná firma musí pracovat s modelem zákazníka. Obchodníci operují s tvrzeními typu "tohle uživatel snese, tohle už ne", "tohle je intuitivní, tohle už ne", "tohle vypadá jako naše chyba, to není přípustné", apod. Myslím si, že model uživatele, s nímž pracuje dominantní firma, je (zbytečně) vychýlen směrem k podprůměrnému uživateli s nižším IQ. Je to logické -- lidé, kteří konktaktují uživatelskou podporu, většinou k této skupině patří a je tak výhodné ušetřit náklady, pokud jich bude co nejméně. Ona podceňovaná "mlčící většina" je ale v průměru mnohem šikovnější a schopnější, než by dominantní firma byla ochotna připustit. Což je mimo jiné i důvod, proč vůbec vznikají a jsou velmi populární projekty jako je síťový souborový systém postavený na protokolech dominantní firmy.

Tak.

Doufám, že jsem aspoň částečně vysvětlil své "svaté pravdy", které byly autorem vyjmuty z kontextu naší dlouhotrvající diskuse a lehce osprejovány narudo.

A teď si neodpustím ti tu trošku demagogie, jIRI, vrátit ve formě malé podpásovky. Jen tak dál, časem si snad opravdu nainstaluješ nějakou šikovnou linuxovou distribuci, staneš se jejím spokojeným a nakonec i pokročilým uživatelem a budeš tak schopen posuzovat a hodnotit věci i "z druhého břehu".

Kdyby totiž platil tvůj omyl, že "Linux nemá zákazníky", neuvažovali by tvůrci Visty o podpoře staré verze Samby -- nebo snad ano?

Malinkatá chybička

Příspěvek How would you solve this compatibility problem: Network interoperability (Old New Thing) si určitě přečtěte. Je zajímavé, jak takový vcelku banální problém dokáže přesně rozdělit lidi na dvě poloviny. A je zajímavé, kolik se toho o lidech dovíte z toho, na kterou stranu se přikloní.

O co jde?

Raymond Chen z Microsoftu se táže svých čtenářů, jak by řešili tento problém: file serveru se lze na seznam souborů zeptat pomalu nebo rychle. Pomalu se ptaly WindowsXP, Windows Vista se ptají rychle. Ovšem někteří betatesteři reportují podivnou chybu, kdy s některými file servery (nakonec byla v diskusi identifikována jako provinilec Samba, včetně odkazu do bugzilly) není načten celý seznam souborů, ale jen prvních 128 položek. Chyba v sambě byla zkraje roku opravena, nicméně jistě stále zůstává dost neupgradovaných instalací, při kontaktu se kterými by se Vista jevily jako pochybný operační systém, který ani nedokáže vylistovat soubory. (Poznamejme ještě, že nejde jen o problém s Windows Explorerem, ale se všemi aplikacemi, které používají API shellu k vylistování obsahu adresáře.) Čili se Chen ptá, jak mají Vista s touto chybou (která není jejich chybou, ale chybou kopírovačů, kteří Microsoft a jeho produkty tak nenávidí, až je pod hlavičkou open source kopírují) naložit.

Mají Vista chybu detekovat, zapsat informaci o ní do logu, a API vrátit chybový kód? Nebo se ji mají snažit detekovat, a před uživatelem skrýt? A tady se právě lidé rozdělují na dva neslučitelné tábory: jedni (ke kterým patří třeba BVer) se domnívají, že jediným řešením je chybu ohlásit a nechat uživatele/administrátory ať si nainstalují novou verzi Samby. Druzí (do této skupiny patřím já) si myslí, že je nepředstavitelné, aby operační systém, který používá zhruba 500 miliónů lidí, najednou přestal fungovat tak, jak tito lidé očekávají.

BVer mi v naší vášnivé diskusi na toto téma vysvětloval, že podobné workaroundy jsou cestou do pekel, a že jakékoliv jiné řešení než to "čisté" zalogování a vrácení chyby, je projevem opravdového zla. Já si na druhou stranu myslím, že pro Microsoft, který už tak všichni upřímně nesnáší, je nepřijatelné to, že za drahé peníze vnutí svým zákazníkům nový operační systém (kvůli kterému budou muset upgradovat hardware, přistoupit na licenční podmínky, které určitě budou výhodnější než ty současné -- výhodnější pro Microsoft, atd.), a ten pak nebude fungovat.

BVer dštil oheň a síru na snahu Microsoftu "vypadat dobře", a že z uživatelů dělá blbce. Já tomu ale rozumím: když nějaká firma utratí řekněme půl milionu dolarů za upgrade na Vistu, má za své peníze určitá očekávání. Jedním z nich je, že to co fungovalo, bude fungovat bez problémů dál.

Vidím tu ten propastný rozdíl mezi uvažováním lidí od Linuxu a lidí od Windows: Linux nemá zákazníky a není zákaznicky orientovaným softwarem. Windows naproti tomu jsou komerční produkt, který se musí prodávat, aby obhájil svou existenci.

Militantní Linuxáři vám řeknou: Pokud ti Linux příjde složitý, jsi debil, který si ho stejně nezaslouží. Podlézavý Microsoft vám nabídne slevu (kterou samozřejmě nechce zadarmo).

Linuxáři hají svou svatou pravdu s otevřeným kódem. Microsoft chce všechny peníze, které jste mu schopni dát.

Co mají oba tábory společné, je ta zarputilá tvrdohlavost, se kterou jdou za svým...

PS: Kauza pokračuje (a Chen vysvětluje, proč BVerův scénář s donucením k updatu není úplně realizovatelný). Doporučuji sledovat...

Visual Driven

Takže BVer mě svou soustavnou věrozvěsteckou činností nakonec přeci jen uvrtal do Test Driven Development. (Byly časy, kdy jsem si myslel, že je to tím, že je o nějaký ten rok starší, že vždycky přivede k něčemu zajímavému on mě, a ne já jeho. Pak jsem ale sám trochu zestárl, a zjistil jsem krutou pravdu: opravdu jsou někteří lidé chytřejší než já. Někteří o dost chytřejší [sigh].) Zatím jsem ve fázi bezbřehého nadšení, které samozřejmě časem vyprchá, až budu kvůli banální změně v interfacu třídy přepisovat dvacet testů, ale právě teď mě fakt, že se v nUnit mnění kolečka z červených na zelená, naplňuje takovým štestím, že se to snad ani nedá popsat.

S tím souvisí další téma, které jsem chtěl už delší dobu zmínit: Visual Studio 2005. Tak tedy: na první pohled skvělé. Sice mi příjde, že se vizuálním vzhledem až nebezpečně blíží Microsoft Office 2003, což je samozřejmě nepříjemné, protože, jak známo, vývojové prostředí má být tak spartánské jak to jen jde... No dobrá, podobné žvásty mě iritují u vyznavačů čistých textových editorů jakožto primárního vývojového prostředku, takže si je odpustím. (Pravda je taková, že bych těch pár pixelů, které zkonzumují barevné toolbary klidně obětoval dalším dvěma řádkům kódu, ale nešť.)

Nové (teď už ne tak moc) Visual Studio z mého pohledu (tedy z pohledu v zásadě stand-alone vývojáře, sám se řídím, sám si peru, a tak dále) nepřineslo nic až tak obrovsky úžasného. Ano, C# konečně podporuje templaty (v microsoftím newspeaku generika), ano, Class designer je moc pěkná věc, která konečně umožňuje snadné XML komentování kódu, a občas i návrh tříd (a je opravdu fajn, že se prázdná třída vygeneruje automaticky), a pak jsou tu tyhle vymoženosti v Data-bindings, a spousta nových funkcí a tříd v .NET frameworku 2, ale popravdě: je to krok spíše evoluční, než revoluční, skoro nic, co by mi dneska nemohl poskytnout produkt jako je #develop, nebo v případě C++ nějaký ten front-end nad gcc.

Jelikož pořád ještě nemáme (a dlouho mít nebudeme) WinFX, nějakému tomu importování Win32 funkcí se člověk nevyhne, nové Visual Studio padá (a to tak že často -- s VS2003 jsem žádný pád nikdy nezažil, zato hned první pokus s VS2005 skončil moc pěknou chybou, kdy neinicializovaný objekt -- po importu projektu z VS2003, kde to nevadilo -- způsobil pád form-designeru, který se, po znovuspuštění a znovunačtení projektu, automaticky načetl, takže nebylo lze chybu opravit, a nakonec jsem musel smazat .suo soubor, abych se neotevíraly žádné soubory projektu), i když je teď dialog Options trochu přehlednější, nemůžu se zbavit dojmu, že z něj zmizely některé položky, které v VS2003 bylo možné nastavit.

Celkově je VS2005 (podle mého zjevně nezasvěceného názoru) pořád nejlepším vývojovým prostředím (hlavně kvůli opravdu vypečenému IntelliSense), ale nějak jsem si od něj sliboval víc...