Joel a szoftverről szoftvermenedzsment egyszerűen

Joel lapja

Gerilla magyar fordítások

Hivatalos fordítások

Hogy veszítette el a Microsoft az API háborút

Írta: Joel Spolsky (2004. június 13.)
Fordította: Nagy Balázs, 2004. július 11.
Az eredeti cikk

Manapság sokat lehet hallani azt az elméletet, miszerint a Microsoftnak befellegzett. Amint teret nyer a Linux a desktopon, és a webalkalmazások felváltják a helyi alkalmazásokat, a birodalom térdre hull.

Bár van némi igazság abban, hogy a Linux hatalmas veszélyt rejt a Microsoft számára, a redmondi cég halálát kelteni legalábbis meggondolatlanság. A Microsoftnak hihetetlenül sok készpénze van a bankban, és még mindig hihetetlenül nyereséges. Messze van még az elbukás. Ha tíz évig mindent elrontanak, csak akkor jelentkeznének távoli jelei a veszélynek, tehát ki tudhatja… az utolsó pillanatban még újra felfedezhetik magukat darált jég gyárként is. Szóval ne írjuk le őket olyan gyorsan. A kilencvenes évek elején mindenki azt hitte, az IBM-nek vége: a mainframe-ek már csak történelem. Akkoriban Robert X. Cringely azt jósolta, hogy a mainframe-kornak 2000. január elsején vége lesz, és minden COBOL-ban írt alkalmazás kihal, és ahelyett, hogy az amúgy már rég elveszett forráskódban javítgatnának, mindenki újraírja azokat kliens-szerver architektúrára.

Tippelj, mi történt. A mainframe-ek még mindig itt vannak, nem volt semmi 2000. január elsején, és az IBM átpozícionálta magát egy jó öreg technológia-konzultációs céggé, ami úgy tűnik, még olcsó fröccsöntött telefonokat is gyárt. Így a pár mérési eredményből azt extrapolálni, hogy a Microsoftnak lőttek, nagyon is túlzó.

Bár egy kevéssé megértett jelenséget nem vettek észre: a Microsoft stratégiai kincsének, a Windows API-nak vége. A Microsoft monopólerejének és a hihetetlenül nyereséges Windows és Office franchise-ok sarokköve, ami virtuálisan minden bevételért felelős, és maximálisan csak épphogy megtérülő termékvonalat jelent, a Windows API már nem tűnik érdekesnek a fejlesztők számára. Az aranytojást tojó tyúk még nem halt meg, de végzetes betegségben szenved, amit még senki nem vett észre.

Elnézést kérek, amiért túl grandiózusnak vagy dagályosnak tűnt, amit mondtam. Lehet, kezdek a vásári szórólapok szerkesztőihez hasonlítani, akik egyre csak rágják a Microsoft stratégiai vagyonát, a Windows API-t. Betölt néhány oldalt, mire elmagyarázom, mire is gondolok valójában, hogy megítélhesd az érveimet. Kérlek, ne ugorj máris egy következtetésre, amíg nem magyarázom el, miért is beszélek. Hosszú írás lesz. El kell magyaráznom, mi is az a Windows API, be kell mutatnom, miért is ez a legfontosabb stratégiai vagyona a Microsoftnak, el kell magyaráznom, hogy is veszett oda, és mik a hosszútávú hatásai ennek. Aztán mivel nagy trendekről beszélek, néha túloznom és általánosítanom kell.

Fejlesztőket, fejlesztőket, fejlesztőket, fejlesztőket!

Emlékeztek az operációs rendszer definíciójára? Az az a dolog, ami kezeli a számítógép erőforrásait, hogy az alkalmazások futhassanak. Az emberek nem igazán törődnek az operációs rendszerel. Az alkalmazásaikkal foglalkoznak, amiket az operációs rendszer megléte tesz lehetővé. Szövegszerkesztőkkel, üzenetküldőkkel, e-mail olvasókkal, banki szoftverekkel. Web oldalakkal, a Paris Hilton képével. Magukban az operációs rendszerek nem használhatók. Az emberek azért vesznek operációs rendszert, mert hasznos alkalmazások futnak rajtuk. Tehát az a leghasznosabb operációs rendszer, amin a leghasznosabb alkalmazások futnak.

Ennek az a logikus következménye, hogy ha operációs rendszert akarsz eladni, a legfontosabb dolog az, hogy a fejlesztők akarjanak fejleszteni a te operációs rendszeredre. Ezért ugrálta körbe a színpadot Steve Ballmer kiabálva, hogy „fejlesztőket, fejlesztőket, fejlesztőket, fejlesztőket”. Ez annyira fontos a Micosoftnak, hogy csak azért nem adja ingyen a Windows fejlesztői segédeszközöket, mert nem akarja gondatlanságból megfojtani a fejlesztői segédeszközgyártó versenytársait (már amennyi maradt), mivel minél több fejlesztői környezet van egy platformra, annál népszerűbb a fejlesztők körében. Az Empower ISV program keretében öt teljes MSDN Univerzum összeállítást (másnéven „minden Microsoft termék, kivéve a Flight Simulator”) megkapsz úgy 375 dollárért. A .NET nyelvek parancssori fordítója az ingyenes .NET környezetben már bent van. A C++ fordító már szintén ingyenes. Minden a .NET platform fejlesztőit bíztatja, épphogy nem ütve ki a Borlandot és a többieket.

Miért nem tud eladni számítógépet az Apple és a Sun

Tudom, ez egy kicsit butuska cím: persze, hogy el tud adni számítógépet az Apple és a Sun, de nem a két legnagyobb haszonnal járó piacra, nevezetesen a céges munkaállomásnak és otthoni számítógépnek. Az Apple még mindig csak igen alacsony egy számjegyű piaci részesedéssel bír, és az összes Sun munkaállomást használó ember a Sun-nál dolgozik (kérlek értsd meg, hogy nagy trendekről beszélek, tehát ha azt mondom, „senki”, úgy értem, hogy „kevesebb, mint tízmillió ember”, és a többi).

Miért? Mert az Apple és a Sun számítógépek nem futtatják a Windows programokat, vagy ha igen, csak nagyon nehézkesen. Ne felejtsük el, hogy az emberek az alkalmazások futtatása miatt vesznek számítógépet, és sokkal több nagy szoftver fut Windows-ra, mint Mac-re, így nagyon nehéz Mac felhasználónak lenni.

Ezért olyan nagy érték a Microsoftnak a Windows API.

(Tudom, tudom, ennél a pontnál a világ 2,3%-a, akik Macintosh-t használnak, már készítik is levelező szoftvereiket, hogy jól megmondhassák, mennyire is szeretik a Mac-üket. Mégegyszer, most nagy trendekről beszélek, és általánosítok, tehát ne pazarold az idődet. Tudom, hogy szereted a Mac-edet. Azt is jól tudom, hogy minden megvan rajta, ami neked kell. Szeretlek, aranyos vagy, de akkor is csak a világ 2,3%-ához tartozol, és ez a cikk nem rólad szól.)

A Microsoft két tábora

A Microsofton belül két szembenálló tábor van, amiről kicsit összezárt szájjal csak úgy fogok beszélni, mint a Raymond Chen tábor, és az MSDN Magazine tábor.

Raymond Chen a Microsoft Windows csapatához tartozik. Már 1992 óta ot van, és az ő Régi-Új dolog weblogja tömve van részletes technikai történettel arról, hogy a Windows-ban miért vannak úgy a dolgok. Még egészen apróságok is, amikről a végén kiderül, nagyon is jó okai vannak.

Raymond weblogjában a legfigyelemreméltóbb olvasnivaló a visszafelé kompatibilitás megőrzése érdekében tett hihetetlen lépések történetei:

Nézzük a dolgot a vásárló szemszögéből. Megvetted az X, Y és Z programokat. Aztán frissítettél Windows XP-re. A rendszer véletlenszerűen összeomlik, és a Z program el sem indul. Azt fogod mondani az ismerőseidnek, hogy „ne frissítsenek Windows XP-re, mert véletlenszerűen lefagy, és nem kompatibilis a Z programmal”. Nekiállsz hibát keresni a rendszerben, hogy kiderüljön, az X okozza az összeomlásokat, és a Z azért nem megy, mert nem dokumentált Windows üzeneteket használ? Persze, hogy nem. Visszaviszed a Windows XP-t, hogy adják vissza az árát. (X-et, Y-t és Z-t néhány hónappal ezelőtt vetted meg, és már rájuk nem érvényes a 30 napos visszavásárlási garancia. Csak a Windows XP-t viheted vissza.)

Erről a SimCity nevű sláger játék egyik fejlesztőjétől hallottam először, aki elárulta, volt egy kritikus hiba a programukban: egy memóriaterületet közvetlenül felszabadítása után használtak. Ezt egyértelműen nem szabad csinálni programozásban, de DOS alatt rendben működött. Windows alatt persze nem, mert a felszabadított területet kapásból oda is adta valamelyik másik programnak. A Windows tesztelők számos népszerű alkalmazást kipróbáltak, hogy biztosan működjön, de a SimCity álandóan meghalt. Ezt jelentették a Windows fejlesztőknek, akik visszafejtették a SimCity kódját debugger-ben végiglépkedve, megtalálták a hibát, és beszúrtak egy külön kódot, ami ellenőrizte, hogy a SimCity fut-e éppen, és ha igen, a memória lefoglalót olyan módba kapcsolták, amivel lehetett a lefoglalt memóriaterületet felszabadítása után is használni.

Ez egyáltalán nem volt kirívó eset. A Windows tesztcsapata hatalmas, és az egyik legfontosabb követelményük, hogy mindenki biztonságosan frissíthesse az operációs rendszerét, bármelyik alkalmazást is használják, akár olyanokat is, amik rossz dolgokat csinálnak, nem dokumentált függvényeket használnak, vagy olyan hibákat használnak ki, ami a Windows n-ben még hibás volt, de a Windows n+1-ben már nem. Ha körbenézel a registry AppCompatibility részénél, egy nagy csomó olyan alkalmazásnevet fogsz találni, amit a Windows külön kezel különféle hibákat és furcsaságokat emulálva, hogy azok tovább működhessenek. Ha valamelyik alkalmazás nem fut el Windows 95-ön, azt én felhasználói hibának veszem. Sok álmatlan éjszakámat töltöttem mások által írt kódok kijavításával, csak hogy működhessenek Windows 95 alatt is.

Nem minden fejlesztő és mérnök ért egyet az ilyen működéssel. Ha az alkalmazás valamit rosszul csinál, vagy valamilyen nem dokumentált viselkedést használ ki, gondolják, ne működjön, ha az oprendszert frissítik. Az Apple-nél a Macintosh fejlesztői mindig ebbe a táborba tartoztak. Ezért olyan kevés régi alkalmazás működik még most is Macintoshon. Például sok fejlesztő próbálta úgy gyorsítani programját, hogy az ugrótáblából kimásolták a mutatókat, és saját maguk hívták meg azokat ahelyett, hogy a processzor megszakítás szolgáltatását használták volna, ami erre való. Bár valahol az A Machintos Belsejében könyvben, ami az Apple hivatalos Macintosh programozási bibliája, volt egy technikai megjegyzés, hogy „ilyet nem lehet csinálni”, mégis megtették, és működött, a programjuk gyorsabban is futott… az első verzióváltásig, és onnantól kezdve már egyáltalán nem ment. Ha a szoftver írója közben kivonult a piacról (szinte az összes), hát, így jártál, haver.

Ezzel szemben az 1983-ban, eredeti IBM PC-re írt DOS-os programjaim még mindig remekül futnak, hála a Raymond Chen tábornak. Tudom, hogy ez nem csak Raymond érdeme: az egész Windows API csapat modus operandi-jából fakad. Ám mivel Raymond publikálta a legrészletesebb formában a remek Régi-Új Dolog weboldalán, róla neveztem el.

Ez az egyik tábor. A másik tábort az MSDN Magazin tábornak fogom hívni, arról a fejlesztői magazinról elnevezve, ami teli van érdekes cikkekkel arról, hogy milyen különféle módokon lőheted lábon magad, a Microsoft termékek ezoterikus keverékével a szoftveredben. Az MSDN Magazin tábor arról próbál mindig meggyőzni, hogy használd az új, összetett külső COM+, MSMQ, MSDE, Microsoft Office, Internet Explorer technológiát és komponenseiket, az MSXML-et, DirectX-et (persze csak a legújabbat!), Windows Media Playert, és a Shareponint-ot… Azt a Sharepoint-ot, ami senkinek sincs meg, és ami olyan kiterjedt külső függőségekkel rendelkezik, hogy idegrohamot kap az installáláskor az ember a fizetős ügyfél színe előtt. Ennek a technikai neve DLL-pokol. Itt megy, de ott miért nem?

A Raymond Chen tábor a fejlesztők számára egyszerű azt jelenti, hogy az egyszer megírt programok mindenhol (na jó, minden Windows-on) menjenek. Az MSDN Magazin tábor szerint a fejlesztők számára egyszerű azt teszi, hogy minél hatékonyabb kóddarabokat adjunk a kezébe, amit felhasználhat, ha cserébe vállalja a borzasztóan összetett telepítést és az azzal járó fejfájást, nem említve a hosszú betanulási időt. A Raymond Chen a konszolidáltságra esküszik. Légyszi, ne tegyük még rosszabbá a dolgokat, hagyj minket mindent úgy csinálni, ahogy még mindig működik. Az MSDN Magazine tábor rendszeresen jön az újabbnál újabb gigászi technológiákkal, amivel senki sem tud lépést tartani.

Miért is számít ez?

A Microsoft elveszítette a felhasználók visszafelé kompatibilitásba vetett hitét

A Microsofton belül az MSDN Magazine tábor nyerte meg a háborút.

Az első nagy győzelmük az volt, hogy a Visual Basic.NET nem kompatibilis a VB 6.0-val. Szó szerint ez volt az első alkalom, mikor egy Microsoft termék frissítése után a régi adataidat (a még VB6-ban írt kódokat) nem lehetett tökéletesen és automatikusan importálni. A Microsoft első alkalommal nem méltányolta az előző verziót használó fejlesztők munkáit.

Az ég úgy tűnt, nem szakadt rájuk, legalábbis a Microsoft-on belül. A VB6 fejlesztők feltették a kezüket, de valahogy eltűntek, mivel legtöbbjük céges fejlesztő volt, akik úgyis a webes fejlesztés felé mozdultak. A valódi hosszú távú veszteség rejtve maradt.

Az MSDn Magazine tábor e nagy sikerrel hátuk mögött átvették a hatalmat. Hirtelen rendben lett a dolgok megváltoztatása. Más szálkezelési modellel jött ki az ISS 6.0, amitől sok régi alkalmazás dobta fel a talpát. Megrázó volt azt hallani az ügyfelektől, hogy a Windows Server 2003-nak problémái vannak a FogBugz futtatásával. Aztán a .NET 1.1 nem volt teljesen kompatibilis az 1.0-val. És most, hogy kibújt a szög a zsákból, a Windows API csapatot is megcsapta a változás szele, és úgy döntöttek, hogy a Windows API bővítése helyett írnak egy teljesen újat. A Win32 helyett, mondták, készüljünk a WinFX-re: a második generációs Windows API-ra. Minden más lesz. .NET-alapú menedzselt kód. XAML. Avalon. Biztos sokkal jobb lesz, mint a Win32, elismerem. De ez nem frissítés: nincs kódfolytonosság.

A külső fejlesztők, akik sosem voltak kifejezetten boldogok a Windows fejljesztés bonyolultságától, mindenki elfordult a Microsoft platformtól, és már webre fejleszt. Paul Graham, aki a Yahoo! Stories-t írta a dotkom bumm kezdeti időkben, ékesszólóan összefoglalta: „Az új cégek legfontosabb oka arra, hogy webes szoftvert írjanak, az az, hogy a desktop alkalmazások írása már lényegesen kevésbé szórakoztató. Ha desktop alkalmazást akarsz írni, azt a Microsoft szerint kell tenni, meghívva az API-jait, és ki kell védeni a hibás operndszer hibáit. Ha olyan szoftvert akarsz írni, ami helyből felszáll, csupán a Microsoft-nak végzel piackutatást”.

A Microsoft elég nagyra nőtt, túl sok fejlesztője van, és azok túlzott nyereséghajszolási lázukban kitalálták, a minden még nem elég nagy projekt. A fenébe, mindent megcsinálunk kétszer is! A régi Microsoft, a Raymond Chen-es Microsoft megfejlesztheti az Avalont, az új grafikus rendszert DLL-ek sorozatában, ami a Windows minden verziójában elfut. Technikai oka nincs arra, hogy ne így legyen. Ám a Microsoft okot akar adni arra, hogy vedd meg a Longhorn-t, és mindent le akar cserélni, mint amikor a DOS-t felváltotta a Windows. A hiba ott van, hogy a Longhorn nem túl nagy fejlődés a Windows XP-hez képest. Közel sem akkora, mint a Windows volt a DOS-hoz képest. Ez még valószínűleg nem fogja meggyőzni az embereket a váltásra. Vagy lehet, hogy mégis, de a Microsoftnak biztosra kell mennie, és amit eddig láttam, nem volt elég meggyőző. A Microsoft sok döntése hibásnak bizonyult. Például a WinFS úgy lett reklámozva, mint egy keresési módszer, ahol a fájlrendszert relációs adatbázisba helyezik el, figyelmen kívül hagyva azt a tényt, hogy a keresés valójában abból áll, hogy elvégezzük a keresés műveletét. Ne kelljen már beírnom minden fájlhoz a metaadatokat, hogy majd jól kereshessek bennük a lekérdezőnyelvvel. Csak tegyétek meg azt a szívességet, hogy keressetek már azon a nyamvadt vinyón gyorsan arra a szövegre, amit beírtam, használva a teljes szöveges indexeket és más hasonló technikákat, amik 1973 környékén születtek.

Az automataváltó nyerte a mai versenyt

Ne értsetek félre… a .NET szerintem nagyon remek fejlesztői környezet, és az Avalon a XAML-al óriási előrelépés a Windows GUI alkalmazásainak fejlesztése óta. A .NET legnagyobb előnye, hogy automatikus memóriamenedzsmentje van.

Sokunk gondolta a 90-es években, hogy a nagy háború a procedurális és az objektumközpontú programozás között fog eldőlni, és azt hittük, az objektumközpontú programozás óriási lökést fog adni a programozói teljesítménynek. Én is ezt hittem. Vannak még néhányan, akik még mindig ezt hiszik. Kiderült, hogy tévedtünk. Az objektumközpontú programozás nagyon kézre áll, de reményeink ellenére mégsem segített a termelékenységben. A valódi lényeges termelékenységi előny a programozásban azokból a nyelvekből ered, amik automatikusan kezelik a memóriát. Ezek a referenciaszámláló vagy szemétgyűjtő algoritmusok. Ez lehet Java, Lisp, Visual Basic (még az 1.0 is), Smalltalk, csak hogy párat említsünk, vagy egy rakás szkriptnyelv. Ha a programozási nyelved megengedi, hogy lefoglalj egy adag memóriát anélkül, hogy azon kezdenél gondolkodni, hogy fogod felszabadítani használat után, egy memóriamenedzselt nyelvet használsz, és valószínűleg sokkal hatékonyabb leszel, mint az, aki explicit memóriakezelést használ. Amikor azt hallod, mennyire hatékony az ő nyelve, a hatékonyságának legnagyobb részét az automatikus memóriakezelésnek köszönheti, még ha ezt nem is ismeri el.

A versenyautó-rajongók most bizonyára már írják az ellenérveiket ezzel kapcsolatban, de a tapasztalataim szerint csak egy környezetben igaz, hogy a kézi váltó sokkal hatékonyabb, mint az automatikus: átlagos vezetésnél. Ez ugyanígy van a szoftverfejlesztésben is: szinte minden esetben jobb az automatikus memóriakezelés, mint a kézi, és sokkal nagyobb programozói hatékonyságot eredményez.

Ha a Windows kezdeti éveiben fejlesztettél alkalmazást, a Microsoft két módszert adott hozzá: vagy megírod C-ben, meghívva közvetlenül a Windows API-t, kezelve a saját memóriádat, vagy Visual Basic-ban írod meg, ami megteszi helyetted a memóriakezelést. Ezt a két fejlesztési környezetet használtam legtöbbször az elmúlt 13 évben, ismerem azokat kívülről-belülről, és az a megítélésem, hogy a Visual Basic lényegesen hatékonyabb. Gyakran írtam meg ugyanazt a kódot egyszer C++-ban, Windows API-t meghívva, egyszer Visual Basic-ban. A C++ fejlesztés háromszor-négyszer hosszabb ideig tartott. Miért? A memóriakezelés miatt. A legegyszerűbb belátni ezt, ha megnézzük a Windows API bármelyik függvényének leírását, ami szöveget ad vissza. Nézd meg tüzetesen, hogy micsoda vita van arról, hogy mi foglalja le a helyet a szövegnek, és hogyan tárgyalja meg, mekkora memória is kell. Tipikusan a függvényt kétszer kell meghívni – egyszer nulla bájtot lefoglalva, ami „nincs elég memória” hibaüzenettel visszatér, mellesleg megmondva, hány bájtot is akart volna lefoglalni. És ha szerencsés vagy, nem kell olyan függvényeket meghívni, amik szövegek listáját, vagy egy teljesen változó hosszúságú struktúrát ad vissza. Bárhogy is, az olyan egyszerű dolgok is, mint egy fájl megnyitása, szöveg kiírása, a fájl bezárása nyers Windows API-ban megírva akár egy oldal kódot is kitehet. Visual Basic-ban mindezt leírva elfér három sorban.

Szóval van ez a két programozási világ. Mindenki egész biztos abban, hogy a menedzselt kód világa sokkal jobb a nem menedzselt kód világánál. A Visual Basic az egyik legsikeresebb programnyelv volt (és valószínűleg az is marad), és a fejlesztők jobban szeretik a C-nél vagy C++-nál, ha Windows fejlesztésről van szó. Annak ellenére, hogy a „Basic” nyelvet a programozók kemény magja lenézi még akkor is, ha ez, névadójával ellentétben már egy elég modern nyelv, számos objektumközpontú tulajdonsággal, és csak nagyon kevés benthagyott szeméttel (mint a sorszámok és a LET utasítás). A VB másik problémája az, hogy a telepítéskor szükség van a VB runtime-ra, ami elég jelentős a modemen terjesztett shareware-ek miatt, de leginkább azért, mert így mindenki láthatja, hogy a program (ezt a szégyent!) Visual Basic-ban lett fejlesztve.

Egy futtatókörnyezet mind felett

Aztán jött a .NET. Nagy projekt volt, a nagy szemétdombot egyszer s mindenkorra összetakarító hiper-szuper projekt. Persze, van benne memóriakezelés is. Van benne Visual Basic is, de van olyan új nyelv is benne, ami szellemében a VB-t idézi, de C-szerű szintaxisa van, kapcsos zárójelekkel és pontosvesszőkkel. És ami a legszebb, hogy ezt a Visual Basic / C hibridet Visual C#-nak hívják, így hát senki sem mondhatja, hogy „Basic” programozók volnánk. A borzasztó Windows függvények szőröstül-bőröstül visszafelé kompatibilisességükkel és a kitalálhatatlan szöveget visszaadó függvényestül ki lettek hajítva, és egyszerű, tiszta objektumközpontú környezetre cserélték, ahol csak egy fajta szöveg típus létezik. Gyönyörű. Aztán végül megérkezett. A .NET remek programozási környezet, ami kezeli a memóriát, gazdag, teljes, és konzisztens interfészt nyújt az operációs rendszer felé, és gazdag, nagyon teljes, és elegáns objektumkörnyezetet ad az alapműveletekre.

Az emberek mégsem használják nagyon a .NET-et.

Persze, néhányan mégis.

Ám a Visual Basic és a Windows API programozás egységesítését úgy megoldani, hogy a semmiből egy teljesen új rendszert építünk fel, nem egy, nem kettő, hanem három (vagy az megvan négy is?) programozási nyelvvel, olyasmi, mint amikor két veszekedő gyereket próbáljuk abbahagyatni, hogy egyre hangosabban kiabálják egymásnak, hogy „fogd be”. Ez csak a tévében működik. Valójában ha két embernek azt kiáltod, hogy „fogd be”, mert túl hangosak, épp most adtál egy-egy jó érvet nekik is.

(Egyébként ha követed a misztikus, de politikailag viharos blog összefogó formátumokat, láthatod, hogy ugyanez van ott is. Az RSS sok különböző verzióra szakadt, pontatlan specifikációkkal, és egy rakás politikai harccal. Egy mindent letisztázni akaró próbálkozás újabb formátummal jött ki Atom néven, így most már van nekünk sok különböző RSS verziónk és egy Atom verziónk, pontatlan specifikációkkal és egy rakás politikai harccal. Két szembenálló felet egyesíteni egy harmadik alternatívával csak azt eredményezi, hogy a végén három szembenálló fél lesz. Nem egyesítettél semmit, és nem javítottál ki semmit.)

Így most a .NET egyesítése és egyszerűsítése helyett van hatféle káoszunk, és mindegyik próbálja kitalálni, melyik fejlesztési stratégiát használja, és hogy vajon megengedhetik-e maguknak a jelenlegi alkalmazásuk .NET-esítését.

Akármennyire konzisztens a Microsoft a marketingszövegben („Csak használj .NET-et – Bízz bennünk!”), a legtöbb ügyfél még mindig C-t, C++-t, Visual Basic 6.0-t és klasszikus ASP-t hasznnál, nem említve a többi fejlesztői környezetet a többi cégtől. És azok, akik .NET-et használnak, az ASP.NET-et használják webalkalmazások írására, ami bár Windows kiszolgálón fut, de nincs szüksége Windows kliensekre, ami kulcsfontosságú lesz, amikor a webről fogok beszélni.

Várj csak, még van tovább is!

A Microsoftnak olyan sok fejlesztője van, hogy nem elég egyszer újra feltalálnia a Windows API-t, ha kétszer is lehet. Tavaly a PDC-n előre bejelentették, hogy az operációs rendszerük következő nagy verziója, a Longhorn többek között egy teljesen új interfész API-t fog tartalmazni, az Avalon-t, ami teljesen új rendszer lesz, hogy kihasználhassa a modern számítógépek gyors megjelenítő adaptereit, és valósidejű 3D renderelést biztosítson. Ha fejlesztettél már Windows GUI alkalmazást a Microsoft „szabványos” legújab-legszebb Windows programozási környezetében, a WinForms-ban, akkor mindent újra kell kezdened tanlni két évig, hogy kihasználhasd a Longhorn és az Avalon előnyeit. Ez megmagyarázza, hogy a WinForms miért is van még gyerekcipőben. Remélem, még nem öltél bele túl sok energiát. Jon Udell talált egy diát a Microsoft-tól, aminek az a címe, hogy „Hogyan válasszunk Windows Forms és az Avalon között?”, és azt kérdi, „Miért kéne választanunk a Windows Forms és az Avalon között?”. Jó kérdés, olyan, amire nincs jó válasz.

Szóval van Windows API-d, van VB-d, és most van .NET-ed, számtalan nyelvi formában, és egyik sem ragadt meg igazán, mert tudod, már készítjük az Avalont, ami csak a legújabb Microsoft operációs rendszeren fog futni, és amilyen még jóóó sokáig nem lesz senkinek. Személy szerint még nem volt időm belemélyedni a .NET-be, és még nem portoltuk a Fog Creek két alkalmazását klasszikus ASP-ről és Visual Basic 6.0-ról .NET-re, mert nem fog pénzügyi előnyt jelenteni. Semennyit. Amennyire meggyőződtem erről olyan, mint a Tűz és előre: a Microsoft örülni fog, ha nem azzal töltöm az időmet, hogy egyre több szolgáltatást adjak a hibakövető rendszeremhez és a tartalomkezelő szoftveremhez, hanem elvesztegetnék néhány hónapot azzal, hogy átportoljam az újabb programozási környezetre, tehát amiből egy ügyfélnek sem lesz jobb, tehát nem lesz jobb az eladás. Ezért ez a jó pár hónap a termék számára teljesen el van pazarolva, ami jó a Microsoft-nak, mert nekik is van tartalomkezelő és hibakövető rendszerük, és mit sem szeretnének jobban, minthogy elpazaroljam a drága időmet az egyre gyorsuló felzárkózásra a mai technikához, hogy aztán megint pocsékoljak egy-két évet az Avalon verzióra is, miközben ők folyamatosan fejleszthetik a saját szoftverüket. Hát persze!

Nincs olyan főállású programozó, aki folyamatosan követni tudja a Redmondból áradó fejlesztéseket, már csak azért sem, mert túl sok droid fejleszt a Microsoftban fejlesztői környezetet!

Ez már nem a kilencvenes évek

A Microsoft a 80-as, 90-es években nőtt meg, mikor a személyi számítógépek fejlődése olyan drámaian gyors volt, hogy minden évben több új számítógépet adtak el, mint az összes addig használt gép. Ez azt jelentette, hogy ha egy olyan terméket készítettél, ami csak új gépeken fut, egy-két éven belül elfoglalhattad a világot még akkor is, ha senki sem váltott át a termékedre. Ezért válthatta fel a WordPerfect-et és a Lotus-t a Word és az Excel teljesen: a Microsoft csak kivárta a hardver fejlődés következő nagy hullámát, és eladta a Windows-t, a Word-ot és az Excel-t az új hardvereiket (ami lehet, hogy az első hardverjeik voltak) megvásárló cégeknek. Tehát a Microsoft-nak sok helyen nem volt szüksége arra, hogy a már meglévő gépeken frissítsenek az N termékről N+1-re. Mikor az emberek új gépeket vesznek, szívesen veszik meg a legújabb Microsoft terméket, de egyébként nem nagyon hajlandóak frissíteni. Ez nem zavaró, mikor a PC ipar futótűzként terjed, de most, hogy a legtöbb PC már elég jó, kösz, a Microsoft hirtelen ráébredt, hogy hosszabb ideig fog tartani, hogy a legújabb dolgok bejöjjenek. Amikor megpróbálták kivonni a forgalomból a Windows 98-at, kiderült, hogy annyian használják még mindig, hogy meg kellet ígérniük, hogy a rozoga nagyit még támogatni fogják jó pár évig.

Sajnos ezek a Vadiúj Stratégiák, mint a .NET, Longhorn és Avalon mind egy új API-hoz akarják kötni az embert, amik nem működhetnek, ha még mindenki a régi, még remekül működő gépét használja 1998-ból. Még ha a Longhorn a megígért 2006-ban is ki lesz adva, amit én egy percig sem hiszek, jó pár évnek el kell tellnie, mire elegendő embernek lesz meg ahhoz, hogy fejlesztői platformszámba vegyék. Fejlesztőket, fejlesztőket, fejlesztőket, de a fejlesztők nem eszik meg a Microsoft személyiségzavaros javaslatait arról, hogy kéne szoftvert fejleszteni.

Lépj Hálóra

El sem tudom képzelni, hogy juthattam el eddig anélkül, hogy megemlítettem volna a Webet. Minden fejlesztőnek megvan a lehetősége, mikor új alkalmazást fejleszt: webre fejlesszen, vagy „gazdag klienst” készít, ami PC-ken fog futni. Az alapvető érvek és ellenérvek egyszerűek: a Webalkalmazásokat egyszerűbb telepíteni, míg a gazdag kliensek gyorsabb válaszidőt adnak, amik gazdagabb felhasználói élményt nyújthatnak.

A Webalkalmazásokat egyszerűbb telepíteni, mert nincs szükség installálásra. Egy webalkalmazás installálása kb. annyi, hogy beírod az URL-t a böngészőbe. Ma felinstalláltam a Google legújabb email alkalmazását egy Alt+D, gmail, Ctrl+Enter beírásával. Sokkal kevesebb kompatibilitási probléma van, és nem fog összeveszni a már meglévő többi alkalmazással. Az alkalmazásod bármelyik felhasználója ugyanazt a verziót fogja használni, és nem kell az ide-oda feltelepített különböző verziókkal törődnöd. Akármilyen programozási környezetet használhatsz, hiszen csak fel kell raknod a saját webszerveredre. Az alkalmazásod virtuálisan a világ összes beszámítható számítógépén elérhető lesz. Az ügyfeleid adatai is, természetesen, elérhető lesz a világ bármelyik internetes gépéről.

Ám megvan ennek az ára a felhasználói felület gördülékenységében. Íme néhány példa arról, hogy mit nem lehet jól megoldani egy webalkalmazásban:

1. Gyors rajzolóprogramot írni
2. valósidejű helyesírásellenőrzőt készíteni hullámos aláhúzással
3. Figyelmeztetni a felhasználókat, hogy elvész a munkájuk, ha bezárják a böngészőt
4. A képernyő kis területét frissíteni a felhasználó által végzett módosítás alapján anélkül, hogy a kiszolgálóról újra letöltené az oldalt
5. Gyors billentyűvezérelt interfészt írni, amihez nem kell billentyűzet
6. Engedni a felhasználókat tovább dolgozni, ha már nem kapcsolódnak az internetre

Ezek nem nagy problémák. Néhányukat gyorsan meg tudják oldani a Javascript fejlesztők. Két új webalkalmazás, a Gmail és az Oddpost, mindkettő email olvasó, nagyon jól ki tudja kerülni, vagy meg tudja oldani ezeket a hibákat. És a felhasználók meg nem törődnek a kisebb UI hibákkal és a webes interfész lassúságával. Szinte minden átlagos ember, akivel találkoztam, valahogy teljesen meg van elégedve a web-alapú email-lel, hiába próbáltam meggyőzni őket, hogy a gazdag kliens hmm… gazdagabb.

Így a Web felhasználói felület 80%-a megvan, és még a legújabb web böngészők nélkül is fel lehet tornászni 95%-ra. Ez már megteszi a többségnek, és mindenképpen megteszi a fejlesztőknek is, akik már minden jelentőségteljesebb alkalmazás fejlesztésekor a webes alkalmazás mellett tették le a voksukat.

Ez egy csapásra azt jelenti, hogy a Microsoft API-jára már nincs is akkora szükség. A webalkalmazásokhoz nincs szükség Windows-ra.

Ez nem jelenti azt, hogy a Microsoft nem vette észre, mi is történik. Természetesen észrevették, és amikor ez kiderült, berántották a féket. Az olyan reményteljes új technológiák fejlesztése, mint a HTA-k, vagy a DHTML, megálltak. Az Internet Explorer csapat eltűnt. Éveken keresztül nem látszott nyoma a munkájuknak. A Microsoft nem engedheti a DHTML-t tovább fejlődni: a gazdag kliens egyszerűen túlzottan veszélyes az üzletre. Manapság a Microsoft nagy mémje az, hogy „a Microsoft a gazdag kliensre fogad”. A Longhorn-os prezentációk szinte összes diáján megtalálhatod ezt. Az Avalon csapatában dolgozó Joe Beda azt mondja, hogy „az Avalon, és általánosságában a Longhorn a Microsoft alapvető érdeke, mondván, mi hisszük a desktop erősségét, hogy ott ülsz mellette, remek dolgokat tehetsz vele. Mi a desktopba fektettünk be, úgy gondoljuk, ott jó lenni, és reméljük, hogy ez új hullámot indít el…”.

Csak sajnos már túl késő.

Jómagam kicsit szomorú vagyok

Tulajdonképpen kicsit szomorú is vagyok ettől. Számomra a web nagyon remek, de a webalkalmazások a maguk sérülékeny, lassú, inkonzisztens felhasználói felületeivel nagy visszaesés a napi használhatóságot tekintve. Szeretem a gazdag kliensalkalmazásokat, és azt hiszem, beleőrülnék, ha a naponta használt alkalmazásaimat weben kéne használnom: a Visual Studio-t, a CityDesk-et, az Outlook-ot, a Corel PhotoPaint-ot, a QuickBooks-t. Ám a fejlesztők ezt akarják csinálni. Senki (hadd ismételjek: „kevesebb, mint tízmillió ember”) nem akar már Windows API-ra fejleszteni. A kockázatitőke-befektetők nem invesztálnak már Windows alkalmazásokba, mert túlságosan félnek a Microsoft-tal versenyezni. Meg aztán a legtöbb felhasználót látszólag nem zavarja annyira a gyengécske Web felhasználói interfész, mint amennyire engem.

Aztán itt van a non plus ultra: azt vettem észre (amit egy fejvadász ismerősöm meg is erősített), hogy a new york-i Windows API programozók, akik ismerik a C++-t és a COM programozást, kb. 130.000 dollárt kérnek évente, míg egy tipikus Web programozó, aki menedzselt memóriakezeléses programnyelvet használ (Java, PHP, Perl, vagy akár ASP.NET), kb. 80.000 dollárt keresnek. Ez hatalmas különbség, és amikor beszélgettem a Microsoft Consulting Services-beli régi barátaimmal, elismerték, hogy vesztettek egy egész nemzedéknyi fejlesztőt. Mivel 130.000 dollárba kerül COM-os tapasztalattal rendelkező fejlesztőt felvenni, senki sem vette a fáradságot, hogy megtanulja a COM programozást az elmúlt kb. nyolc évben, így csak egy öreg rókát tudsz szerezni, aki valószínűleg már a vezetésben csücsül, és arról kell meggyőznöd, hogy üljön be droidnak, hogy foglalkozzon a (Istenem, segíts) rendezéssel, elnevezésekkel, szálkezeléssel, csoportosítással és leválasztással, amit csak Don Box érthet meg, de amire már Don Box sem bír ránézni.

Nehezen mondom ki, de a programozók elég jelentős része már jó ideje weben fejleszt, és nem akar visszaváltani. A legtöbb .NET fejlesztő ASP.NET-et fejleszt, a Microsoft webkiszolgálójára írva. Az ASP.NET brilliáns: tíz éve dolgozom a webfejlesztésben, és ez tényleg generációs ugrás a legújabb technológiákhoz képest. Igen ám, de ez egy kiszolgáló technológia, és a kliensek akármilyen desktopot használhatják. Ráadásul egész jól fut Linuxon Mono alatt is.

Ez egyáltalán nem sejtet jót a Microsoftnak, és a profitjának, amit az API erejéből nyer. Az új API a HTML, és az alkalmazásfejlesztési piacon az új nyertesek azok lesznek, akik dalra fakasztják a HTML-t.