sobota 22. prosince 2007

Zbytečná skepse kolem skriptovacích jazyků

Po posledním CZJUGu jsme řešili využití skriptovacích jazyků a překvapila mě velká skepse všech diskutujících. Tuto skepsi volně vystihuje článek Skriptovací jazyky v Javě - co s nimi? na Blogu o javičce. Zkusím tedy tuto skepsi trochu rezprášit.

někdy jsou světy Javy a skriptovacího jazyka natolik rozdílné, že to nelze v některých jazycích vůbec implementovat nebo za cenu ne úplně ideálního kódu. Myslím například anotace v Javě.

Je chyba přemýšlet o skriptovacích jazycích jako o náhradě Javy. Skriptovací jazyky jsou samozřejmě pouze vhodným typem doplňku k Jave. K tomu se dostanu později.

větší nároky spojené s údržbou aplikací. Dříve stačilo umět jen Javu, ale teď k tomu potřebuji znát ještě minimálně další jazyk.

Pravda. Položme si ovšem otázku, jak drahé je najmout si člověka, který ovládá J2EE Javu a někoho kdo zvládne například JavaScript? Odpověď nechám na vás...

často se uvádí slabší výkonnost skriptovacího enginu s JVM oproti nativnímu enginu samotnému. Je to dáno tím, že je potřeba provádět řadu kontrol a konverzí mezi oběma světy. Toto např. neplatí úplně pro Groovy, což je jen taková jiná Java.

Slovy klasika: to za nás vyřeší Intel

Takže k čemu já to jen využiji? I když si dokážu představit, že určité části aplikace napíši rychleji např. pomocí Groovy, tak jsem asi moc konzervativní, ale mě to zase taková výhoda nepřijde. Já mám svoji Javu rád :), takže si všechno napíšu v ní. Když to nebudu brát jen z mého osobního pohledu, tak přeci jen otázka údržby aplikace je hodně významná a s použitím více jazyků a technologií se tento problém stává těžší a komplikovanější (a tedy nákladnější). A když už budu psát část aplikace pomocí skriptovacích jazyků, tak proč už to pak nenapíšu celé jen pomocí skriptovacího jazyka?

I já mám svojí Javu rád a právě proto skriptovací jazyky vítám, ale zpět od citových výlevů k faktům. Začnu trochu ze široka. Položili jste si někdy otázku, co stojí za překotným tempem v přijímání nových syntaktických cukrátek? Já osobně si myslím, že to je právě efektivita ostatních jazyků. Jednou z největších výhod Javy, jako jazyka, byla konzervativnost a velice jednoduchá syntaxe. Rozšiřováním syntaxe Javy se všech těchto podstatných výhod zbavujeme. Přijde mi lepší nechat tento boj o efektivitu vybojovat skriptovací jazyky a ty nechat spolupracovat se starou dobrou Javou nad JVM.

Skriptovací jazyky se nehodí na všechny typy úloh, ale můžeme vzít jako příklad systém, který je potřeba podle zákaznických požadavků modifikovat (customization).

  • Uděláme jádro systému, které bude zajišťovat klíčové vlastnosti systému, bez ohledu na to, co zákazník vymyslí. To jádro bude pravděpodobně zajišťovat přístup k datům, řídit transakce, dělat audit a tak dále. Celá implementace bude v Jave.
  • Nad tím uděláme framework, který bude v kostře implementovat základní případy užití systému. Framework bude ovšem nabízet styčné body, kterými bude možné chování rozšiřovat/modifikovat. Zde už je to tak půl na půl s volbou jazyku.
  • Pro vlastní rozšíření se již přímo nabízí skriptovací jazyk a to z několika důvodů. Rozšíření může psát i člověk bez kapesního průvodce Javou v kapse, tedy konzultant. Žádný složitý setup, deploy, kompilace a další nudné věci, které zdržují. Skriptovací jazyk umožní pouze zaměření na daný problém a to bez komplexnosti v podobě zpracování výjimek, přístup do databáze a nebo nutnosti synchronizovat přístup k datům. K tomu musíme připočíst dobrou podporu skriptovacích jazyků v dnešních IDE.

Obecné použití skriptovacích jazyků vidím v tvorbě DSL (Domain Specific Language), pro které se hodí daleko více než staticky typová Java. Zkuste se zamyslet, která část vaší aplikace je ve své podstatě DSL a potom si položte otázku, jestli by nebylo efektivnější ji mít vyjádřenou skriptovacím jazykem. Ne vždy musí být skriptovací jazyk jasnou volbou, ale je to jednoduchý vzor jak určit, pro které části použít skriptovací jazyk a pro které nikoliv.

Pronajmu infrastrukturu značka: levně

V pondělí jsem si na prezentaci Romana Staňka vyslechnul plno zajímavých informací. Asi nejvíce mi utkvěla v hlavě myšlenka pronajmutí infrastruktury. Není se čemu divit i infrastruktura je služba, tak proč jí nepronajímat. V této souvislosti je v poslední době nejvíce slyšet o Amazonu jako poskytovateli virtuálního výpočetního výkonu, datového úložiště a databáze.

Amazon rozjel celkem tři zajímavé služby a to Amazon Simple Storage Service (Amazon S3), Amazon Elastic Compute Cloud (Beta) a Amazon SimpleDB (Beta). Zkusme si nyní představit, jakým způsobem takto pronajmutá infrastruktura funguje a to na příkladu softwarové firmy, jako je třeba ta vaše.

Naše firma F má zdrojové soubory, které je potřeba buildovat. Pronajme si tedy u Amazonu službu S3 jako fyzické úložiště. Zároveň si pronajme službu Compute Cloud, a dodá image s předinstalovaným systémem na správu zdrojových souborů (např. SVN) a CI serverem. Pro výsledky buildu použije jako úložiště službu SimpleDB. Na místě je otázka, co to firmě přinese.

  • nebude muset vlastnit patřičný hardware na buildovací stroje a tím pádem ani oddělení, které se o něj bude starat. Například je zbytečné, aby po dobu víkendu ležely buildovací stroje ladem a skladem. Při nárazových požadavcích, např. blížící se release, lze potřebnou službu dopronajmout.
  • Spolehlivost služeb např. záloha dat, fail over strojů je zajištěna poskytovatelem. To samé platí o bezpečnosti. Všechny tyto atributy služeb bývají podchyceny v takzvaném Service Level Agreementu, tedy jedná se o věc smluvně garantovanou.

Vybudovat takovouto infrastrukturu na vlastní pěst nen í záležitost na týden nebo měsíc. Samozřejmě za předpokladu, že software někde neztloukáte na koleni. Další ne nepodstatnou výhodou pronájmu služeb je lidský faktor. Při modelu služeb, nebudete více potřebovat lidi a nebo oddělení, které by se vám jinak o infrastrukturu staralo.

Softwárová firma by se měla zaměřit na vývoj softwaru a nemrhat prostředky na výstavbu infrastruktury, kterou nemůže udělat stejně efektivně a kvalitně jako někdo, kdo se zaměřuje pouze a jenom na infrastrukturu. Samozřejmě tyto služby jsou pořád daleko od masivního využití. Neřekl bych, že je to problém technický spíše jde o to udělat pověstný mentální kotrmelec a nebo počkat až ten kotrmelec udělá někdo jiný a v případě úspěchu jej následovat.

Nepochybuji o tom, že Roman Staněk tenhle kotrmelec udělal...