Google Translator Toolkit

Dokładnie rok (czerwiec 2008) przed wprowadzeniem przez Google usługi Google Translator Toolkit (czerwiec 2009) miałem identyczny pomysł na projekt, który wynikał z moich doświadczeń z tłumaczeniem i z chęci utworzenia systemu do tłumaczenia dokumentacji technicznych online (w tym konkretnym przypadku na potrzeby tłumaczenia książki o Django). Mój projekt (nazwany roboczo Transworld) nie wyszedł zanadto poza fazę zbierania wymagań i decydowania na czym to postawić. Osobom lubiącym teorie spiskowe dodam, że opis systemu znajdował się na Google Docs i z pewnością został przez pracowników giganta przeczytany, a że realizacja zajęła im aż rok - może znaleźli dokument nieco później ;)

Niektóre szczegóły systemu GTT nie są takie, jakie miałem we własnym zamyśle (miałem bardziej konkretne wytyczne po doświadczeniach z wydawnictwem), ale mimo wszystko podobne. Jeszcze większa zbieżność dotyczy wykorzystania systemu Google Translate (sam planowałem użyć dostępnego API do uzyskania tłumaczenia maszynowego). w GTT jest to oczywiście posunięte dalej. Kolejny aspekt to wykorzystana infrastruktura - prawie identyczna (bo planowałem postawić to na Google App Engine). Nawet system GUI to ta sama broszka - GWT w Google i Pyjamas (odpowiednik GWT, ale pisze się w Pythonie) dla Transworld. Przyznam się, że miałem nawet punkt "Prostota wyglądu w stylu Google".

Po przeczytaniu informacji o GTT cieszę się podwójnie. To budujące, jak ktoś sporo później niezależnie realizuje podobny pomysł pokrywający się w 80% z moją ideą (gdyby odrzucić część komercyjną Transworld to nawet 95%). Druga radość to jednak ta, że nie pociągnąłem projektu dalej, bo wkrótce zostałbym (tym bardziej, że miałem to realizować na infrastrukturze Google) przejechany przez walec z napisem Google - zbyt podobne pomysły, bym tu miał szansę.

Google Translator Toolkit nie jest jeszcze dopracowany do końca (tłumaczenie tylko z angielskiego), ale ma ogromną zaletę, z której korzysta tłumacz i Google: ogromną bazę zdaniową, która będzie tylko rosła i rosła. Poprawi to jakość tłumaczenia maszynowego, co jest celem dla obu wymienionych.

PS. Czyżby cza zacząć tłumaczyć The Django Book 2.0 na nowej platformie? Powinna się naprawdę sprawdzić przy tłumaczeniu grupowym, czego wszystkim życzę!

Edukacja wydajnościowa w GAE

Wygląda na to, że również Google zaczął nieco bardziej aktywnie edukować programistów w kwestii optymalizacji i zwiększania wydajności (a przy tym i ewentualnych kosztów). Przy okazji porządków na stronie artykułów o Google App Engine umieszczono kilka nowych artykułów poruszających tematykę tworzenia wydajnych aplikacji na tej platformie.

Prezentowane tam informacje pokrywają się częściowo z moim wcześniejszym wpisem o optymalizacji, ale najczęściej zawierają najbardziej podstawowe wskazówki: jak tworzyć paginację, jak dzielić dane na część metadanową i szczegóły, jak korzystać z memcache i rozbicia liczników do unikania konfliktów przy często zapisywanych elementach. Polecam przeczytanie wspomnianych artykułów przed lekturą mojego wpisu, gdyż stanowi on dobre uzupełnienie tych ogólnych informacji.

Google App Engine stracił na kilka godzin silnik

Jak donoszą agencje i strona statusów, GAE zanotowało wczoraj kilkugodzinne problemy z działaniem serwerów aplikacyjnych, memcache i bazy danych Datastore. Takie jednorazowe problemy zdarzają się każdemu, ale w przypadku Google App Engine jest to w ostatnim czasie dłuższa seria okresowych problemów, które tu i tam pojawiają się co kilka dni.

Nie wróży to najlepiej przyszłemu rozwojowi usługi w aspekcie Enterprise, gdyż dla dużych firm pewność działania to aspekt podstawowy. Choć mniejsi twórcy witryn prawdopodobnie nie będą szukali nowego domu (GAE to wiele zalet dla startupów), działy IT z administratorami w dużych firmach nadal nie mają się o co martwić w kwestii rozwiązań cloud computing przez kolejne miesiące i przeciwnicy adaptacji chmur w firmach dostają kolejne argumenty.

Edycja 2009-07-12: Google zamieścił na grupie dyskusyjnej szczegółową informację na temat przyczyn kilkugodzinnego przestoju platformy 2 lipca.

Google App Engine po darmowych obiadkach

Ponad tydzień temu, czyli 22 czerwca 2009 (z miesięcznym poślizgiem względem początkowo wskazywanej daty) znacznie ograniczono bezpłatne limity dwóch parametrów systemu:

• dzienny czas procesora z 46 do 6,5 godziny,
• dzienny limit transferu danych do i z aplikacji z 10GB do 1GB.

Pozostałe limity nie zmieniły się, ale prezentowane dwa uległy ograniczeniu o ponad 80-90%. Wiele osób pomyśli: "No tak, zwiedli ogromnymi wartościami, a teraz ograniczają na potęgę!". Może jest w tym ziarno prawdy, bo Google nie jest instytucją charytatywną (szczególnie w czasach kryzysu), ale bądźmy szczerzy - to oryginalne wartości były wzięte z kosmosu! Policzmy ile do 22 czerwca Google mogło dać jednemu programiście miesięcznie (wartości mnożone przez 10 aplikacji) całkowicie gratis:

• 10 x 30 dni x 10GB = 3TB transferu miesięcznie,
• 10 x 46h = prawie 20 dostępnych procesorów do wykorzystania miesięcznie,
• 10 x 150 MB + 10 x 500 MB = 6,5 GB przestrzeni statyczno-dynamicznej.

 Patrząc na te wartości oferowane bezpłatnie można dojść do wniosku, że z komercyjnego punktu widzenia Google "błądziło w chmurach" ze swoim rozwiązaniem chumrowym i niedawno zeszło na ziemię. Oczywiście obie wspomniane wartości można obecnie dokupić, ale czy nadal możliwe jest utrzymanie średniej witryny w bezpłatnym limicie?

Okazuje się, że tak, choć trzeba zacząć bardziej kombinować, jeśli witryna jest złożona lub ma więcej niż kilka tysięcy stałych użytkowników.

Sposoby na oszczędzenie kilku cykli procesora

Kilka wskazówek pozwalających skutecznie ograniczyć liczbę cykli procesora:

• skorzystaj z Jinja2 do generowania szablonów zamiast standardowych szablonów Django (Jinja2 jest podobna do szablonół Django, co zmniejsza czas nauki),
• przyspiesz szablony Jinja2 jeszcze bardziej, kompilując je do kodu Pythona przed umieszczeniem na GAE - kod,
• korzystaj z wersji multi poleceń dla Datastore i Memcache - pozwalają one pobrać w tym samym czasie kilka elementów, a także zapisywać je równolegle,
• obejrzyj prezentację Breta Slatkina na temat sposobów ograniczania czasu pakowania/rozpakowania długich list (używane w relacjach wiele do wielu), korzystając ze sztuczek z hierarchią kluczy,
• jeśli masz obiekty z dużą ilością danych, ale przez większość czasu korzystasz tylko z kilku, zastosuj dwa obiekty (szczegóły niech będa zapisane jako dziecko podstawowych danych) - oszczędzisz na serializacji i ilości pobrań danych (pamiętaj, że określanie kolumn do pobrania w Datastore nie ma praktycznego znaczenia),
• jeśli możesz coś umieścić statycznie i tak wczytywać, zrób to - przykładem może być kompresja CSS i JS, której nie należy robić w locie, nawet jeśli używasz przy tym memcache, bo to czysta strata zasobów),
• jeśli możesz, nie korzystaj z plików ZIP dla kodu elementów witryny odwiedzanych najczęściej, a jeśli limit na to pozwoli, w ogóle nie stosuj plików ZIP z kodem,
• w miarę możliwości stosuj paginację z rozwiązaniem z zakładką (ewentualnie zakładkowanie po dacie) zamiast pobierać 1000 wyników i je paginować (ponownie czas deserializacji),
• gdy nie potrzebujesz całych obiektów, a tylko ich klucze, użyj dostępnej od niedawna składni __key__,
• jeśli nie potrzebujesz indeksów dla niektórych pojedynczych właściwości, wyłącz ich tworzenie właściwością indexed ustawioną na false,
• tego chyba nie trzeba powtarzać: memcache i jeszcze raz memcache dla każdych buforowalnych, a intensywnych obliczeniowo działań.

Kilka wskazówek dotyczących ograniczenia ilości przesyłanych danych:

• w pliku app.yaml ustaw domyślny czas aktualności plików statycznych na około rok w przód (default_expiration: "365d"), by ograniczyć liczbę pobrań plików,
• skorzystaj z łączenia i kompresji plików JS i CSS, np. z systemu MediaGenerator z App Engine Patch,
• jeśli używasz bibliotek takich jak jQuery, Dojo lub Prototype, skorzystaj z możliwości odciążenia własnego konta przez wczytywanie bibliotek z serwerów Google,
• użyj rozwiązań takich jak Smush It (maksymalna kompresja obrazów) oraz spriteów CSS (przykład), by zminimalizować liczbę żądań i ilość danych,
• stosuj możliwie zwięzły kod HTML (używając intensowniej CSS i zewnętrznego JavaScript),
• jeśli masz taką możliwość, zamień przysłanie danych ajaksowych z XML na JSON.

Większość prezentowanych rozwiązań powinna być znana każdej osobie pracującej nad portalami o dużym nateżeniu ruchu. W przypadku Google App engine przydaje się ona także do wyciągnięcia jak najwięcej z darmowego limitu. Nawet pomomo wspomnianych na początku ograniczeń 5 milionów wyświetleń stron miesięcznie całkowicie gratis nadal stoi otworem!