jAbLoK

Podle článku Google App Engine Announces Pricing Plan, APIs, Open Access na ReadWriteWeb se očekává, že Google dnes na Google I/O konferenci oznámí několik novinek ohledně AppEngine (viz též starší zmínka na Jabloku):

Služba bude v základní bezplatné verzi přístupná všem zájemcům bez čekání (rozdíl oproti současnému uzavřenému byť zvolná narůstajícímu okruhu testerů).

Limity základní verze zůstavají na 500 MB persistentně uložených dat a přenosové kapacitě specifikované jako “dostatečná pro 5 milionů pageviews měsíčně”. Do konce roku se objeví možnost přikoupit dodatečné zdroje, ReadWriteWeb uvádí následující předběžný ceník:

• $0.10 - $0.12 per CPU core-hour
• $0.15 - $0.18 per GB-month of storage
• $0.11 - $0.13 per GB outgoing bandwidth
• $0.09 - $0.11 per GB incoming bandwidth

Zmínka o placení za CPU mi není příliš jasná vzhledem k tomu, že základní verze žádné omezení vlastní výpočetní kapacity nezmiňuje. Uvidíme.

Posledním zajímavým rozšířením jsou dvě nová API - pro manipulaci s obrázky a především - pro kešování (absence kešování byla vzhledem k přirozeným omezením odezvy distribuované databáze nepříjemná).

Jinak celý tento článek je pro Javisty off-topic, jiné jazyky než Python zatím Google v AppEngine podporovat nehodlá

Před pár dny Google na svém blogu oznámil spuštění automatického překladače mezi češtinou a opravdu velkou spoustou jazyků.

Takže pokud vás zajímá, co se tak zrovna zajímavého děje v Číně aniž byste disponovali patřičnými jazykovými znalostmi, můžete s trochou fantazie sledovat český překlad čínských Google News. Uznávám, že zpráva Andy Lau Shi Zhu Liqian vztahy s měkkou sílu postupně nejistý dotýkající se patrně čínské pop-kultury už vyznívá trochu surrealisticky, na druhou stranu na podobné výplody je patrně zvyklý mnohý uživatel dosavadních automatických překladačů mezi češtinou a angličtinou.

Teď ještě, aby to umělo překládat i feedy.

Mimochodem, japonština se i podle úrovně překladu zdá být znatelně jednodušším jazykem.

Předevčírem jsem se o své první dojmy z EC2 chtěl nadšeně podělit s Františkem. Jenže František je - jak známo - všude první, a tudíž mohl být nad nějakou virtualizaci povznesen - samozřejmě už předtím četl spekulace o tom, že se Google chystá nabídnout svou infrastrukturu jako službu. Což se během dvou dnů také stalo.

Služba se jmenuje appspot.com, a v tuto chvíli se nachází ve stadiu “preview release”, což znamená testovací provoz pro prvních 10,000 zájemců, kteří se ozvali během několika hodin po oficiálním oznámení (já to bohužel nestihl). K dispozici je vývojové prostředí AppEngine, které obsahuje potřebné knihovny a hlavně lokálně spustitelný runtime, v němž je možná aplikaci otestovat před uploadem na appspot bez jakýchkoli úprav. Služba je při omezené návštěvnosti a velikosti persistentních dat zdarma, v plánu je placená varianta, kde tato omezení padnou.

AppEngine nabízí oproti Amazonu škálovatelnost transparentní, samozřejmě za cenu jistých omezení. Zatimco amazoními služby (AWS) vám usnadňují žonglování se serverovou farmou, jejíž možnosti můžete využívat dle architektonické i programátorské fantazie, Google vás zcela odstiňuje od konkrétního (byť virtuálního) serveru, operačního systému a jeho limitů. Zkrátka poskytuje transparentně škálující aplikační server.

Tato transparentnost je samozřejmě možná jen za cenu několika omezení, které musí takto vyvíjená a nasazená aplikace splňovat. Namátkou:

• Persistentní vrstva
  • Používá speciální API a dotazovací jazyk pro persistentní ukládání dat (pro lepší srozumitelnost ale budu dál používat pojmy z relačnch databází)
  • Omezené dotazovací možnosti (nelze “najít NULL”, nelze kombinovat porovnávací operace nad více “sloupci” a pokud je použijeme, musíme je v připadné ORDER BY klausuli dát na začátek, a navíc není podporován operátor nerovnosti)
• Aplikace běží v omezeném kontejneru (sandboxu), který neumožňuje:
  • zápis na filesystem; číst je mоžné pouze soubory aplikace
  • práci se sockety (je ale možno použít explicitně poskytovanou službu pro odesílání e-mailů a pro přístup k vzdáleným zdrojům přes HTTP či HTTPS přes standardní porty)
  • spouštět nová vlákna nebo procesy
  • zpracovávat požadavek příliš dlouho
  • další systémová volání (např. práci se signály)
• Veškerá serverová logika se točí okolo zpracovávání požadavků, žádné další služby jako plánování úloh nejsou k dispozici
• Jediný podporovaný jazyk je (zatím?) Python

Jestli jste se někdy zajímali o to, jak škálují weby jako Flickr, Wikipedia, Amazon nebo samotný Google, asi je jasné, že dobře škálující aplikace prostě musí být s ohledem na škálovatelnost navržena. Jinými slovy, musí brát v úvahu některá omezení: nepřehánět to s normalizaci dat, s používáním sessions, nenačítat při zpracování požadavku zbytečně mnoho dat, snažit se o co nejrychlejší odezvu atd. atd. Z tohoto pohledu jsou omezení AppEngine pochopitelná - nějak byste se omezit stejně museli, takže Google vám vlastně jen nutí své best practices.

Škálovatelností se samozřejmě nedá vysvětlit omezení na Python - ale darovanému koni na zuby nehleď. Předpokládám, že spolu s placenou verzí budou další jazyky muset následovat. Na druhou stranu si dokážu představit, že při určitém poměru návštěvnosti a složitosti aplikace by hodnota infrastruktury mohla převážit jednorázové náklady na nahrazení aplikace i programátorů pythonovými alternativami

Zdroje:

• Google App Engine Developer’s Guide
• Google Appengine: A first Look na High Scalability
• Google App Engine: History’s Next Step or Monopolistic Boondoggle? na Read Write Webu

Jak z této tabulky vyrobit snadno a rychle čárový graf?

Takhle: <img src="http://chart.apis.google.com/chart?cht=lc&chs=200×125&chxt=x,y&chd=t:50,5,75,12,81&chxl=0:|1|2|3|4|5">

Podrobná dokumentace je k dostání na http://code.google.com/apis/chart/.

P.S. samozřejmě, že pokud by tato stránka způsobila více než 50,000 dotazů na výše linkovaný obrázek, bylo by to porušení pravidel používání Google Chart API…

Kde byste raději pracovali — v Googlu nebo v Meetupu?

Via Joel on Software.

Pozorováním programátorů v divočině člověk snadno zjistí, že je zjevně zábavnější vytvářet obecné frameworky nežli aplikace, které něco opravdu dělají. Takže není divu, že máme další z mnoha frameworků poskytující podporu pro organizaci aplikace podle vzoru  inversion of control .

Název naznačuje, proč zrovna tenhle kousek stojí za popzornost: než byl vypuštěn do světa jako open-source projekt, tak byl po několik měsíčů prakticky ověřován na Gůglích  "mission critical applications"  (zdroj) — nevím, které přesně, někde jsem sice v této souvislost četl o AdWords, ale už si nevybavuju, kde.

Stručná charakteristika:

• řeší jen a pouze dependency injection + integraci s servletovým kontejnerem
• vyžaduje Javu 5, a je silně postaven na generických typech a anotacích
• má být svižný (čemuž bych věřil, protože letmý pohled do zdrojáků naznačuje naprostou absenci reflection)

Jak se s Guice programuje?

Máme-li třídu závislou na implementaci nějakého rozhraní, označíme příslušný setter (nebo konstruktor) anotací @Inject:

import com.google.inject.Inject;

public class Client {
     private Counter counter;

    @Inject
    public void setCounter(Counter counter) {
        this.counter = counter;
    }

    public void test() {
        counter.ping();
        counter.ping();
        System.out.println(counter.getValue());
    }
}

Co nám vlastně do proměnné counter přilítne, určí programátor tak, že vyrobí, tzv. modul, tedy implementaci rozhraní com.google.inject.Module, ve většině newebových případů pak potomka com.google.inject.AbstractModule a pro webové aplikace má k dispozici rovnou com.google.inject.servlet.ServletModule.

V modulu si pak namapuje rozhraní na konkrétní implementaci a vymezí rozsah platnosti instancí, třeba takhle:

import com.google.inject.Scopes;
import com.google.inject.servlet.ServletModule;

public class MyModule extends AbstractModule {
    protected void configure() {
        super.configure();
        bind(Counter.class).to(CounterImpl.class).in(Scopes.SINGLETON);
    }
}

Výše uvedený kód říká, že do metod označených anotací com.google.inject.Inject, které přijímají parametr typu Counter se předá vždy jedna a tatáž instance (ano, to je to in(Scopes.SINGLETON)) třídy CounterImpl.

A pokud má náš kód běžet v prostředí webového kontejneru a modul vyrobíme rozšířením třídy ServletModule, pak máme — nejspíš v souladu s očekáváním — další dvě možnosti nastavení rozsahu platnosti injektovaných tříd, a to com.google.inject.servlet.ServletScopes.REQUEST a SESSION.

Pokračování možná jindy.

Vypadá to, že po e-mailech věnuju Google další balík informací. Nová (bezplatná) služba Google Analytics postavená na principu počitadla návštěvnosti vypadá velmi slibně.

Zdá se, že služba se ne nadarmo jmenuje Google Analytics a nikoli třeba skromněji Google WebCounter.

Už jsem si párkrát říkal, že masově nasazené webové počitadlo může být užitečné pro lepší porozumění obsahu — třeba už jen kvůli seskupování stránek do skupin podle návštěvníků.

A vida…

Aktualizace:

Projekt je to zajímavý a ambiciózní, ale na to, že v logu nemá obligátní “beta”, je rozhodně nedotažený — nefunkční odkazy, nefunkční detekce počítacího kódu na stránkách, nepřehledné uživatelské rozhraní…

Rozhodně Google Analytics — aspoň zatím — nevypadá jako produkt, který by hrdě mohl nést cedulku “od tvůrců GMailu”.

Aktualizace 2

Analytics už měřící kódy detekuje a sbírá data (Jablok prý dnes navštívili dva čtenáři z Karlových Varů a jeden ze Strakonic).

A aby toho nebylo málo, Google dnes konečně spustil veřejnou beta verzi Google Base, určenou k vkládání/publikaci strukturovaných dat — zdá se, že zatím se ji chytly hlavně personální agentury.