Za účinnou kampaň

Dopis předsedovi strany, kterou bych ještě před 5 lety nevolil ani omylem.

Date: Sun, 03 May 2009 23:53:38 +0200 (CEST)
From: Přemek Brada
To: mirek.topolanek@ods.cz

Vážený pane premiére,

chtěl bych Vám poděkovat za práci, kterou jste s končící vládou odvedl. Nebyl jsem (a zatím zřejmě ani nebudu) voličem ODS, k obsahu i formě vládnutí jsem měl občas vážné výhrady. Dokázali jste ale načít podstatné systémové změny a tím mi osobně dali naději, že vývoj v ČR začne jít rozumným směrem. Musím také uznat, že jste v mých očích do značné míry rehabilitoval ODS zpět do pozice racionální konzervativní strany.

Bohužel, současná situace mi naděje na blízkou budoucnost země dosti kalí, a styl některých čelných politiků ČSSD mě v podstatě upřímně děsí (viz Poslanci zatrhli zahraniční vojenské mise…, Rath chystá převrat. Deseti pojišťovnám hrozí zrušením). Nehledě na potenciální odklon od osy EU-NATO směrem k východu, který je z mnoha náznaků cítit a který mne (pamatuji socialismus velmi dobře) děsí v podobné míře. Domnívám se přitom, že začínající kampaň ČSSD – vedená v duchu kampaně do krajských voleb – bude velmi účinná právě svou jednoduchostí a populistickými hesly, která pomohla ke známému skóre 13:0.

Chtěl bych proto Vás požádat, abyste pečlivě zvážili obsah a styl kampaně ODS, která má zřejmě jako jediná strana šanci podstatně zasáhnout do momentálního vývoje. Myslím, že je potřeba jasně a prvoplánově oslovit hlavně střední vrstvy a zároveň dát určité ujištění všem nízkopříjmovým skupinám. Nestačí na to obecná hesla, nestačí na to negativní kampaň, nestačí na to “mobilizační propaganda”.

Rozumný volič – doufám, že je jich u nás stále aspoň polovina – hledá podle mého názoru pozitivně a konkrétně formulovaný program. Něco ve smyslu “vláda jako byla v r.2008 mi dává šanci na rozumný důchod” [člověk mezi 30-40], “tvořím hodnoty užitečné pro všechny, dávám práci 20 lidem, z mých daní se zaplatí provoz jedné školy, a středo-pravá vláda mi v tom pomůže pokračovat zatímco levicová mě znechutí” [živnostník-podnikatel], atd. Pozitivní a konkrétní program dává motivaci jít volit, negativní program bohužel nikoli (protože vyjadřuje pouze mezistranické souboje “těch nahoře”).

Zároveň bych považoval za velmi moudré, kdybyste se ve volební kampani nějakou formou aspoň volně podporovali s ostatními dvěma koaličními stranami, které Vás myslím mohou účinně podpořit jako partneři. Jejich roli v našem systému považuji za klíčovou, velmi pozitivní a velmi podceňovanou – Váš koaliční projekt i nedávné vyjádření mi dávají naději, že tento aspekt chápete.

Přeji Vám, pane premiére, dostatek sil a moudrosti ve Vašem rozhodování, a pokojný a šťastný osobní život.

S úctou
Přemek Brada

new 494 days ago / edit Jan 1, 01:33 / link

Integrating 3-rd party software with local modifications, using Subversion

(A rather long title, I’d say :-)

Anyway, most probably this has been described somewhere on the net, it’s just that I could not find it. So, first why and then how I went about it.

The problem to be solved

I use an open-source tool, call it T, and do my local modifications to it. What I needed was full tracking of both the T’s original distros and my changes in one repository, with merging upstream upgrades into the changes.

How to do it

Create repo structure like this:

The T/release-N.N directories are created by svn import <repo-url>.../T/release-N.N statements, fired in root directory of the T’s distro in that particular N.N release.

Assume we have T release 1.0 with local modifications in trunk (got there by e.g. svn copy from release-1.0, then comitting the mods). The task is to merge-in the “upgrade” to release 1.1 into our mod.

So, cd to trunk and do svn merge with URLs of the T/release-1.0 and T/release-1.1 as sources, and current (trunk) dir as destination. This takes head revisions on the import tags, makes their diff, merges that diff into the local modifications on trunk.

Footnote

It’s much easier with Mercurial

new Feb 27, 02:28 / edit Jan 1, 01:33 / link

Jak vypadá podvodný email (phishing)

Pěkný příklad phishingu čili podvodného emailu – tedy takového, který se tváří jako odeslaný z instituce (nejlépe co do činění s penězi) a přitom jen chce vylákat osobní údaje a/nebo přístup k účtu.

Následující phising email je také podrobně komentován na hoax.cz .

Screenshot podvodného emailu

Podle čeho se pozná, že je to phishing?

Užitečné odkazy

new Feb 26, 08:38 / edit Jan 1, 01:33 / link

J2EE Eintopf: Poučení z vývoje

V předchozím příspěvku jsem nastínil rozsah platformy Java Enterprise Edition – jaké technologie podporující tvorbu vícevrstvých aplikací zahrnuje a také, jaké jsou související aplikační rámce standardizované i volně vznikající. Tento článek je zamyšlením nad vývojem platformy enterprise Javy a z toho plynoucími poučeními.

Podoba Java EE platformy včera a dnes

Protože cílovým nasazením Java Enterprise Edition platformy byly vždy spíše právě “enterprise”, tj. velké, aplikace, je logické že podoba standardních služeb a aplikačních rámců tomu odpovídala. Nicméně, pod zdravým tlakem alternativních řešení došlo s příchodem verze 5 ke kvalitativně podstatnému posunu směrem k vývojářské jednoduchosti.

Nebudu se teď zabývat konkrétnostmi, ty se dají najít jinde (např. prezentace z Java Blueprints, úvodní článek na SDN). Podíváme se spíše na tři aspekty: historický vývoj platformy z hlediska dostupných technologií, jak se tento vývoj odrazil v typické architektuře Java EE aplikací, a jaká poučení z tohoto vývoje můžeme vyvodit.

Historie Enterprise Java platformy

Platforma Java Enterpise Edition oficiálně vznikla v roce 1999, když byla v prosinci vydána specifikace J2EE 1.2. (Jak už je zvykem, verzování ve věcech Javy není zcela souvislé ani logické — verze 1.0 ani 1.1 pravděpodobně nikdy neexistovaly.) Ta obsahovala základní technologie, které tvoří páteř platformy dodnes, mj.\ Enterprise JavaBeans (EJB), Servlety a JSP, Java Message Service (JMS), transakční API a služby, JDBC, Java Naming and Directory Services (JNDI). Je zajisté zajímavé, že hlavním architektem J2EE byl Vlada Matena, absolvent ČVUT Praha.

Následný vývoj J2EE platformy byl spíše evoluční, verze 1.3 (2001) a 1.4 (2003) přidávaly postupně nové technologie a vylepšovaly ty již zahrnuté.

Obrázek: technologie v J2EE 1.2
Technologie obsažené v J2EE 1.2

Obrázek: technologie v J2EE 1.4
Technologie obsažené v J2EE 1.4

Podstatnější změna nastala s verzí 1.5 respektive 5 vydanou v květnu 2006, do které se promítly novinky jazyka Java v jeho verzi 5 (distribuce JDK 5 vydaná na podzim 2004, zejména anotace. Ty umožnily podstatnou věc, a to vrátit definici komponent, nastavení aplikace, konfiguraci vazeb a další aspekty (definované rolí vývojář) z externích XML souborů do zdrojového kódu — enterprise aplikace se tak více přibližují POJO-stylu programování. Další novinkou je časté použití stylu Inversion of Control neboli Dependency Injection (na český překlad obou termínů se zatím čeká), tj. řešení závislostí mezi komponentami deklarací (anotace, setter) ve zdrojovém kódu — vlastní navázání na poskytující komponentu řeší kontejner.

Obě tyto věci byly dosud hlavní zbraní alternativních řešení, zejména platforem Spring a Hibernate. Jejich obliba mezi vývojáři zapříčinila následně tyto změny i v Java EE standardech. (Buďme jim za to vděčni, ať už preferujeme tu či onu platformu či aplikační rámec.)

Obrázek: technologie v JEE 5
Technologie obsažené v Java EE 5

Změny v architektuře J2EE aplikací

Nejprve tedy srovnání toho, jak vypadala typická enterprise aplikace v dobách J2EE 1.x verzí a jak vypadá nyní. Architekturu aplikace si ukážeme na schematech vycházejících ze vzorového Pet Store projektu z Java Blueprints.

Podoba pro JxEE do verze 1.4

V aplikaci jsou dobře separovatelné jednotlivé vrstvy (web, aplikační logika) podporované příslušnými částmi J2EE standardu.

Obrázek: Architektura aplikace - front controller, request processor, screen flow manager, web a EJB controller, HTML actions a EJB komponenty

Jednotlivé moduly můžeme namapovat na JxEE technologie takto:

Z architektury je přímo vidět jedna podstatná věc: že totiž mnoho modulů, které bylo třeba implementovat “ručně”, realizuje funkčnost čistě infrastrukturní a v takové či onaké podobě se proto budou vyskytovat v jakékoli složitější JxEE aplikaci — front controller, zpracování událostí (akcí, požadavků), řízení screen flow, skládání výsledné stránky z parametrizovaných šablon.

Přitom např. EJB implementace perzistence pro libovolný doménový objekt (např. zákazník) vyžaduje alespoň 3 třídy: vlastní EJB komponentu, “remote home” rozhraní a “local home” rozhraní; typicky k nim přibude ještě DTO třída pro komunikaci s webovou vrstvou.

Další podstatnou věcí je úroveň abstrakce na webové vrstvě. Servlety zpracovávají HTTP požadavky v podstatě na úrovni protokolu. Některé hodnoty (cookie, locale) dotazu jsou sice kontejnerem převedené do Java objektů ale obecně je potřeba převést parametry ručně do abstraktnější podoby. O něco lépe je na tom odpověď, kde v JSP stránkách jsou přístupné objekty vložené do kontextů (dotaz, relace, aplikace) i s jejich atributy a metodami.

Pro generování výsledného view musí řídící servlet provést v rámci obsluhy požadavku přesměrování na cílové JSP. Navigace je typicky “zadrátována” v kódu servletů a/nebo pomocných tříd; parametrizace je sice možná (web.xml deskriptor, properties soubory) ale není standardizována.

Implementace v Java EE verze 5

Aplikace je stále jasně dělená na webovou a aplikační logiku, ale mnoho “mezivrstev” odpadá.

Obrázek: Architektura aplikace - JSF controller s navigační mapou, EJB controller, JSF stránky, backing beans a EJB komponenty

Je vidět, jak většina věcí přímo nesouvisejících s aplikační logikou a prezentační vrstvou je schována do standardizovaných kontrolerů či kontejneru, které jsou dle potřeby parametrizovány (navigační mapa faces-config.xml). Navíc příchozí požadavky a jejich parametry jsou transformovány tak, že je přímo volán aplikační kód backing beany podle odpovídající akce provedené uživatelem na webovém rozhraní, a dostává atributy naplněné hodnotami z požadavku (typicky formuláře) díky mapování v JSF kódu. Programátor se tak nemusí starat o zpracování HTTP požadavku.

Co možná není na první pohled zřejmé je přeměna některých komponent z “řízených” neboli “těžkých” (zejména SLSB a EB(Entity Beans) ) do podoby normálních Java tříd čili POJO – vlastnost “býti komponentou” je implicitně definována anotacemi a kontejner ji zjistí pomocí introspekce. To jednak zjednodušuje celkovou architekturu (mizí množství pomocných rozhraní a XML souborů), za druhé ulehčuje práci programátorům (není nutno udržovat konzistenci mezi Java kódem a XML deskriptory). Přitom stále existuje možnost kterýkoli aspekt komponenty nastavit v XML deskriptoru, což se hodí pro konfiguraci – bezpečnost, transakční izolace, atd. – během nasazování aplikace.

Složitost JxEE: problém, nebo vlastnost?

Problémem Javy EE, který se verze 5 snaží řešit, tedy byla (do jisté míry stále je) složitost aplikací z pohledu vývojáře – to je vidět zejména na architektuře aplikací z dřívějších verzí platformy. Jeho hlavní rysy můžeme shrnout do následujících bodů:

Názory, které se těmto výhradám snaží (více či méně úspěšně) oponovat, lze shrnout takto:

K otázce složitosti technologie je možné ještě poznamenat jednu, zdá se mi opomíjenou, věc. Standard EJB explicitně definuje několik rolí, které se účastní procesu tvorby a provozu enterprise aplikací. Vývojář (zvaný “bean provider”) je jen jednou ze šesti. Ostatní role, které se ve světě enterprise Javy vyskytují (application assembler, deployer, system administrator), nehledě na zákazníky a uživatele aplikace, už takto vnímaná složitost pravděpodobně netrápí. Spíše je zajímá stabilita a výkon aplikace, resp. její konfigurovatelnost. V tomto ohledu pak poměrně jemná dekompozice architektury (vedoucí na složitost aplikací) a možnosti EJB kontejnerů vychází vstříc těmto potřebám.

Poučení a závěr

Když se na vývoj J2EE platformy dívám z mírného odstupu, vysvítá z něj vcelku zřejmé poučení: historie se stále opakuje, i v oblasti technologií, a málokdo si vezme z předchozích iterací vývoje ponaučení. Základní myšlenka J2EE je stále nosná – dát k dispozici robustní platformu pro vývoj aplikací funkčně velmi komplexních, a přitom výkonově škálovatelných a bezpečných.

Jak ale říká Rod Johnson v prezentaci Are We There Yet?, “v roce 2003 panovalo přesvědčení, že na to, aby mohla být technologie úspěšná, musí být i komplexní. Dnes už tomuto věří málokdo.” Původní J2EE poskytovalo potřebnou funkčnost, ale jednak pracovalo na abstrakčně nízké úrovni, za druhé bylo vymyšleno do značné míry “od stolu” standardizačním orgánem. (Podobnou technologií s chmurnějším osudem je např. CORBA – velké možnosti, velká složitost).

Vývojáři proto pochopitelně hledali řešení elegantnější (jednodušší programátorsky, přehlednější architektonicky). Tak vznikly konkurenční frameworky, které buďto řešily nedostatek dostupných abstrakcí (Struts) nebo přílišnou složitost (Spring). Tento přístup, který je možno shrnout pod anglická hesla “grassroots” a “back to basics”, se ukázal natolik životaschopný, že se v praxi rychle ujal.

Historie se opakuje – tentokrát s nadějným koncem

V tomto smyslu je vývoj J2EE velmi podobný jiným příběhům z oblasti výpočetní techniky a softwarového inženýrství. Vzpomeňme: protokolový stack ISO-OSI, čistý a přehledný, versus TCP/IP, snadno implementovatelné a efektivní. HTML 3.0, “dokonalé” ale nikdy neimplementované, versus HTML 3.2, následně přijaté pod tlakem reálného stavu. Vodopádový model životního cyklu sw projektu, navenek dávající projektu pravidla a řiditelnost, versus iterativní a zejména agilní metodiky (vycházející v podstatě z idejí modelu spirálového), které akceptují realitu přicházejících změn a charakteru vždy unikátního vývoje. Pravděpodobně by se našly další a další analogické příklady.

Naštěstí pro enterprise Java komunitu se v případě J2EE stala věc podobná situaci s HTML. Dotyčný “standardizační orgán” (Sun Microsystems a Java Community Process) pochopil vysílané signály, přehodnotil – dalo by se téměř říci s jistou pokorou – přístup, a přišel s řešením které zachovává kompatibilitu s předchozními verzemi standardu a přitom přejímá řadu nejlepších myšlenek vzniklých v “konkurenčních” přístupech.

Je tedy naděje, že Java Enterprise Edition verze 5 vrátí eleganci a stabilitu do vývoje velkých aplikací, a nevydá se cestou HTML 3.0 a ISO-OSI. Ostatně JBoss Seam a další štiky v rybníku dávají tušit, že nebude mít kdy usnout na vavřínech.

Zdroje a citace

[1] Is Java EE’s Complexity Its Worst Enemy?
[2] Analysts see Java EE dying in an SOA world
[3] Is the New Lightweight Java EE 5 Light Enough?
[4] Are We There Yet?
[5] Java EE 5 and SOA: The vendors strike back
[6] Towards Ease of Development

new Oct 21, 01:36 / edit Jan 1, 01:33 / link

J2EE Eintopf: Základní ingredience a doporučené přílohy

Anotace příspěvku, který budu mít 22. října na konferenci sdružení EurOpen 2007 — připravuji také pokračování pro tento blog.

Technologické základy platformy Java Enterprise Edition prošly od jejího počátku několika proměnami, základní principy pro tvorbu velkých aplikací podle třívrstvé architektury ale zůstávají víceméně stálé. Základní otázka při vývoji J2EE aplikací (zejména v případě vývoje “na zelené louce”) dnes proto nezní až tak “jak” ale spíše “s čím”: problém nevyzrálé technologie či neznalosti principů je nahrazen problémem orientace ve spleti technologií a aplikačních rámců (frameworků).

Cílem tohoto příspěvku je ve zkratce představit základní stavební kameny platformy J2EE, šíři technologií pod touto platformou zahrnutých nebo na ni navazujích, a vývojové platformy související i konkurenční.

new Oct 16, 17:41 / edit Jan 1, 01:33 / link

Trivially Enhanced CSS

Unaware of CSS-SSC and Switch CSS but frustrated by lack of reasonable syntactic sugar in CSS like many others, some time ago I created a trivial server-side filter to enhance CSS with one-line comments and constants.

So, here goes the ...

TE-CSS manual

Trivially Enhanced CSS Converter, version 1.0
Converts an enhanced CSS to the standard one. 
Copyright (c) 2007 Premek Brada 

The enhancements handled:
- // one-line comment
- @define CONSTANT value
- $CONSTANT expansion

Use the URI of the form 
  http://premek.abilo.net/tecss/?f=http://your.domain/your-style.css
to run your CSS through the converter.

The source is available under Creative Commons License .

So, what's the bonus?

In comparison with CSS-SSC, the TE-CSS adds the one-liner that enables to quickly comment-out a declaration (myself, I need this way too often).

It also lets you visually tell the user-declared constant from a built-in token of the CSS grammar, by using the dollar sign prefix. In this, it is similar to Christian Heilmann's approach but unlike it, the constant definition in TE-CSS is more in line with CSS's @at-rule syntax.

Unlike Switch CSS, it is implemented in the more ubiquitous PHP and far more lightweight (but also less powerful).

Open issues

Some things are most probably not ideal in TE-CSS:

new Aug 21, 12:53 / edit Jan 1, 01:33 / link

Zápisky z cesty do USA, díl třetí

Střípky a doderky, na které jsem si vzpomněl s lehkým odstupem času.

1. Pokud někoho překvapuje, případně mírně rozčiluje, lehce oslavný tón předchozích dvou povídání o USA jako takovém a MITu, pak na svou obhajobu mohu uvést, že (a) aspoň na ten letmý a nejspíš mírně povrchní týdenní pohled pracovního turisty to tam tak opravdu vypadá, (b) radši se v myšlenkách zaobírám věcmi inspirativními a zajímavými, než hnidopišstvím, (c) střízlivý obrázek si rád udělám, budu-li mít příležitost v oné velké zemi být slušně dlouho.

2. Nějakých pár fotek z cesty je v našem rodinném albu.

3. V New Yorku mě překvapila zcela zjevná přezaměstnanost – nikoli nezaměstanost. Jedna cca 200m dlouhá fronta na Empire State Building, a kolem ní tak 3-4 zřízenci, jejichž jediným úkolem bylo slovně postrkávat frontu k pohybu. Desítky prodavačů Hot Dogs na křižovatkách, třeba i 4 na jedné. A tak. Asi je to fakt bohatý kus země, když jich tolik uživí.

new May 16, 22:49 / edit Jan 1, 01:33 / link

Zápisky z cesty do USA, díl druhý

Několik postřehů z týdenní návštěvy v dubnu 2007. V tomto dílu o MIT jakožto univerzitě.

MIT – Massachusest Institute of Technology – patří k nejvýznamnějším světovým technickým univerzitám; koneckonců OpenCourseWare je příklad jeho leading edge role. My jsme měli možnost jej kvůli OpenCourseWare aspoň částečně “navzorkovat” zblízka a několik vzorků je tu stručně popsáno. Stálo to za to, podobně jako celá návštěva USA, o jejíchž obecných rysech píši v prvním dílu.

Mimochodem, Boston – na jehož území přišli první evropští osadníci v roce 1630 – drží dvě prvenství týkající se vzdělání: město v roce 1635 zřídilo první školu na území dnešních USA (Boston Latin School), a o rok později první vysokou školu, Harvard College. Samotný MIT je z roku 1861.

Univerzitní campus

Celý MIT je umístěn v Cambridge, na druhém břehu řeky Charles než je Boston (není tedy de iure v Bostonu), ve velkém trojúhelníkovém areálu. Ten ale není uzavřený, nýbrž je normální součástí města – ulice, obchody včetně několika knihkupectví, pošta, a tak. Takže když člověk něco potřebuje, nemusí “do města” jako na našem zeleném trojúhelníku.

Směřování univerzity

... of Technology je to klíčové slovo, které prodává MIT už dlouho. Nicméně v MIT Museum jsem našel poučné signály toho, že to tak nebylo vždy a nemusí být napořád:

(1) Do 40. let byl MIT pouze slušnou regionální technikou, po válce již významnou věděckou univerzitou. Její výzkumný potenciál ale klesal kvůli přílišné vytížeností kateder výukou a aplikovaným výzkumem. Sílu stát se světovou leading edge výzkumnou univerzitou získal MIT až v 50. letech 20. století díky podstatným grantům vládním i soukromým. (Viz panel Making a National Research University v kolekci The Making of MIT Scientists and Engineers)

(2) V současné době MIT zřejmě velmi aktivně reaguje na měnící se vnímání techniky, technologií a inženýrství vůbec, sloganově vyjádřeno přechodem od “Institute of Technology” k “University of Arts and Sciences”. Jednak “redefinuje význam titulu Bc. v oblasti přírodních věd, spojováním vědeckého a technického vzdělání s uměním, humanitními obory a společenskými vědami” a “započal rozsáhlý program přeměny univerzitního areálu s cílem podpořit kreativitu, spolupráci a komunikaci mezi různými disciplinami” (panel Inside MIT).

Podstatněji pak, hlavním cílem snažení přestávají být materiální věci (lodě, rakety, ...) a stávají se jím nápady na inovace, plánování, objevování. “Ve světě složeném ze systémů neobyčejného rozsahu a složitosti vyhledávají studenti vzdělání od MIT proto, že je naučí řešit problémy a stávat se leadery ve svém oboru.” (panel MIT in the 21st Century).

Praktický příklad: budova CSAIL

Naprosto odzbrojujícím a pro mě úchvatným příkladem tohoto zacílení na možnost komunikace a tvořivé spolupráce různých disciplin je nová (od roku 2004) budova Stata Center v níž sídlí Computer Science and Artificial Intelligence Laboratory (CSAIL) – výzkumná “laboratoř” spadající administrativně pod Department of Electrical Engineering and Computer Science tj. něco jako větší KIV.

budova MIT Stata Center

Co je na ní úchvatné? To, že ji nechali navrhnout Frankem O. Gehrym (jeho Guggenheim Bilbao jsem měl možnost vidět zvenku i zevnitř a byl jsem unešen). To, že na (barevných a křivkovitých) chodbách jsou volně k dispozici tabule pro čmárání. To, že z rozlehlého open space laboratoří jedněmi dveřmi vejdete do soukromí několika kanceláří a seminárních místností. To, že z rampy nad schodištěm vidíte o 2 patra níž do prosklené laboratoře, v níž jezdí roboti. To, na kolika plochách, barvách, křivkách a “vychytávkách” může oko spočinout a hlava nabrat osvěžení či inspiraci. To, že “kout” (asi tak 30m2) u jednoho z vchodů je věnovaný původní slavné Radio Lab budově č.20 a v ní vynalezenému radaru. To, že dnešní uspořádání kanceláří a laboratoří je možné by design poměrně snadno změnit, až se změní potřeby. To, že jedny vedlejší schody vedou na průběžnou výstavu digitálního umění s veselými i fascinujícími exponáty (viz níže).

... Zkrátka to, že velmi dobře funkčně promyšlená budova bude ještě za 100 let architektonicky zajímavá a navštívení hodná – ”(...) a work of architecture that embodies serious thinking about how people live and work, and at the same time shouts the joy of invention.” – a že v takovéhle budově může nějaký můj kolega bádat, diskutovat s kolegy a studenty, chodit na svačiny, chodit do ní do práce.

Praktický příklad č.2: Technické umění na MIT

O možnosti propojení techniky (počítačové) a umění, a to propojení velmi plodném, zajímavém, poučném až vtipném, jsem se přesvědčil při této návštěvě USA několikrát.

Poprvé v MoMA(Museum of Modern Art) v New Yorku na výstavě Digitally Mastered, kde byly mj. velmi vtipné interaktivní exponáty (člověk si “sám” hraje s počítačem, a na velké obrazovce nad ním vidí jeho hraní ostatní návštěvníci).

Podruhé v Stata Center, kde právě běžela výstava COLLISIONeleven – mezi “exponáty” byl např. magnetický panel s asi 12 “hokejovými puky” s diodou, která blikala podle blízkosti a umístění ostatních “puků” takže různé konfigurace, které si člověk mohl sám vytvářet, dávaly vznikat různým vizuálním vzorům a efektům; pojízdný pultík se skrytou dopřednou kamerkou a velkým monitorem, na kterém se snímaná scéna kreslila černobíle jako by ji črtal člověk tužkou od ruky; a také “expertní systém” který návštěvník natrénoval odpověďmi (ano/ne) na 3 otázky, pak mohl položit svoji otázku, a systém odpověděl ano/ne a vloženou otázkou přidal do trénovací množiny pro další návštěvníky.

Třetím příkladem propojení techniky a umění byly exponáty v MIT muzeu v kolekci Gestural Engineering. Většina byla v kategorii “hračiček” (např. Machine with Ball Chain), ale naplno mi krása propojení těchto nesourodých oblastí došla v exponátu Machine with Concrete. Jde o elektromotor, soustavu ozubených koleček, a betonovou kostku cca 4kg těžkou do které je pevně zakotvena osa posledního kolečka. Na vysvětlující tabulce je výpočet převodů se závěrem, že kostku stroj otočí (při stálém běhu na daných otáčkách motoru 212 ot/min) za … 2181 trilonů let ;-)

Optimistický dovětek

Pokusem s expertním systémem vystaveným na COLLISIONeleven jsem také dospěl k závěru, že případná budoucí budova pro FAV by mohla být funkčně i architektonicky podobně úchvatná jako Stata Center:

Q: Bude někdy v mojí vlasti postavená budova podobná této? A: Ano, s 97% pravděpodobností.

new May 2, 01:12 / edit Jan 1, 01:33 / link

Zápisky z cesty do USA, díl první

Několik postřehů z týdenní návštěvy v dubnu 2007. V tomto dílu o životě USA obecně.

Byl jsem v USA poprvé, a nejspíš proto byl pro mě týdenní pracovní pobyt v Bostonu a New Yorku (Manhattanu) velmi intenzivním zážitkem. Přesto, že jsem na cizinu poměrně zvyklý... Tady jsou tedy mé postřehy o USA obecně, seskupené do několika oblastí. (V dalším dílu povím pár věcí o MIT a univerzitách.)

“Nic velkého nám není cizí”

Velká země, hodně místa, dlouhá léta prosperity – it shows. Auta jako Volkswagen Touareg (který u nás vyčnívá) jsou normou – ve městě běžně potkáte Ford F-150 nebo Toyota Sienna. Když osobní, tak typicky sedany jako Lincoln – místo kombíku už raději SUV nebo velký pickup. Běžně s automatickou převodovkou, v All-Wheel-Drive verzích (i ve městě), s motory aspoň dvoulitrovými. Japonců hodně, evropská auta také, hlavně BMW, Audi, občas VW.

Hummer limousine

Jídlo levné a ve velkých porcích – ve fastfood eateries velmi často čínských nebo italských dostanete leckdy víc než sníte. Pití (coke, sprite, čistá voda) zásadně s ledem a brčkem a hlavně, normální “porce” je cca 1/2 litru – pokud chce člověk standardní třetinku (u Coke mi bohatě stačí) je třeba nezapomenout si o to říct předem.

Intenzita života zejména v NYC je strhující – “city that never sleeps” je přesné, plné chodníky lidí a ulice aut, mumraj, troubení, všechny barvy tváří které můžete znát, pulzující život. Přitom není problém se domorodce zeptat na cestu nebo se posadit v parku na trávník a posedět.

Chuť něco dělat, podnikat, zkusit to, makat a být dobrý. A přát druhým aby jim jejich podnik vyšel. Většina lidí jakoby z principu pohodových a přátelsky naladěných (včetně řidičů kterým chodci náhodně kříží cestu), takže není problém se dát s kýmkoli do řeči – srovnání s obecně spíše kyselými a trochu naštvanými Čechy je pro našince tristním poznáním.

Doprava, najmě automobilová

Velká auta už jsem zmiňoval. Vedlejším efektem velkých motorů je (aspoň to je má hypotéza) překvapivé ticho na plných ulicích – rozjezd 3,5litrového dieslu nového Jeepu Grand Cherokee je prostě tišší (nebo aspoň míň upištěný) než u 1,6litrové benzínové oktávky, natož vyježděné 1,3litrové felicie.

Typické jsou žluté taxíky a school busy. Typické je také metro – podobné spíš Londýnskému než Pražskému, t.j. žádná designová paráda, tmavé tunely a sešeřelá nástupiště, ale hustá pavoučí síť a silná orientace na funkčnost.

Co je také překvapivě typické je malý, řekl bych až minimální, počet dopravních značek. A ještě k tomu většina z nich je v podobě popisných cedulí, nikoli “obrázků” – typický případ je Right lane must turn right (pravý pruh odbočuje vpravo) místo našeho C 2b nebo Wrong way (Tudy ne) místo B 2. Pravděpodobný důvod je zjednodušení práce pro všechny účastníky – hlavně řidiči si nemusí pamatovat co který obrázek znamená, ale vědí, že když už nějakou značku vidí, je třeba ji brát vážně (opět porovnání s našimi sériemi omezení rychlosti a podobnými).

Coby chodec je člověk v pohodě (opět na rozdíl od Čech). Dodržování rychlostních limitů je až dojemné, a to je max. rychlost na dálnici cca 105 km/h (jen za dnešní volný den jsem v Plzni napočítal 5 jízd odhadem mezi 60-80 km/h). Řidiči vnímají chodce jako součást provozu a bez problémů jim zastavují, i když přechází mimo přechod, včetně kritické situace po odbočení z křižovatky tedy přecházejícím chodcům za zády. Stalo se mi dokonce několikrát, že řidič stojící na červené mi ukázal, ať přejdu, i když na přechodu pro chodce svítila červená. Když už jsme u toho, semafory na přechodu při zelené – respektive bílé – odpočítávají kdy padne červená, takže je vidět jestli se ještě vyplatí začít přecházet ;-)

Semafor na přechodu pro chodce Right lane must turn right

A ještě jedna chodecká: slavný systém číslovaných ulic (Street) a tříd (Avenue) na Manhattanu je sice asi nudný – žádná hezká, obrazotvorná a libozvučná jména – ale neuvěřitelně praktický. Hrozně snadno odhadnete, kde jste, jak daleko a jakým směrem je místo, kam potřebujete dojít. Stačí vědět, že z avenue na avenue to trvá cca 5 minut pěšky, a ze street na street něco jako 2 minuty. Že když vám někdo řekne 120 street tak to bude někde daleko na severu, protože Central Park začíná na 59. A tak – anglosaský pragmatismus v celé kráse ;-)

Historie a kořeny

Takzvaně shodou okolností jsme byli v místech, jejichž historie sahá do počátků osidlování USA angličany (Boston byl jednou z prvních kolonií). Díky tomu asi jsme kořeny dnešní Ameriky – vytrvalost kolonizátorů, boj za vlastní svobodu a nezávislost, fenomén přistěhovalectví a tavícího kotlíku čili melting pot – potkávali téměř denně (Boston: Freedom Trail vinoucí se městem, Boston Common, expozice o přistěhovalcích na vyhlídkovém patře Prudential Tower, Fan Pier, North End s “Old North” kostelem a Paul Revere Mall, USS Constitution; NYC: socha Svobody a Ellis Island, Battery Park, Broadway jejíž trasa kopíruje původní loveckou stezku místních indiánských kmenů).

NYC: Downtown Manhattan, Socha svobody a Ellis Island

Těžko tu směs hrdosti na minulost a přetrvávání jejích podstatných výdobytků popsat. Je vidět z toho, jak Američané sami navštěvují svoje historická místa. Z vlajek, které najdete všude. Z národní písně America. Z toho, na jakých hodnotových základech stojí jejich úspěchy.

Myslím, že výstižně jsou kořeny dnešních Spojených států shrnuty v článku o výročí 400 let Jamestownu (první britské kolonie) v týdeníku Time z 7. května 2007:

(...) Klíčové aspekty Jamestownu jako vzoru – zejména lákadla náboženské svobody, soukromého vlastnictví a určité míry samosprávy – zajistily, že britská severní Amerika měla dost [lidských] sil k obraně proti výzvám pocházejícím z Francie, Holandska a nakonec také proti pokusům jejich domovské vlasti převzít nad ní moc.

[První] osadníci (...) pracovali tvrdě a uměli přimět druhé pracovat v jejich prospěch. Byli pošetilí, draví a překvapivě tvrdohlaví. Když jedna věc nevyšla, zkusili jinou. Jsme jejich potomky.

A pak také Ground Zero, kde se historie potkává se současností v intenzitě málokde vídané. K pochopení toho, co Američan asi cítí na tomhle místě, je potřeba zavnímat to ohromné množství tvrdé práce (ano, včetně šikovných obchodů), které je skryto za velkolepostí dnešního Manhattanu, a mrakodrap ne jako symbol vyhloubačství ale národní hrdosti a kulturního dědictví (asi jako u nás hrady a zámky).

Ground Zero: socha Ground Zero: místo dvojčat

Těžko najít přirovnání v českých poměrech, ale dovedete si představit naše pocity, kdyby najednou namísto horního konce Václaváku s “Koněm” a Muzeem zel 30m hluboký kráter?

Nihil novum sub sole

Na odlehčení, v MoMA jsem našel jiný, hezký příklad spojení historie a současnosti: předchůdce dnešních mobilních “véček” telefonů ;-)

MoMA: Točítkový 'véčko' telefon z roku 1965

Downside, čili rub mince

Přestože celkový dojem z USA jako země, která věří v podstatné hodnoty a možnost úspěchu skrze práci, mám jednoznačně pozitivní, není možné nevidět odvrácenou stranu věcí. Ale nemám opravdu chuť být kyselým Čechem, který ze závisti nebo čirého škarohlídství vše dobré, nebo aspoň zajímavé, šmahem hodí přes palubu. Leccos jsem také neviděl, a nemohu proto svědčit a soudit. Proto je tenhle výčet kratší, než odstavce předchozí.

new May 1, 20:59 / edit Jan 1, 01:33 / link

Proč jsou otevřené formáty a protokoly lepší

Většina diskusí se točí kolem toho, zda/že “free software” je lepší než komerční varianty. Jakkoli považuji argument “pro open source” za důležitý a pádný, často to není jádro pudla. O co jde možná ještě více je, IMHO, možnost otevřeně komunikovat s druhými. Tomu jsou hlavní zábranou proprietární formáty a protokoly (nikoli closed-source software).

Stručně a jasně to shrnuje Hynek Hanke v již 5 let starém článku na Živě:

Šíření takových uzavřených formátů na veřejnosti je [ukázkou] netolerance vůči všem ostatním. [Když] komunikujete s lidmi, které neznáte, je třeba využívat otevřených formátů dokumentů, aby ten druhý měl možnost si je přečíst. Mluvím o možnosti číst jej i bez toho, aby musel kupovat zbytečně drahý produkt nějaké společnosti. ... [Ta si] nezveřejněním specifikací a donucením uživatele k užívání takového formátu velmi snadno zajistí monopolní postavení v dané oblasti.

Přitom jde o taktiku velmi hloupou, neboť šikovný formát ukládání dat nebo protokol pro jejich výměnu ještě sám o sobě nic nemusí znamenat, důležitý je dobrý software, který jej využívá. A tady nic nebrání vzájemné konkurenci otevřeného a komerčního software, kde ten druhý může účinně vítězit a svému tvůrci vydělávat.

(Moje osobní zkušenost je, že bych rád používal OpenOffice kvůli jeho ODF ale kvůli použitelnosti a propracovanosti raději volím Microsoft Office. Což je, abych tak řekl, sad story.)

Takže tedy transparent do manifestace:

P.S.

Pár odkazů, které jsem nasbíral, když jsem se snažil vygooglit něco na tohle téma.

new Aug 22, 10:23 / edit Jan 1, 01:33 / link