Magic Maze jest próbą odpowiedzi na pytanie o to czym jest gra, która dostarcza radości z grania w nią. Co sprawia, że chcemy do niej wracać? Czym jest ulotna "playability" (grywalność)? Jest też próbą skonstruowania gry wykorzystującej geolokalizację.
Na Auli 45 opowiadałem o projekcie localolo.pl, którego podstawą jest geolokalizacja, a częściami składowymi—informacja, lifestream, rozrywka i reklama. Magic Maze, który jest produktem przygotowanym na podstawie doświadczeń zdobytych w czasie budowy localolo.pl, należy na pewno do działu rozrywka, ale kolejne jego wersje zachaczać będą o lifestream i reklamę. Moim celem jest budowa systemu, który pozwalałby reklamodawcom skutecznie docierać ze swoim przekazem bez gwałcenia prywatności gracza. To trochę skomplikowane, ale to właśnie czyni projekt ciekawym.
Projektując Magic Maze chciałem połączyć dwa światy: niezwykle wciągających, ale paskudnych z wyglądu gier z lat 80-tych oraz gier na urządzenia mobilne wykorzystujących geolokalizację. Zastanawiałem się jak prosta powinna być gra, która będzie sprawiała radość z samej gry a nie z patrzenia na animowane obrazki a jednocześnie wykorzystująca nowoczesne technologie jak GPS? Planując grę zdefiniowałem kilka prostych zasad, które pozwoliły mi skoncentrować się na tym, co najważniejsze:
Gra nie może wykorzystywać więcej niż 8 kolorów
Limit 8 kolorów wybrałem kierująć się nostalgią za grami z lat 80, na które przypadło moje wejście w wiek nastoletni i pierwszy kontakt z komputerem (ZX Spectrum 48K) a także ograniczeniami praktycznymi. Przygotowanie dobrze zrobionej kolorowej grafiki zajmuje dużo czasu, a ja wolałem go poświęcić na pisanie kodu i testowanie pomysłów.
W czasie testów na styczniowym mrozie okazało się, że wybór ograniczonej palety kolorów był strzałem w dziesiątkę, ponieważ w świetle słonecznym giną niuanse cieniowania obrazków. Dlatego duże kwadraty rysowane nasyconymi do maksimum kolorami na kontrastującym, czarnym tle sprawdziły się znakomicie.
Gra powinna być odporna na zakłócenia sygnału nadajników GPS
Pisanie samej gry to dwa dni pracy w przerwach między innymi projektami, ale kalibracja zajęła nam tydzień. Trwałoby to krócej, ale nie było ochotników do wychodzenia na mróz. Ostatecznie wybraliśmy "kwadraty" o boku ok. 3m i prosty algorytm "odszumiający" sygnał, co pozwoliło nam wyeliminować nieprzewidziane zachowanie gry spowodowane zakłóceniami sygnału satelitów GPS.
Gra powinna tworzyć odpowiedni nastrój
Twórcy gier na komputery stacjonarne i konsole mają łatwiejsze zadanie. Gracz siedzi w domu przed telewizorem albo komputerem, zwykle ma podłączone głośniki 5.1 i duży monitor. Jak zatem stworzyć nastrój w grze, która odbywa się na zewnątrz, gracz dysponuje malutkim ekranem a dźwięki wydawane przez malutki głośniczek są ledwie słyszalne? Można sobie radzić słuchawkami, ale to jednak nie to samo co kontrolowane domowe środowisko.
Rozwiązanie narzuciła sama technologia GPS. Skoro i tak jesteśmy na zewnątrz, to nie ma sensu tworzyć jakiejkolwiek bariery pomiędzy światem rzeczywistym a wirtualnym światem gry. Gracz jest głównym bohaterem w grze, to on musi przebierać nogami, więc atmosfera tworzy się sama. Sam na odsłoniętym placu… stoisz na środku i zastanawiasz się, w którą stronę iść… Twoim jedynym przewodnikiem jest czerwony kwadrat na ekranie… nagle okazuje się, że ten malutki plac gry wcale nie jest taki malutki, a próba wyjścia z labiryntu wymaga sporego wysiłku fizycznego. Czy tak będą wyglądały więzienia przyszłości?
Instrukcja powinna mieścić się na jednej stronie wkładki do kaset z grą na ZX Spectrum
To kolejny przykład inspiracji grami z lat 80-tych. Jeżeli instrukcja nie mieści się na małym kawałku papieru to gra jest prawdopodobnie zbyt trudna i nudna. Najlepsze gry z mojego dzieciństwa miały najkrótsze opisy i najlepszą grywalność. Opis zasad gry Magic Maze jest równie prosty.
Gra powinna być niezależna od położenia gracza
Ten wymóg wydaje się przeczyć samej idei systemu GPS, który ma służyć do precyzyjnej lokalizacji położenia odbiornika GPS. Jednak jak w każdym przypadku, tak i tu warto pójść czasem pod prąd i zamiast tego traktować koordynaty obliczane przez odbiornik GPS jako pomoc w budowie świata gry a nie sztywny system, któremu musimy się podporządkować.
Co dalej?
Kolejnym etapem w rozwoju Magic Maze będą dodatkowe poziomy o różnym stopniu skomplikowania, edytor poziomów, oraz gra zespołowa. To, co dziś wydaje się być prymitywnym prototypem już wkrótce zamieni się w rozbudowaną grę, która pomoże zrzucić kilogramy nie gorzej niż Wii Sports.
Wyobraź sobie, że możesz wejść do świata gry z lat osiemdziesiątych. Ogromne pixele, rozdzielczość gorsza od rozdzieczości wyświetlacza w Twoim budziku. Uruchamiasz grę, Twój telefon łączy się z siecią, ale coś poszło nie tak… Znalazłeś się w niewidzialnym labiryncie, z którego musisz się jak najszybciej wydostać wchodząc na żółty kwadrat. Idź na północ, trzymaj się czarnej ścieżki, a jeżeli wejdziesz na zielone pole cofnij się do poprzedniego kwadratu.
Jak grać?
Do gry w Magic Maze potrzeba otwarej przestrzeni o wymiarach ok 70m na 70m. Aby zacząć grę należy stanąć w centrum pola i uruchomić grę. Gra rozpoczyna się z chwilą otrzymania komunikatu o połączeniu z siecią Skynet. Położenie czerwonego punktu zmienia się po przejściu przynajmniej 3m do następnego kwadratu. Kiedy wejdziesz na zielone pole tracisz życie (masz ich 9) i musisz cofnąć się do poprzedniego kwadratu.
Uwaga! Zarówno autor gry jak i wydawca nie ponoszą odpowiedzialności za szkody i straty poniesione przez graczy. Nie odpowiadają m.in. za straty materialne, finansowe, utratę zdrowia lub życia.
Jestem daleki od zachwytów nad budowanym przez Apple zamkniętym systemem dystrybucji oprogramowania, ale jedno przyznać muszę, iTunes App Store oraz aplikacja iTunes są majstersztykiem biznesowym. To maszynka do zarabiania pieniędzy, którą będzie musiał skopiować każdy, kto chce stanąć do rywalizacji z Apple. Musi to zrobić przede wszystkim Google ze swoim Androidem. Dlaczego? Pokażę to na praktycznym przykładzie:
Buszując w sieci napotykam na recenzję aplikacji na iPhone.
Klikam w łącze do aplikacji.
System uruchamia program iTunes.
Program iTunes wyświetla stronę aplikacji w iTunes App Store.
Program iTunes służy mi za lokalny magazyn aplikacji oraz jako łącze między "starym" internetem a nowym. Tego nie oferuje Android Market. Łącza do Android Market znalezione w sieci mogą być otwarte tylko na urządzeniu z systemem Android i aplikacją Market. Nie ma możliwości przechowywania aplikacji na własnym komputerze, nie ma możliwości kupowania siedząc przed komputerem. Trzeba uruchomić na telefonie aplikację Market i wyszukać to czego szukamy. Deweloperzy próbują sobie radzić publikująć kody QR na stronach WWW, ale jest to równie wygodne i intuicyjne jak pakowanie żywej ośmiornicy do kapelusza.
Google musi coś z tym zrobić, bo nie da się już dłużej udawać, że nie ma problemu. Czas skończyć w Mountain View z wieczną betą.
Są takie miejsca na świecie, których nie zobaczysz na Google Maps czy Bing Maps. Czasami, jeśli masz szczęście, zobaczysz mapkę dojazdową. Wiesz, że toczy się tam wojna, albo panuje despotyczny satrapa, ew. ktoś "grzecznie poprosił" o usunięcie danych. Dlatego np. chociaż w localolo.com znajdziesz adresy restauracji w Kabulu, trafić tam trudno. I chyba na razie nie ma sensu tam jechać. Ale jeżeli jesteś tam i chcesz coś zjeść, localolo.com podpowie ci gdzie szukać np. fast-foodu AFC (Afgan Fried Chicken). Przekonaj się o tym sam. Oczywiście, jak wszędzie, możesz się i tam zameldować przez Check-In Anywhere. Zawsze jednak pamiętaj o zasadach zachowania bezpieczeństwa i prywatności. Nie tylko w miejscach, których nie ma na mapie, ale też we własnej okolicy.
Stare i nowe media po raz trzeci zaczęły analizować czwarty już z kolei "pierwszy" telefon od Google. Faktycznie, Nexus One jest pierwszym telefonem, który Google oficjalnie ochrzcił jako "Google Phone", "Google Experience", itp. A na pewno jest to pierwszy telefon, który można kupić pod łatwym do zapamiętania adresem http://www.google.com/phone. Jeszcze nie w Polsce, ale ma to się zmienić za kilka miesięcy.
Media, jak to media, szukają sensacji a najłatwiej o to zestawiając Google Nexus One z Apple iPhone. Który lepszy? Czy Nexus jest killerem, który zepchnie produkt Apple z piedestału?
Mam dla czytelników tego tekstu dwie przewrotne odpowiedzi: a) Nexus One przegrał bitwę z iPhone 3GS na starcie; b) Android wygra tę wojnę najdalej za rok-dwa.
Nexus One nie jest złym telefonem. To najlepszy obok Droida Motoroli telefon z systemem Android dostępny na rynku. Gdyby uruchomić na nim iPhone OS, prawdopodobnie byłby jeszcze lepszą wersją iPhone'a. Ale to jest inny system, inna filozofia rozwoju platformy, inny plan.
Nexus One przegrał bitwę na długo zanim pierwszy egzemplarz opuścił fabrykę HTC. Jego projekt jest kolejną iteracją telefonu znanego jako G1, Magic, i Hero. To ten sam telefon, w którym za każdym razem zmienianie są pojedyncze komponenty, ale pewne założenia projektowe pozostają te same.
Porażka pierwsza: Rozmiar pamięci przeznaczony do przechowywania aplikacji
Nexus oferuje w chwili obecnej tylko 512MB… pomimo, że jest wyposażony w 4GB. iPhone oferuje do 64GB. W praktyce oznacza to, że gry takie jak Myst nie mogą być w chwili obecnej przeniesione na system Android. Przedstawiciele projektu Android wspomnieli, że ten limit ma zostać zwiększony w dość kuriozalny sposób, bo przez szyfrowanie programów na karcie pamięci, w którą wyposazony jest każdy telefon z systemem Android. To pomaga, ale niekoniecznie rozwiązuje problem.
Przyszłość pokaże czy Android pozbędzie się tego kamienia młyńskiego u szyi. Ogranicza on bowiem możliwość tworzenia na Androida aplikacji, które mogłyby swoją stroną wizualną i dźwiękową konkurować z aplikacjami dla iPhone'a.
Porażka druga: Java
Chociaż projektanci maszyny wirtualnej w systemie Android robią co mogą, nie da się uniknąć faktów. Zachwyty nad Nexusem biorą się stąd, że jest to nareszcie szybki sprzęt. Sprawdźmy więc parametry procesorów: Nexus potrzebuje procesora z zegarem 1GHz, a iPhone z zegarem ~500MHz. Oznacza to, że kiedy iPhone dostanie procesor z zegarem 1GHz, telefon z systemem Android będzie potrzebował procesora z zegarem 2GHz aby mu dorównać. Wina leży po stronie Javy, która pomimo wysiłków projektantów maszyny wirtualnej, nadal nie poraża prędkością. Problemem jest również zestrojenie systemu bazowego (Linux) ze sprzętem. Zdaje się, że HTC nie ma po prostu na to czasu ani zasobów finansowych potrzebnych do wyciśnięcia z kodu i sprzętu maksimum wydajności.
Porażka trzecia: Interfejs użytkownika w systemie Android
Android jest bardzo ciekawym systemem. Z jednej strony oferuje programiście olbrzymie możliwości, z drugiej strony, biblioteki interfejsu użytkownika nie zaskakują niczym szczególnym. W porównaniu z Core Animation oraz innymi bibliotekami UI z iPhone OS, Android prezentuje się jak ubogi krewny.
Prawdziwy zwycięzca
Prawdziwym zwycięzcą w pojedynku międy Apple i Google nie jest ten czy inny model telefonu, ale system operacyjny. I jest to Android a nie iPhone OS.
Android jest w chwili obecnej dostępny na kilku rodzajach urządzeń, na których iPhone OS nie znajdziemy. Chińscy producenci zaadoptowali go do odtwarzaczy MP4, tabliczek, netbooków, oraz telefonów o różnych rozmiarach ekranu i konfiguracjach sprzętowych. Apple nie odda kontroli nad iPhone OS więc siłą rzeczy udział w rynku systemów dla urządzeń mobilnych będzie w przypadku iPhone OS mniejszy.
Jak zdobyć świat?
Nie zdziwiłbym się gdyby Google zaoferował wydawcom blogów oraz innych serwisów i stron internetowych możliwość zarabiania na promocji Nexusa przez AdSense. Robili tak kiedyś z Firefoxem i Google Toolbar. Owszem, Google może reklamować telefon Nexus One na wszystkich swoich stronach i tak pewnie zrobi, ale to za mało żeby osiągnąć pożądany efekt. Ale gdyby zaoferowali blogerom procent od sprzedaży… HTC może nie nadążyć z produkcją. Ciekawe czy Google zdecyduje się na to?
Bo taki ma być. Bo nie mam czasu czytać ani moderować komentarzy. Bo ci, którzy chcą ze mną pogadać potrafią znaleźć mój adres email i napisać do mnie. Bo wolę żebyś skomentował to, co napisałem na swoim blogu zamiast na moim. Bo tak lubię. Internet wszystko wytrzyma, moje fanaberie też.
Piszę to z ciężkim sercem, ale kilkumiesięczne doświadczenia z pracą z Android SDK nie dają mi wyboru. Google nie wie co to profesjonalne przygotowanie dokumentacji, pakietu SDK oraz programu developerskiego. O ile nie mogę się nachwalić Google App Engine SDK to niestety muszę powiedzieć, że Android SDK to nic innego jak wielka, parująca kupa g… Zanim napiszesz mi jaki głupi jestem krytykując Androida, przeczytaj ten akapit jeszcze raz i zauważ, że piszę o Android SDK a nie o samym systemie Android. To dwie różne rzeczy. Żeby nie było tak negatywnie zacznę od pochwały (no, może nie takiej oczywistej…)
Java czyli mogło być gorzej
Programiści rozpoczynający pisanie oprogramowania na Android'a od nauki Javy są podwójnie sfrustrowani, bo Java nie na darmo jest nazywana COBOL-em XXI w. Jej domeną są nudne, ale niezbędne do funkcjonowania współczesnej cywilizacji aplikacje, których zadaniem jest przetwarzanie danych dot. wydobycia i przetwórstwa ropy naftowej, prowadzenie systemów billingowych telekomunikacyjnych behemotów, czy systemów obsługi kont bankowych. Z tego powodu Java jest dla programistów piszących lub utrzymujących w ruchu oprogramowanie klasy enterprise tym samym czym kopalnia dla górnika i jego rodziny—jest jak matka. I dlatego ma tak wiele dzieci. Ta matka.
Jak żaden inny język programowania, Java zapewnia utrzymanie programiście i jego rodzinie; żywi niezliczone zastępy kierowników projektów, którzy języki programowania rozróżniają po długości nazw zmiennych i zagęszczeniu kodu na ekranie (Java dobrze wypada w tym rankingu, bo ma wysoki stosunek tekstu do tła, co daje pewność stałych bonusów w postaci korporacyjnej karty płatniczej i podróży na koszt firmy). Java to enterprise a enterprise to pieniądze. Takie prawdziwe, które można wydać w sklepie, a nie nadmuchane opcje na akcje w startupie. A tam gdzie są pieniądze, liczy się efekt końcowy a nie akademicki puryzm, co widać po chaosie w bibliotekach Javy. Kto próbował, ten wie. I od tego bałaganu nie udało się uciec twórcom bibliotek androidowych, bo na krzywych fundamentach krzywo się buduje.
Ten bałagan oraz ukierunkowanie na efekt końcowy (dostarczyć projekt na czas, nie ważne w jakim stanie) widać też w kiepskiej jakości dokumentacji. Javadoc już dawno nie jest wzorcem do naśladowania, ale jest wygodny dla programistów, którzy lubią kiedy im się wszystko kompiluje, nawet jeśli zamiast treści są puste miejsca. Testy przeszło? Przeszło. Pociąg w rowie? W rowie. A co było z unit-testami? Było 100% pass… Aha, to wszystko w porządku!
Szkoda, że Android SDK jest tak marnie udokumentowany i że Google nie chce go lepiej opisać. Szkoda, bo kto popracował przez 2-3 miesiące pisząc oprogramowanie dla systemu Android wie jak potężne jest to narzędzie. To na co pozwalają zamiary (moje, może nienajlepsze tłumaczenie rzeczownika "intents") mogę porównać tylko do zabawy w swobodną zamianę instalacji elektrycznyej, gazowej i wod-kan. w komedii Szczury Paryża. Z tym jednak zastrzeżeniem, że za pomocą Android SDK można na tej podstawie budować bardzo poważne rozwiązania. Jasne, że można to zrobić w 80% z iPhone OS SDK, ale łatwość z jaką pozwala to robić Android SDK jest porażająca. I to jest prawdziwa przewaga Androida nad iPhone OS. Kiedy pierwszy raz zdałem sobie z tego sprawę zakląłem pod nosem i pierwszymi słowami jakie przyszły mi do głowy były "Game over" (dla Apple iPhone i Microsoft Windows Mobile). Z powodu samych zamiarów oraz wielu innych perełek rozrzuconych po całym Android SDK jestem w stanie wybaczyć wybór Javy jako oficjalnego języka programowania dla Android OS. Nie przepadam za nią, ale rozumiem dlaczego tak się stało. Po prostu na rynku jest wielu programistów znających Javę. A bez programistów piszących oprogramowanie nie utrzyma się na rynku żaden, nawet najlepszy system operacyjny.
Bałagan na rynku Android OS
Przepraszam jeśli czegoś nie rozumiem, ale na którą wersję Android OS powinienem pisać swoje oprogramowanie? W chwili obecnej mamy na rynku kilka(naście?) milionów urządzeń działających pod kontrolą Android OS 1.1, 1.5, 1.6, 2.0 oraz 2.0.1. Pięć wersji systemu, kilka rozdzielczości ekranu (240 x 320, 320 x 480, 480 x 800, 480 x 854) dwie orientacje ekranu (pionowa i pozioma) i to wszystko w ciagu jednego roku? Czy ktoś w Mountain View dostał kreatywnej sraczki?
I dlaczego notatki na temat pisania oprogramowania na różne rozdzielczości ekranu nie zgadzają się ze stanem faktycznym? Dlaczego np. pomimo akceptacji opisu ekranu w wersji -large emulatory 800 i 854 nie odczytują go? Dlaczego muszę kupować kolejne urządzenia o różnych rozmiarach ekranu i z różnymi wersjami Androida aby mieć jaką taką pewność, że użytkownik zobaczy mój program tak, jak go zaprojektowałem? To po jaką cholerę mi ten emulator?
Możliwość wyboru jest rzeczą dobrą, ale nie na rynku konsumenckim, gdzie powinna być ograniczona i dobrze zarządzana jeśli chcemy odnieść sukces rynkowy. Tu Google jest ofiarą Open Source. To, co na rynku aplikacji serwerowych Open Source jest naturalne, czyli totalny bałagan w kwestii kontroli publikacji kolejnych wersji oprogramowania i związany z tym taniec z aktualizacjami, na rynku urządzeń konsumenckich po prostu się nie sprawdza.
Ktoś może powiedzieć, że Apple wypuściło w tym samym czasie więcej wersji iPhone OS i jakoś nikomu to nie przeszkadza. To prawda, ale Apple dokładnie kontroluje kanał dystrybucji aktualizacji i robi co tylko się da aby przebiegały one bezboleśnie. To nie Foxconn czy operatorzy sieci komórkowych decydują o tym, kiedy pojawi się aktualizacja, ale właśnie Apple.
To samo powinien zrobić Google. To nie HTC ani operatorzy sieci komórkowych powinni decydować o tym czy i kiedy użytkownicy dostaną oprogramowanie ale właśnie Google. HTC zrobiło świetną robotę przygotowując całkiem udane telefony, których naprawdę nie trzeba się wstydzić.(*) Co więcej, HTC Tattoo, czyli Android dla zwykłego użytkownika, bez blokady za ok. 1100zł jest sensowną alternatywą dla droższych smartfonów innych producentów. Wszystko to piękne, ale dlaczego HTC nie potrafi wypuścić aktualizacji do kolejnych wersji oprogramowania jednocześnie dla wszystkich telefonów? Czy liczy, że zrobią to spece od kastracji telefonów operatorzy? A może chodzi tu o klasyczne korporacyjne rozmycie odpowiedzialności? Google pokazuje palcem na HTC, HTC na operatorów, operatorzy na HTC, a HTC na Google? A użytkownik jest skołowany jak ten developer aplikacji na Symbiana, który za cholerę nie jest w stanie odgadnąć jakie plany ma Nokia i czy istnieje takie coś jak wspólny zestaw API dla przynajmniej 60% telefonów tej firmy?
Google musi wreszcie przejrzeć na oczy, zaakceptować smutny fakt, że są "źli" jak cała reszta systemu globanych korporacji i powykręcać parę rączek a jeśli trzeba—wysłać komu się należy koński łeb albo zdechłą rybę aby uporządkować ten cały bałagan. HTC sobie nie radzi, a operatorzy tylko czekają, żeby ktoś zdjął z nich ciężar użerania się z dziadostwem, które irytuje dział PR pytaniami o to "kiedy będzie Android 1.6 na HTC Magic?" Nikt nie chce zajmować się użytkownikiem końcowym, więc ten, kto to zrobi zdobędzie bogactwo, sławę i status na miarę Steve'a Jobsa. OK, trzeba będzie się schludnie ubrać i obciąć kucyk żeby wyglądać bardziej biznesowo. Ale chyba warto?
Siła Apple bierze się również z tego, że jest to z punktu developera w miarę jednolita platforma, co obniża koszty przygotowania oprogramowania. Dlatego Google powinno zabrać HTC oraz operatorom możliwość ingerowania w system, wyrzucić tandetne bajery typu Sense UI na śmietnik (Android 2.0 wygląda już znacznie lepiej) i publikować aktualizacje automatycznie, tego samego dnia, dla wszystkich. Skoro potrafi to Apple, potrafi to również firma, która zatrudnia samych geniuszy (np. takich, którzy na Google I/O 2009 opowiadają zebranym, że "documentation kinda sucks").
XML czyli niechciane tofu
Oglądałem kiedyś odcinek Bill Cosby Show pt. "27 and Still Cooking", w którym Bill chce przygotować żonie niespodziankę z okazji 27 rocznicy ślubu i sprowadza m.in. kucharza, który gotował im pierwszą wspólną małżeńską kolację. Niestety, kucharz postępuje zgodnie z najnowszą modą i dodaje do każdej potrawy kostkę tofu.
Robi się z tego niezłe zamieszanie, bo Bill nie może mu przetłumaczyć, że nie życzy sobie tofu i chce zjeść potrawy o tym samym smaku co dwadzieścia siedem lat temu. Zdesperowany zaczyna odławiać tofu z kotła, kiedy nie widzi tego kucharz. Przyznam, że podobne reakcje budzą się we mnie kiedy boję się otworzyć lodówkę, bo mam wrażenie, że czycha tam na mnie nowy dialekt XML.
Kiedy ktoś wciska mi XML do każdego zakamarka mojego programu wiem, że nie jest dobrze. Bierze się to z owczego pędu do obesrania ozdobienia wszystkiego znacznikami XML bez względu na to, czy ma to sens czy nie. Manifest aplikacji Androidowych naprawdę nie musi być otagowany. Pliki .ini albo tradycyjne pliki konfiguracyjne znane z systemów Unix/Linux są w zupełności wystarczające. Ale ponieważ mafia XML tako rzecze, nie da rady tego zmienić. Trudno. Skoro umiejętność pisania parserów w yacc lub bison zanika wśród absolwentów kierunków inżynierii oprogramowania, dostajemy XML-owego spaślucha. Co kto lubi, ale moim zdaniem SAX(y) to nie to samo co sexy.
Opis interfejsu użytkownika
Tu mamy ciekawy przykład na niegłupi pomysł totalne spieprzony przez kolegów z tego samego zespołu. Ktoś pomyślał, że dobrze byłoby opisywać intefrejs użytkownika za pomocą zagnieżdżonych znaczników. Hurrra!
To nic, że Apple, Microsoft czy nawet REAL Software (producent pakietu REALbasic) potrafią dać programistom całkiem przydatne narzędzia do rysowania interfejsu, które przy okazji generują odpowiedni kod źródłowy. Rysowanie interfejsu graficznego za pomocą XML-a jest jak słuchanie malarstwa holenderskiego… takie rzeczy pasują na haju po magicznych grzybkach, ale na co dzień kiepsko się sprawdzają. Wiem, że XML można znaleźć w wielu innych narzędziach programistycznych, tylko że tam go nie widać. Nie musimy z nim pracować. Cały ten ambaras z XML-em przypomina mi sytuację z szynką. Jest uznawana za rarytas a to przecież kawałek zwierzęcej dupy. Dupa służy do srania, siadania w gnoju albo kurzu, ale nad tym się nie zastanawiamy nakładając kolejny plasterek na talerz. Niech podobnie będzie z XML-em. Niech sobie będzie, ale nie każcie mi w nim maczać palców.
XML w Androidzie ma sens z punktu widzenia szybkiego dostarczenia programistom narzędzia, które może jest prymitywne, ale działa. Przy okazji warto wspomnieć, że geniusze z Google nie wymyślili nic nowego, po prostu pożyczyli pomysły dotyczące hierarchii widoków i kontrolek znane z bibliotek UI Java, które to zresztą zostały zapożyczone z pakietu Tk, którego pierwsza wersja powstała w 1988. To nic złego, dobrze jest korzystać ze sprawdzonych rozwiązań nawej jeśli próbujemy dla niepoznaki omotać je grubą warstwą XML-a. To gdzie nagle rozchodzą się drogi programistów Google i zdrowego rozsądku to wizualizator UI, który nie daje sobie rady z opisem prostego UI i źle wyświetla w Eclipse i emulatorze Androida, wymuszając testowanie na prawdziwym sprzęcie bez gwarancji, że na innym modelu, z inną wersją Androida będzie to wyglądało tak samo.
Drugi problem to brak wiary w XML w samej drużynie Google. Jeżeli jeden z geniuszy nonszalancko oznajmia, żeby nie używać XML do opisu UI, to coś jest na rzeczy. Ano jest, bo mistrzowie klawiatury nie potrafili zrobić czegoś prostego, tj. kompilatora, który zamieniałby XML na strukturę, ktora jest bardziej wydajna po kompilacji do kodu pośredniego. (To zostało już nieco poprawione, ale reszta kuleje.)
Skoro dwaj ewangeliści Androida mówią, żeby tego nie używać, to znaczy, że a) to nie jest potrzebne, albo b) ktoś spieprzył implementację. Pytanie tylko gdzie był kierownik projektu, kiedy podejmowano decyzje o wykorzystaniu XML do opisu UI oraz co za błyskotliwy (sz)koder nie potrafi tego zaimplementować w tak ważnym z punktu jakości pracy z systemem module jakim jest interfejs użytkownika.
Te dwa przykłady potwierdzają moją tezę, że jeżeli ktoś nie potrafi wyjaśnić dlaczego chce zastosować gdzieś XML, to nie wolno mu na to pozwolić. Zwolnić, wysłać na długi urlop, wykupić weekend do willi Hugh Hefnera i dać otwartą linię kredytową na pokrycie kosztów party z króliczkami Playboy'a, ale nie pozwalać dorzucać XML-a bez powodu oraz dobrego pomysłu na implementację.
Eclipse IDE czyli proteza goni protezę
Z góry przepraszam fanów i developerów Eclipse. Ja wiem, że ten IDE ma wielki potencjał. I zawsze będzie go miał. Niestety, na komputerze z 4GB RAM, działając sam, nie potrafi płynnie przełączać między siedmioma otwartymi plikami. Po godzinie pracy czas przełączania dokumentów pozwala na spokojne zagotowanie wody na herbatę.
Moje życzenie na rok 2010? Żeby ktoś wysadził w powietrze wszystkie repozytoria Eclipse na świecie. I zakazał pod karą dożywotniego odebrania dostępu do internetu odtwarzania tej kupy.
Pomysł na korzystanie z Eclipse IDE wydaje się z punktu kierownika programu genialny. Oto dostajemy wieloplatformowe środowisko programistyczne, do którego wystarczy podpiąć parę wtyczek i już będzie dobrze. A właśnie, że nie będzie. Eclipse IDE jest jedną z czarnych dziur, w których ginie zdrowy rozsądek (inne to XML, Ruby on Rails, wzorce projektowe, cloud computing, itp.). Pomysł był bardzo dobry, bo Eclipse miało być wieloplatformowym środowiskiem programistycznym tworzonym na zasadach Open Source. I jak często ma to miejsce w przypadku projektów Open Source, zbudowano wieżę Babel. Ta kupa kodu nie jest w stanie pracować na kompuerze z 4GB RAM i procesorze Intel Core 2 Duo 2.6GHz. Kto tu kogo robi w konia?
Moje rozwiązanie jest proste--odpalam Eclipse IDE, tworzę projekt a potem otweram ten sam projekt w TextMate. Czego nie mogę zrobić w TextMate, robię w Eclipse, a pisanie i modyfikacja kodu odbywa się teraz z szybkością błyskawicy. Z czasem zmodyfikuję Android TextMate Bundle tak, że Eclipse będzie mi niepotrzebne w 99% przypadków.
Eclipse jako najlepsze Open Source IDE? A pocałujcie mnie w dupę.
Niedorobiony Emulator
Szybka sonda, odpowiedz szczerze jak na spowiedzi, ile razy musisz oglądać następujący komunikat:
ActivityManager: Warning: Activity not started, its current task has been brought to the front
Teoretycznie komunikat powinine pojawiać się kiedy próbujesz uruchomić niezmodyfikowany program na Emulatorze. W praktyce pojawia się w sposób przypadkowy. Co robisz? Pewnie to, co ja czyli dodajesz i kasujesz spację a następnie ponownie odpalasz projekt na Emulatorze. Raz na 3-4 razy odpali nową wersję. Co 10-20 odpaleń trzeba restartować Emulator, bo coś mu się popierniczy i twierdzi, że ma rozdwojenie osobowości:
Emulator]emulator: ERROR: the cache image is used by another emulator. aborting
Komunikat pojawia się zwykle wtedy, gdy nie ma innego działającego Emulatora oprócz tego, z którym walczysz już od pół godziny.
Czasami Eclipse IDE daje sobie spokój i wyświetla komunikat o tym, że się nie doczekał startu Emulatora. Trzeba więc odpalać go ponownie"
Your App]emulator-5554 disconnected! Cancelling 'net.devguide.android.apps.yourapp.YourApp activity launch'!
A przy okazji, autorzy Emulatora zapomnieli, że biblioteki Carbon są już nieco przestarzałe o czym ostrzegają komunikaty przy starcie emulatora.
Warning once: This application, or a library it uses, is using NSQuickDrawView, which has been deprecated. Apps should cease use of QuickDraw and move to Quartz.
Hop, hop! Jest tam kto? Ktoś czyta te komunikaty? Czy wszyscy leją na to i debugują na darmowych G1/G2 rozdawanych googlersom?
Google to wyszukiwarka
O tym, jak silne zakorzenione w świadomości pracowników Google jest główne źródło dochodów firmy świadczy najlepiej to, że nie są oni w stanie podać łącza do wysłanego do marketu Android'a programu. Dokumentacja definiuje co prawda pół tuzina schematów łącz do wyszukiwania aplikacji, ale nie podaje przykładu łącza bezpośredniego… czy tak ciężko jest wygenerować łącze bezpośrednie w panelu publikacji appa?
Google powinien odseparować dział Androida od reszty firmy, bo to szkodzi na głowę. Microsoft zrobił to z działem Xbox i nieźle na tym wychodzi.
Freakshow tylko za opłatą
Oglądając materiał wideo z sesji Google I/O 2009 dochodzę do wniosku, że dobrze Apple robi trzymając swoich geniuszy na krótkiej smyczy i pokazuje ich światu tylko za opłatą na specjalnych sesjach WWDC po uprzednim praniu mózgu (i koszul). Wystawianie na scenę człowieka, który potrafi w chwili szczerości spierniczyć wysiłki działu marketingu nie jest dobrym pomysłem. Bo szczerość jest piękna, ale nie chcemy słuchać szerych wyznań programistów, którzy spierniczyli narzędza, którymi posługujemy się na co dzień. Chcemy być uwiedzeni jak studentka przez 30-latka i nie żałować ani chwili. Zamiast tego dowiadujemy się, że jak coś źle napiszemy (a piszemy, bo dokumentacja "jest trochę do dupy" jak mówi jeden z ewangelistów Androida z Google) to się na nas ten czy inny mastach z Google obrazi… Czas dorosnąć bo Android SDK brzydko się rozkracza…
(*) Wczoraj wróciłem z hali targowej galerii handlowej "Plaza" w Lublinie gdzie zaobserwowałem klasyczną scenkę w salonie Play. 50-letni pan tak długo udawał, że nie może się zdecydować na HTC Hero, że w końcu zaczęły go do tego przekonywać żona, córka i sprzedawczyni. W końcu uległ. Lepszego dowodu na to, że para HTC/Android osiągnęła status Walkmana i na dobre zaistniała w świadomości zwykłego użytkownika nie trzeba.
Przyznam, że sprawa jest trochę głupia. Przy całym natłoku narzędzi, bibliotek, filtrów, itp. błyskotek do przetwarzania dokumentów tekstowych stary, poczciwy AWK bije większość z nich na głowę. Powinienem wiedzieć. AWK przeżuwa na naszych serwerach 20 000 000+ dokumentów dziennie. Tak, napisałem "ponad 20 milionów." Większosć filtrów piszę właśnie w AWK, potem w Pythonie, PHP i Perl-u. Potem Python pisze dane do CouchDB, SQLite, i Redis-a. I to jest właśnie siła Unix-a i oprogramowana Open Source. Mogę dopasować zestaw narzędzi do zadania, które mam wykonać a nie na odwrót.
Czy maszyny, rośliny, a nawet wszelkiego rodzaju materia nieożywiona może się z nami komunikować? To pytanie zaprząta umysły ludzi od wieków. Programiści Tom Taylor i Tom Armitage znudzeni czekaniem na odpowiedź napisali jakiś czas temu boty monitorujące obiekty w przestrzeni kosmicznej, które mogłyby zagrażać Ziemi (@lowflyingrocks) oraz powiadamiająe o tym co robi most Tower Bridge w Londynie (@towerbrdige).
Zainspirowany ich pracą napisałem boty, które tłumaczą to, co publikują @lowflyingrocks i @towerbridge na język polski a potem publikują swoje tłumaczenia na serwisie blip.pl (^lufawkrzokach i ^towerbridge).
