Programátoři u pásu a na verpánku
Publikováno 19. 10. 2005 v Hospodářských novinách a 20. 10. 2005 v týdeníku Ekonom
Na dnešní obchodování s vývojem softwaru se dnes nahlíží jako na továrny první poloviny dvacátých let minulého století. Vývoj softwaru může leckomu připomínat pásovou výrobu: Je to dobře nebo špatně? Je softwarové inženýrství opravdu ryze technický obor? Umí dnešní firmy nakupovat software?
Když se v šedesátých letech poprvé objevily programovací jazyky Fortran a později Cobol a Basic, průmyslová výroba byla právě na vrcholu. Dělníci u pásů v automobilkách BMW a General Motors pracovali na směny a ropa byla nejžádanějším energetickým artiklem na světě. Průmyslová revoluce hledala ke svému růstu neustále nová média, nové a nové prostředky umělého růstu. V jejích žilách kolovala nejprve pára, poté elektřina, nakonec ropa a dnes jsou to informace. Informace se záhy staly klíčovou složkou metabolismu moderní společnosti, její hnací silou. Ještě než se průmyslově řízená společnost zaměřená na masovou výrobu stačila rozkoukat, informace se jako nenasytný karierní dravec propracovaly z podřízené pozice až k pozici nejvyšší. Kdo má informace, má moc.
Přestože revoluce informačních technologií podkopala pozice své zvolna stárnoucí průmyslové matky, sama ještě překonává pubertu. Mnohé dnešní »dotcomy« a firmy produkující software v samém srdci tohoto hurikánu mohou někdy připomínat továrny první poloviny dvacátého století.
Slovo soft-ware by se dalo otrocky, ale výstižně přeložit jako ne-hmotná věc. Stejně jako ideje musí být formulovány slovy a písmem, každý software je vytvářen pomocí programovacího jazyka. A stejně jako se lidé učí mluvit mezi sebou, učili se mluvit i s počítači. Programovací jazyk pro vývoj softwaru je formálně sdíleným komunikačním nástrojem mezi programátorem a počítačem, který formuluje řešení v podobě souboru pravidel pro zápis algoritmu. Algoritmem pak rozumíme vlastní postup řešení úlohy, kterou chceme, aby počítač řešil místo nás.
Podívejme se tedy pod pokličku světa, kde se místo rukou a běžících pásů užívají mozky a myši.
Software – návrat »věku idejí«
První generace programovacích jazyků byla charakterizována binárním kódem a byla velice náchylná k vysokému procentu chyb. Jednoduchý algoritmus se zde měnil na sáhodlouhý kód.
Jazyk symbolicky konstruovaného kódu přišel v polovině padesátých let jako generace druhá. Jde například o jazyky AUTOCODER, SAP a SPS. Mezi léty šedesátými a osmdesátými přišla generace třetí. Jazyky jako ALGOL 58, 60 a 68, COBOL, FORTRAN IV, ADA a C se staly prvními reprezentanty tzv. »high level languages«. Jejich největším přínosem byla rychlost a nezávislost, to znamená, že poprvé vyřešily vynucené dilema svých předchůdců. Byly totiž univerzálně použitelné a přenosné mezi různými typy počítačů. Do té doby musel každý programátor používat jazyk příslušný k určitému typu počítače, což pochopitelně bránilo také rozšíření počítačů a jejich zlevnění.
Čtvrtá generace jazyků už s sebou nesla náročné požadavky: být uživatelsky přívětivá, přenositelná, nezávislá na operačním systému, použitelná pro ne-programátory, atd. Příkladem této generace jsou ADRS2 od IBM, APL, CSP a AS, Power Builder, Access. Devadesátá léta, která přinesla pátou generaci v čele s PROLOGem, odkazovala již na systémy umělé inteligence, tzv. fuzzy logiku a neuronové sítě. Slouží k tomu, aby systémy mohly inteligentně rozhodovat o svém vlastním procesu. Umožňuje produkovat špičkově inteligentní samoučící software.
Džavíci a dotneťáci
Koncepty, cykly, objekty, a jiné hierarchické entity programovacích jazyků jsou v řádu desetiletí spíše dlouhodobě platné, protože jazyk sám se většinou v mainstreamu drží nejméně deset let a ještě dalších deset přežívá. Co se ale drasticky mění, jsou technologie a nástroje, pomocí nichž se jazyk vyvíjí.
Pokud jde o královny trhu, o své místo na slunci v užívání jazyků (dnes už spíše programovacích technologií) se samozřejmě perou giganti. Nejpopulárnější platformy jsou dnes .Net a JAVA. JAVA je univerzální softwarová platforma, jejíž standard uvedla na trh společnost Sun v roce 1995. Umožnila vývojářům, aby napsali jednu aplikaci (program), která poběží na jakémkoli počítači. Velcí hráči jako IBM, Oracle a jiní se stali kmotry této nové platformy a zasloužili se o její okamžité rozšíření ve vývoji tzv. »enterprise« aplikací (aplikace pro podniky). Microsoft byl nucen na příchod JAVY zareagovat a dal k dispozici dnes již velmi populární »dotnet,« jenž se píše .Net. Jde o vývojovou platformu obsahující sadu programovacích technologií MS – od serverových aplikací, přes technologie webových služeb, XML, až po tzv. chytré klienty či vývojové nástroje.
Zatímco JAVA je více založená na standardech sdílených různými společnostmi a je tudíž hodně otevřená, konkurenční platforma .Net je v jádru spíše proprietární technologií Microsoftu. »Džavisté« a »dotneťáci« jsou dnes nejvyhledávanější specializace mezi programátory. O práci se jim postaraly marketingové úspěchy současných tržních vlčáků, firem Sun, Oracle, Microsoft, IBM a dalších.
Není vůbec jisté, kdo bude poptávce kralovat za takové dva roky. Existují spousty firem, které jsou velmi rezistentní vůči změnám systémů (letecké společnosti, banky, aj.) a jejich systémy často i deset, dvacet let fungují na stejné vývojové platformě (dnes se mnohdy ještě v bankách objevuje »stařík« COBOL). Současný trend spočívá tedy především v integraci aplikací, které pomocí webových služeb stírají rozdíly mezi platformami tak, aby spolu mohly bez problémů komunikovat.
Dřevní doby...
Prvním uceleným systémem řízení softwarového vývoje byla tzv. vodopádová metodika. Její nástup byl předznamenán světovou softwarovou krizí koncem šedesátých let. Průvodními znaky krize bylo neúnosné prodražování vývoje, nízká kvalita, nemožnost údržby a inovací, nízká interoperabilita, nejistota výsledku. Software jako produkt budil obrovská očekávání, ale stejně jako s prvním dítětem v rodině, ani zde nikdo nevěděl, jak novorozence nejefektivněji nakrmit a vychovat a nedopouštět se při tom zásadních chyb. Pouhá tři procenta vyvinutých produktů mohla být bez výhrad použita. Zbytek byly nekonečné předělávky a odpad. Byla to jak procedurální krize, tak krize důvěry v software jako v užitečný produkt.
Mezi nejkritičtější důvody, proč krize nastala, byla všemi experty zařazena špatná komunikace, tedy obor navýsost humanistický a netechnický. Komunikace s klientem, komunikace týmu a komunikace ve vývojářské firmě...Hned v závěsu za tímto hlavním důvodem šla neexistence metodik, pomalý postup vývoje a tak dál. Program nebyl jednoduše dělitelný na části. Ve vývojářském žargonu se tomu přezdívalo »spaghetti code«, nekonečný, nerozebratelný, nestrukturovaný kód. Jedním z budoucích řešení byly nakonec tzv. objekty, které umožnily dekomponovat systém a vytvořit v něm řád.
Velký pokrok znamenalo zavedení tzv. objektového programování a aplikace metodik. V dřevních dobách vývoje také neexistovala funkce analytika a zákazník komunikoval přímo s programátorem. Výsledkem byl produkt, který se líbil pouze programátorům, ale nedal se nikde prakticky použít. Dnes je funkce analytika (který identifikuje pro zákazníky nejlepší řešení) na pracovním trhu ceněna víc, než funkce samotného programátora. V mezičase se totiž silně diferencovaly a rozvinuly úlohy ve vývojovém týmu. Programátor (ten, kdo napíše kód) bývá jen zřídka schopným analytikem a jen výjimečně je schopen tzv. business analýzy, tj. být zákazníkovi partnerem, tím, který pochopí jeho byznys do detailu a doporučí mu sám správné a obchodně efektivní softwarové řešení. Pokud nějaký programátor ve své osobě tyto dovednosti zahrnuje, vyvažují jeho talent firmy zlatem.
OOP a voříšci
Objektově orientované programování (zkracováno na OOP, z anglického Object-oriented programming) je převratné a nové paradigma vývoje softwaru, založené na následujících principech:
- Objekty – jednotlivé prvky modelované reality (jak data, tak související funkčnost) jsou v programu seskupeny do entit, nazývaných objekty. Zatímco v procedurálních jazycích byly pouze funkce, v objektových jazycích pracujeme s objekty jako je »auto«, »letenka«, »faktura« a jiné... Zatímco při čtení programů funkcionálních šlo o nesrozumitelný zápis, čtení programů objektových umožní na první pohled rozpoznat, jakou funkcionalitu program vytváří.
- Abstrakce – vývojář může s objekty pracovat na různých úrovních abstrakce. Zatímco někdy ho zajímá jen existence objektu, jindy ho může zajímat i funkcionalita a vnitřní implementace. Nemusí být tudíž ponořen do nejnižších úrovní konstrukce každého objektu.
- Zapouzdření – stav objektu lze měnit pouze podle pravidel, které si objekt sám definuje. Ostatní objekty nemají možnost měnit stav objektu jinak, než použitím těchto pravidel a tudíž je vyloučeno, že by se objekt dostal do nekonzistentního stavu.
- Polymorfismus – objekty obsahují stejnou operaci v rozhraní, ale každý na ni reaguje svým vlastním způsobem.
- Dědičnost – objekty jsou organizovány hierarchickým způsobem.Vytváří se mezi nimi vztah generalizace – specializace, kdy specializované objekty jsou variantou svého nadřízeného objektu a jsou určeny pro specifické použití.
Jak bylo uvedeno výše, OOP je označováno jako programátorské paradigma, neboť popisuje nejen způsob vývoje a zápisu programu, ale i vyžaduje jiný způsob myšlení a náhledu na konstrukci programu. Tento způsob myšlení je mnohem bližší realitě než tomu bylo v programování funkcionálním.
Při vývoji složitých informačních systémů s pomocí OOP mohou dnes jednotliví vývojáři používat již vytvořené komponenty, podle potřeby si je trochu upravit nebo je používat jako stavebnici pro sestavování důmyslnějších a složitějších objektů. Toto spíše teoretické tvrzení je však v praxi zatím realizovatelné velmi obtížně.
V současnosti existuje velké množství programovacích jazyků, umožňujících objektově orientované programování, např. Smaltalk, Java, C++, Object Pascal, C#, PHP a další. »Objektově programovat« je »trendy« už mnoho let, bohužel také díky tomu, že dnešní »objektové jazyky« umožňují programátorům programovat stále funkcionálně.
Vznik objektových jazyků sice spadá už do sedmdesátých let, ale jejich boom nastal až v letech devadesátých. Nejvýznamnějším beranidlem jejich rozšíření byly paradoxně samotné jazyky funkcionální, které do své struktury začaly objektové principy přejímat. Ve výsledku to tedy vypadá, že naprostá většina současných programů je kombinací funkcionálního a objektového přístupu, jsou to prostě »voříšci«.
Kuchařky na vývoj SW
Od dob, kdy byl do vývoje postupně zaveden systém, formalizovaný pod názvem softwarové inženýrství (v USA uznáno jako samostatný obor až v roce 1997), se velice proměnily metodiky vývoje. Původní a nejstarší metodou je již zmíněné kaskádové programování – The Waterfall Model. Jednotlivé segmenty vývoje jdou logicky za sebou a podporují vzájemnou časovou posloupnost v tomto pořadí: Definice problému – specifikace požadavků – návrh – architektura systému – řešení – implementace – integrace – provoz. Dodnes se tato metodika používá u některých velkých projektů, kde je dostatek času a kde existují nároky na posloupnost a přesnost vývoje.
Jak postupovaly nároky zákazníků a zrychlovalo se tempo vývoje celého sektoru, začala být metoda kaskádového přístupu na obtíž kvůli časové, finanční a personální náročnosti. Skutečný přelom znamenal tzv. spirálový model z roku 1985, předchůdce dnešních agilních metod. Do procesu vývoje zavedl iterativní přístup a důslednou analýzu rizik. V praxi totiž vývoj softwaru naráží stále dokola na fakt, že plán a realita jsou si na hony vzdáleny. Původní inženýrské metody průmyslové revoluce se totiž hrubě vzpírají nasazení ve světě informací. V úvodním zadání bývá například téměř nemožné dopodrobna analyticky specifikovat všechny požadavky a funkce, které musí systém mít. Málokterý zákazník si dokáže brilantně specifikovat všechny své požadavky na systém předem.
Nejprve se tedy musí stanovit obecný rámec, scope projektu. Následně se vyvine část aplikace (první iterace) a pokračuje se detailní konzultací se zákazníkem, který nejlépe pojmenovává své potřeby tváří v tvář navržené kostře produktu. Vývoj tedy probíhá v opakovaných krocích, tzv. iteracích.
Na těchto metodách také staví dnes hojně užívaný systém RUP (Rational Unified Process. Ten vyvinula firma Rational, kterou briskně převzala IBM). RUP je jakousi pohodlnou kuchařkou pro různé typy projektů vývoje SW, od malých aplikací až po megasystémy.
XP znamená eXtreme Programming
Novou vlnu vývoje pojmenovala tzv. Agilní aliance, skupina úspěšných amerických a britských programátorů (více na www.agilealliance.com). Agilní metody, či spíše aktivní souhrny zkušeností programátorů s vývojem, reagují hlavně na šílené tempo vývoje internetových aplikací a na hlavní kritérium: rychlost dodání a schopnost pružné reakce na změnu. Změna je zaklínací formulí těchto metod. Mezi agilní metody patří tzv. extrémní programování, Lean Development (dosud nemá český překlad), FDP-Feature Driven Programming (funkcionálně řízené programování), TDP – Test Driven Programming (programování řízené testováním), a mnohé další.
Požadovaného výsledku se zde dosahuje principem hry, užíváním přímé namísto formalizované komunikace, naprostým omezením administrace, minimalizací porad, častými revizemi, flexibilním předmětem dodávky (»scope« se posouvá v čase a uvnitř rozpočtu zakázky), flexibilním harmonogramem, přenesením rozhodování na nejnižší možnou úroveň, atd. Ne náhodu tyto metodiky uvedli v život sami vývojáři, kteří zúročili svou dlouholetou zkušenost s lidskými vlastnostmi v procesech (tvůrčí člověk se skoro nikdy nepřizpůsobí dvourozměrně formalizovanému plánovacímu procesu).
Tento druh práce se ovšem nehodí pro každého programátora: vyžaduje odvahu dělat chyby a rychle chyby reportovat, měnit nacvičené postupy a zkoušet nové kroky, dobrou analytickou schopnost a rychlost orientace v novém prostředí, schopnost myslet »hlavou klienta«. Takových programátorů dnes mnoho není. Je to také metodika riskantní co do způsobu, jakým je nutno projekt řídit, protože se snadno může vymknout kontrole...
Ale metodiky samy nejsou samospasitelné. Bylo to mimo jiné i netvůrčí užívání metodik, které vedlo ve velkých dotcomech přelomu tisíciletí ke splasknutí nadhodnocených investic. Nesprávně aplikovaná metodika se i dnes stává největší brzdou efektivního vývoje...
Představme si jen, že na každý kus masa na pánvi v různých typech restaurací aplikujeme typizovaný recept smažení hamburgeru, který direktivně stanoví pro své restaurace McDonalds. Spokojen bude jeden host ze sta... zbytek odejde – v lepším případě.
schéma: základní principy – srovnání tradičního a agilního přístupu
Továrny v zahradách
Světově proslulý vyhledavač Google postavil svou image na žurnalistické kampani o neuvěřitelně liberálních pracovních podmínkách ve své firmě. Svět obletěly záběry pracoven v zahradách s pingpongovými stoly a vodotrysky. Každý, i ten, kdo do té doby o IT nikdy neslyšel, si řekl: »Ach, tam tak jednou pracovat...«
Vytvořit programátorům správné prostředí pro optimální výkon je jedna z mnoha věcí, kterou musí dnešní manažer vývoje zajistit. Každý ví, že člověk, který pracuje jen hlavou, potřebuje minimálně 15 minut, než se dostane do »zóny«, jak říká Joel Spolsky. V tomto stavu soustředění produkuje tvůrčí pracovník díky absolutní koncentraci maximálně kvalitní výstupy. Stačí zazvonění telefonu, porada, řev kolegů či nevhodný dotaz spolupracovníka a je třeba dalších 15 minut, než se člověk do zóny znovu dostane. Dnešní moderní Open Space kanceláře snižují v tomto ohledu intelektuální výkon a vyhovují spíše manažerům, kteří chtějí mít kontrolu a přehled. Na jedné straně nemusí programátoři běhat s dotazy ke kolegům, na straně druhé si vzájemně neustále »trhají nit«... Unavený, rozzlobený nebo vystresovaný programátor se do stavu soustředění nemusí dostat vůbec a stráví den čtením internetových diskusí a »pokecem« s ostatními na ICQ. Příměr k práci u pásu tedy kulhá, pokud jde o dosažitelnost stabilního výkonu. Ruce se při velké únavě spíše zraní, zatímco hlava prostě vypne nebo pustí ke slovu »autopilota« a čte si comicsy. A majitel vývojářské firmy si toho musí být vědom. Rychlost a kvalita jsou požadavky, které kladou na hlavu programátorů, analytiků a testerů extrémní požadavky. Hlava nemusí být schopna těmto extrémním požadavkům vždy dostát.
Kdo nic nedělá, nic nezkazí
Trochu stranou pozornosti stojí úloha testerů, tedy lidí, kteří jakoby tahají se zákazníkem za stejný konec provazu. Jejich práce je při vývoji zcela nezbytná. Zde si musím vypůjčit příklad, který spadá spíše do vývoje produktů, než do aplikačního vývoje na zakázku: Vývoj úplně první verze MS Windows byl prý považován za »pochod smrti«, stále se odkládalo dokončení. Když byla první verze po mnoha letech dokončena, poslali manažeři celý tým na dovolenou do Mexika a tam zpytovali svědomí. Nač přišli? Manažeři tak rigidně trvali na dodržení »harmonogramů« a tlačili na programátory, aby dodrželi naplánované časové normy, že programátoři psali pod tlakem extrémně špatné kódy plné chyb. Nikdo se už nesnažil udržet počet chyb na rozumném čísle. Poučen tímto přístupem, zavedl Microsoft tzv. »ZERO-DEFECT« přístup. Podstata metody byla prostá – v jakýkoliv okamžik je nejvyšší prioritou odstranění chyby, dřív, než se začne psát nový kód.
Proto je nezastupitelná úloha dobrého testera, který přebírá po každém programátorovi čočku a proso a do omrzení hlásí počet, umístění a závažnost chyb.
Prodej aplikací: »Můžu to tak nechat?«
Plán je v programování odjakživa jen pasivní funkcí reality. Až to bude, tak to bude, křičí programátoři všude na světě. Ale s tímto přístupem by obchodníci nebyli schopni prodat ani mřenku. Obecně lze říci, že vývoj aplikace je třeba adaptivně podřídit velikosti a požadavkům klienta a jeho rozpočtu. Současní lídři na trhu trpí známou nemocí, které se mezi vývojáři přezdívá silážní jáma. V praxi to znamená, že klient do vývoje vloží nějaký rozpočet a očekává za tyto peníze nejlepší výsledek na zeměkouli. Během vývoje pak vychrlí množství nadbytečných i zcela případných požadavků, které vývoj zkomplikují a prodlouží, není-li dobře nastaveno a laděno jeho očekávání. Ne každá vývojářská firma se přizpůsobuje rychle a vývoj se pak prodlužuje a prodražuje. V půli vymezeného času obyčejně (a bývá to u některých firem spíše pravidlem) přijde dodavatel s požadavkem o navýšení rozpočtu o padesát, nezřídka i sto procent. To je bohužel zcela běžný model na současném trhu. Jeho konzumenty jsou převážně banky, telekomunikační společnosti, a giganti s vlastními odděleními IT, kteří jsou zběhlí v zadávání softwarových zakázek a jsou s tímto nepříliš štastným modelem smířeni. Za to dostávají jistotu početných a prověřených týmů, které nejsou narychlo sesbírány na ulici a které garantují, že nevznikne odpadní produkt.
Jiná situace však nastává v přechodu na tzv. retail, který tvoří novou, neprozkoumanou a dosud neobsazenou část trhu. Malé dravé firmy, které potřebují ke zlepšení pozice výkonný software, mají neanonymní vlastníky a přísně kontrolují své rozpočty, budou mnohem náročnějšími klienty. Z vlastní zkušenosti mohu říci, že práce s tímto druhem klientů se zcela vymyká běžně zavedeným postupům a hledání cest mezi agilními a klasickými metodami vývoje spolu s vytipováním speciálně »vycvičených« programátorských týmů je klíčem k úspěchu. Retailoví klienti nejsou na vnitřní formalizované postupy zvědaví, zajímá je jediné: čistý finanční přínos zavedení softwaru do jejich byznysu. Množství týmových funkcí a dodržování nepružných postupů komunikace vývoj pro malé klienty zbytečně prodražuje a devalvuje obchodní přínos pro obě strany. U klientů i u dodavatelů pak dochází k frustracím. Klient si připadá zklamán, protože neumí řídit svá očekávání a naděje, které do vývoje SW vkládá. Dodavatel je zklamán, protože každý den vývoje navíc mu snižuje zisk z »malé« zakázky. Pro mnoho malých firem zůstává stále jediným dodavatelem »obýváková« »one man company« s mizivou kvalitou, ale rychlým dodáním. I to se však může změnit. Firmy se totiž musí naučit nakupovat software a velké vývojářské firmy se musí naučit vyvíjet »v malém«. Stejně jako zadat stavbu domu a správně si zvolit stavební dozor, musí být i menší firma schopna držet se pravidel a zkušeností, které v této oblasti postupně vznikají. Nebude to ze dne na den, jak vývojáři, tak menší klienti si na sebe a na své vzdálené vesmíry musí nejprve zvyknout. Nový styl vývoje aplikací stojí na výchově nového druhu vývojářů a na jejich cíleném vyhledávání. Nasazení testerů a iterativní přístup hned od počátku vývoje je pak naprostou samozřejmostí. Stejně jako v moderních metodách řízení armád, i zde by mělo platit: Rozhoduje ten, kdo má nejvíce přímých informací o situaci na bojišti. Tedy ten, kdo je momentálně klientovi nejblíže. Nejlépe analytik a programátor v jedné osobě.
První, komu se podařilo sestrojit fungující počítací stroj, byl Němec Konrad Zuse. Roku 1938 spatřil světlo světa první počítač nazvaný Z1. Byl ještě elektromechanický s kolíčkovou pamětí na 16 čísel a byl i poněkud nespolehlivý, pro praktické použití nevhodný. Zuse proto přistoupil ke stavbě počítače Z2, poté i Z3. Počítač Z3 byl v roce 1944 zničen při leteckém náletu. Přibližně ve stejné době pracoval ve Spojených státech na podobném projektu Howard Aiken. Celý projekt financovala firma IBM (International Business Machines), jejíž produkt, označovaný jako PC se stal synonymem slova počítač. Patnáct metrů dlouhé monstrum představovalo trilobita, který v praoceánu předznamenal nový život.
V roce 1944 byl na univerzitě v Pensylvánii uveden do provozu první elektronkový počítač ENIAC. Vážil 40 tun a představoval tzv. první generaci. Druhá generace počítačů (1959 až 1964) spatřila světlo světa v AT&T's Bell Labs s vynálezem tranzistoru, který dovolil díky svým vlastnostem zmenšení rozměrů celého počítače, zvýšení jeho rychlosti a spolehlivosti a snížení energetických nároků počítače. V této generaci počítačů také začínají vznikat operační systémy a v šedesátých letech první programovací jazyky, jako jsou například Fortran, Cobol, Basic a další. Robert Noyce z Fairchild Corporation a Jack Kilby z Texas Instruments nezávisle na sobě odstartovali třetí generaci (1965 až 1970) vynálezem integrovaného obvodu.
Symbolem čtvrté generace (1971 až dosud) se stal mikroprocesor. Tuto generaci poznamenala překotná miniaturizace a prudký pád cen ve zkracujících se intervalech.
V roce 1982 vznikla také společnost SUN s prvními třemi zaměstnanci. Jejich první pracovní stanice obsahovala standard TCP/IP, dodnes používaný jako sada internetových protokolů. Velký boom tehdy odstartovaly společně IBM, Apple a Sun. Skok spočíval v tom, že se lidé v těchto začínajících firmách rozhodli dělat malé počítače »pro lidi«, nikoli monstra pro vědecké účely.
Prvním počítačem vyrobeným v naší republice byl SAPO (SAmočinný POčítač), který byl uveden do provozu v roce 1957. Obsahoval 7000 relé a 400 elektronek. Měl magnetickou bubnovou paměť o kapacitě 1024 dvaatřicetibitových slov. SAPO byl zkonstruován prof. Svobodou a jeho spolupracovníky ve Výzkumném ústavu matematických strojů a byl instalován v budově ústavu na Loretánském náměstí.
Webové služby jsou vlastně krátké kódy, které uživateli mají zprostředkovat a umožnit sdílet data.
