Gdzieś między Polską a Niemcami, a szczególnie w NRD

Czas nieutracony (7) – Założenia

Jak wynika z poprzedniego odcinka, podstawowym problemem MDD w praktyce jest to, że nie ma rozwiązań z półki, a zrobienie swojego rozwiązania na jeden projekt jest niezbyt opłacalne.

No ale w przypadku którym się zajmuję - czyli tego AUTOSARa - to mamy mnóstwo projektów w tym samym, dobrze zdefiniowanym środowisku! Przy projekcie dla gwiazdkowców, w tym jednym modelu samochodu urządzeń z częścią AUTOSARową było 60! Niemal każde z tych urządzeń jest robione przez osobny zespół, ale technologicznie to jest dokładnie samo! A potem następują kolejne modele, inni producenci samochodów ze swoimi modelami, powoli już prawie wszyscy wymagają robienia w AUTOSARze! Zainwestowano w niego tyle czasu i pieniędzy, że ta technologia spokojnie pociągnie jeszcze co najmniej 20 lat. A podstawowym problemem tej technologii jest brak porządnych narzędzi.

Czyli: Mamy setki projektów w dokładnie tej samej technologii - więc można by im dostarczyć rozwiązanie MDD z półki. Rozwiązanie ma poważne szanse obniżyć koszty developmentu i istotnie zmniejszyć problemy ze znalezieniem ludzi mających o tym AUTOSARze pojęcie (bo tool pomoże, nie trzeba będzie wiedzieć wszystkiego samemu). Brzmi atrakcyjnie, prawda?

A narzędzi brakuje tak drastycznie, że co i raz ponownie wypływa temat "Muszę zrobić parę diagramów z obiektami AUTOSARowymi, skąd wziąć jakieś narzędzie do tego?"

Ustaliłem więc założenia projektowe, najpierw długoterminowe:

  • Docelowo chcę wspierać całą funkcjonalność AUTOSARa związaną z tworzeniem własnych modułów. (W terminologii AUTOSARa to się nazywa AUTOSAR Authoring Tool). Całą funkcjonalność - na przykład również ten całkiem nieźle wymyślony support tworzenia dokumentacji, którego nikt na świecie jeszcze nawet nie tknął.
  • Nie będę wspierał konfiguracji modułów standardowych. Taki konfigurator musi być dopasowany do samych modułów standardowych, tylko spora firma (100+ pracowników) jest w stanie je wszystkie zrobić i supportować (a konkurencja tu jest silna).
  • Moje narzędzie ma wspierać:
    • Import, eksport i edycję plików ARXML na poziomie pojedynczych obiektów.
    • Edycję obiektów na wyższym poziomie. Chodzi o to, że żeby na przykład utworzyć AUTOSARowy odpowiednik typu wyliczeniowego, trzeba się strasznie naklikać. Idea jest taka, żeby pokazać do wypełnienia tylko okienko z istotnymi informacjami, a te dodatkowe wygenerować. Znaczy takie wizardy.
    • Asocjacje AUTOSARowe to są takie proste linki tekstowe. Program ma automatycznie robić do nich konektory w modelu, żeby bezproblemowo pokazywać je na diagramach.
    • Zrobię własne okienko managera projektu, z moją obsługą - pewnych rzeczy nie da się zrobić standardowym okienkiem EA.
    • Podobnie zrobię własne okienko do edycji atrybutów i asocjacji obiektów AUTOSARowych, bo to standardowe się nie nadaje.
  • Specyfikacja AUTOSARa nie definiuje w żaden sposób tworzenia własnego kodu. Dorobię więc moje rozszerzenie standardu, żeby było możliwe modelowanie kodu modułu powiązane z obiektami AUTOSARa.
  • Zrobię generowanie kodu statemachine kompatybilnego z AUTOSARem ze statechartu. (To bardzo istotny punkt).
  • Zapewnię możliwość szybkiej generacji ARXMLi i kodu z modelu przez CLI - żeby nie było potrzeby checkinowania plików generowanych.
  • Poważnym problemem jest porównywanie plików ARXML - kolejność obiektów w nich niekoniecznie jest taka sama przy każdej nowej wersji pliku, a ta kolejność w większości przypadków nie jest semantycznie istotna  (mógłbym zrobić długą dygresję o przyczynach mieszania kolejności w zależności od typu kolekcji w Javie używanych w różnych toolach). Porównywanie plików narzędziem operującym na poziomie tekstu (nawet przy uwzględnieniu tagów XML, na przykład przy pomocy Beyond Compare) jest często praktycznie niemożliwe. Mój program zapewni możliwość porównywania plików na poziomie obiektów AUTOSARa.
  • Pomysłów mam jeszcze wiele, niektórych nie chcę zdradzać w ogóle nikomu.

To jest oczywiście program na sporo osobolat, a ja na razie robię tylko sam (no, prawie sam) po godzinach. Więc teraz założenia pierwszego etapu, po którym ma powstać pierwsza wersja produktu nadająca się do sprzedaży:

  • Ma to być plugin do Enterprise Architecta. W dłuższym terminie zobaczymy, ale raczej trzeba będzie z niego wyjść i najlepiej zrobić coś swojego. Tak, wiem, to wielka kupa roboty.
  • Będzie to napisane w C# (musi obsługiwać COM, tylko coś od MS wchodzi w grę)
  • Pełny import/eksport plików ARXML i edycja obiektów na niskim poziomie.
  • Obsługa linków AUTOSARowych (automatyczne tworzenie connectorów EA)
  • Działające okienka mojego managera projektów i atrybutów obiektu
  • Generacja kodu, ale na razie nie ze statechartów.
  • Wywołanie generacji z CLI
  • Zewnętrzna aplikacja do porównywania ARXMLi.

Dalej w następnym odcinku.

 

-----------------------------------------------------------------------------------------------------------------------

Dotyczy:

Kategorie:Programowanie

Skomentuj

Czas nieutracony (6) – Modelarze

Teraz będzie o  narzędziach do modelowania.

Enterprise Architect logo

Enterprise Architect logo

Enterprise Architect pojawił się na rynku w roku 2000. Moje pierwsze zetknięcie z nim to był rok 2002 albo 3. Wybierałem narzędzie do modelowania dla serii projektów, które zamierzaliśmy robić w MDD. Wypróbowałem wtedy wszystko, co było dostępne na rynku. EA był wtedy bardzo nowy i miał baaardzo konkurencyjną cenę, przy niezłym usability i funkcjonalności. Projekty zakończyły się sukcesem, pod względem procesu (który ja stworzyłem) były najlepsze jakie robiłem.

Dziś, po ponad 20 latach od premiery, EA jest nadal nie najgorszy w porównaniu z innymi, podobnymi narzędziami. I jego cena jest nadal konkurencyjna - najtańsza wersja (Proffesional) kosztuje 220 USD. Dla porównania: Rhapsody zaczyna się od jakichś 800 USD.

Tyle że to narzędzie przez te dwie dekady prawie nie zmieniło się od strony technicznej i jest w tej chwili totalnie przestarzałe:

  • To jest nadal aplikacja 32-bitowa, czyli może zaallokować max. 2 GB pamięci. Niby dużo, ale jednak nie.
  • Modele zapisywane są w Accessowej bazie danych (przynajmniej dla wersji Proffesional, droższe wersje wspierają również inne bazy danych). Do niedawna używali drivera MS JET 3.5 (MS Access 97) parę lat temu przeszli na MS JET 4.0 (MS Access 2003). Problem jest przede wszystkim w ograniczeniu maksymalnej wielkości pliku bazy danych (v3.5 - 1GB, v4.0 - 2GB). To jest za mało na moje potrzeby. No i samo użycie bazy danych - relacyjna baza danych jest stosunkowo wolna przy zapisie (aktualizacja indeksów), aktualne tendencje idą w stronę nierelacyjnych baz danych NoSQL.
  • Producent nie chce zdradzić w czym to jest napisane, ale musi to być coś ze stajni Microsoftu, prawdopodobnie C++.
  • Interface do pluginów idzie przez microsoftowy COM, to jest strasznie wolne (mierzyłem - wczytanie wszystkich obiektów modelu do mojego plugina przez COM idzie 50 razy dłużej niż jak wczytam je bezpośrednio z bazy danych).
  • Potrafię wywalić ten program do systemu w 100/100 próbach przy normalnej edycji modelu, ten problem był już w wersji 13.5, na pewno był nadal w 15.1, nie sprawdzałem jeszcze w aktualnej 15.2.
  • Struktura bazy danych i COM API są bardzo niespójne (również w konwencjach nazewnictwa), i mają luki - pewne rzeczy nie są w ogóle dostępne przez API, niektóre wyraźnie przez nieuwagę.
  • UI jest jeszcze bardziej niespójne, widać że narastało ewolucyjnie.
  • EA nie za bardzo potrafi generować kod. Daje się z niego łatwo generować nagłówki funkcji, ale kodu wewnątrz funkcji nie (przynajmniej bez kombinowania albo uzupełniania EA pluginami). Notacja do konfigurowania jego wewnętrznego generatora też jest kryptyczna, niezbyt intuicyjna i słabo opisana.

Krótko mówiąc: ten program wymaga totalnego redesignu, którego nie będzie - bo wszystkie pluginy porobione przez użytkowników przez te 20 lat przestały by działać. No ale program jest dość popularny, niedrogi i ma nieźle udokumentowane API w porównaniu z innymi, można od niego zacząć.

Żeby nie było że EA to jakiś technologiczny wyjątek - Rhapsody jest parę lat starsze (1996) i też od tego czasu niewiele się technicznie zmieniło:

  • Też jest 32-bitowe (tymczasem jest też wersja 64-bitowa, ale nie ma ona jeszcze wszystkich ficzerów wersji 32-bitowej)
  • Jest napisane bodajże w C++ (wnioskuję po tym, że wywala się czasem do systemu, w Javie tak nie ma), ale wygląda na bardzo posprzęgane z Javą.
  • Wersje 8.1.x też się wywalały aż do systemu przy normalnej pracy, nie wiem czy udało im się to poprawić.
  • API do rozszerzeń jest w Javie, ma to plusy i minusy.
  • Projekty są zapisywane w plikach tekstowych, jest możliwość podłączenia bazy danych.
  • Kilka dodatkowych toolów do konfigurowania tego i owego w Rhapsody (na przykład template dokumentacji) jest zrobiona w Eclipse (w końcu Eclipse jest od IBM, a nazwa jego wynika stąd, że miało zaćmić Słońce (czyli Suna, popatrzcie na logo)). Eclipse dobre było, ale dziś to nie jest już aktualny stan techniki.
Logo Eclipse

Logo Eclipse

Narzędzi do modelowania jest znacznie więcej, miałem kontakt jeszcze z kilkoma innymi (np. Borland Together, MagicDraw, Papyrus, Astah...). Długo by opisywać, do ideału wszystkim jest daleko.  Może teraz parę generalnych uwag co do takich narzędzi i MDD:

  • Hype na MDD sprzed dwudziestu lat szybko opadł, kiedy się okazało że nie za bardzo da się wziąć narzędzia z półki i z marszu zrobić MDD aplikacji według swoich potrzeb. Praktycznie zawsze niezbędny jest długi etap dopasowywania narzędzia do projektu, i to może być trudniejsze niż zrobienie aplikacji "normalnie". W każdym razie, dla jednego projektu najczęściej się nie opłaca, a wiele kolejnych projektów w dokładnie tej samej technologii (czyli nie wymagających dopasowania narzędzia od nowa) to nie jest znowu taki częsty przypadek.
  • Producenci narzędzi często oferują profile do robienia MDD w różnych działkach, ale żeby któryś z tych profili pasował do konkretnego zastosowania bez potrzeby robienia w nim zmian, to jest raczej wyjątek.
  • Robiłem już projekt, w  którym modelowaliśmy obiekty w toolu, a potem ręcznie robiliśmy analogiczne definicje w plikach tekstowych, z których był generowany kod. (To był pomysł klienta, nie jedyny taki świetny w tym projekcie, aż na koniec rzuciłem wypowiedzeniem). Takie podejście praktycznie nie różni się od modelowania + kodowania całkowicie ręcznego - jest media break (jest na to polskie określenie?), więc nie ma MDD.
  • Narzędzia do modelowania są najczęściej słabo zintegrowane z build process - w praktyce kod generowany z modelu jest checkinowany, bo generacja nie jest możliwa z batcha, za długo trwa żeby generować za każdym buildem, albo (jak w standardowym EA) generowane są tylko nagłówki funkcji, a kod trzeba dopisać ręcznie. Problem polega na tym, że jeżeli kod jest w repository a generacja wymaga czasu/wysiłku, to developer ma mocne pokusy żeby poprawiać kod w wygenerowanym źródle, a nie w modelu, i w tym momencie jest po MDD. (Nie rzucę pierwszy kamieniem, mimo że jestem z tych twardszych i bardziej zdyscyplinowanych)
  • Praktyczny, realnie istniejący (nie mylić z górnolotnymi ideami) development z użyciem toola do modelowania wygląda typowo tak:
    • W toolu architekci robią system design. Do tego taki tool nadaje się praktycznie z marszu, do tego takie narzędzia zostały wymyślone.
    • Dalej development przechodzi na poziom modułów. Developerzy rzadko są biegli w modelowaniu i raczej od razu implementują (czytaj: kodują) swoje moduły.
    • Szczególnym problemem są automaty skończone (czy tak się mówi fachowo po polsku na statemachine?). W praktyce każdy kawałek który ma jakąś swoją zmienną przechowywaną pomiędzy wywołaniami i jakiegoś ifa zależnego od tej zmiennej, to już jest statemachine. Problem jest taki, że w implementacji nie widać zbyt dobrze, co ona właściwie robi - do tego służy statechart. Tyle że jeżeli statechart i implementację zrobimy niezależnie od siebie, to można spokojnie założyć, że obie te rzeczy wcześniej czy później się rozjadą. Porządna implementacja statemachine też nie jest taka całkiem trywialna, ludzie robią to często mnożąc ify w różnych miejscach kodu, a potem nie są w stanie tego wszystkiego opanować (to był przypadek modułu, z powodu którego leciałem do Meksyku). Prawdziwy zysk z MDD ma się wtedy, gdy kod statemachine jest generowany ze state diagramu (w moim przypadku, tym jednym ruchem udało się uniknąć dobrych paru baniek strat w euro).
    • Dokumentację modułu robi się, nawet jeżeli w tym toolu, to ręcznie i dopiero na późnym etapie.
    • Nawet jeżeli dokumentacja jest OK, to potem trzeba robić poprawki w kodzie, ręcznie nanoszone znowu do modelu, i na 90% dokumentacja przestaje dokładnie odpowiadać stanowi rzeczywistemu.
    • Robienie dokumentacji z modelu to też większy temat. W praktyce najczęściej diagramy przekleja się ręcznie do dokumentu w czymś innym. W Rhapsody generowało się z każdego diagramu (ręcznie) osobny dokument w Wordzie, z listą obiektów widocznych na diagramie i opisami do nich wziętymi z modelu, ale porządną dokumentacją nazwać tego nie można było. Zrobienie porządnych templatów do dokumentacji jest możliwe (chociaż nie w każdym narzędziu tego typu), ale to może być jeszcze więcej roboty, niż ze zrobieniem generacji kodu.
  • Nie wiem skąd ten pomysł, ale i EA, i Rhapsody (inne pewnie też, ale nie sprawdzałem albo nie pamiętam) mają taki ficzer, że jak dodać connector między dwoma obiektami, to ten connector pojawia się automatycznie na wszystkich diagramach gdzie te dwa obiekty są. Nawet jeżeli diagram jest zalockowany. No tylko strzelać do pomysłodawców - regularnie trzeba przeglądać wszystkie diagramy i usuwać z nich te niepotrzebne connectory.
  • U mnie, w automotive, w działce safety, zasadniczą sprawą jest requirement tracing. Same requirementy trzymane są zazwyczaj w IBM Doors, to jest server, do którego można się podłączyć z aplikacji. W odpowiednich miejscach modelu (i kodu, ale to nie jest ściśle wymagane) powinny być linki do requirementów, które dany element implementuje. No i tu też nie widziałem dotąd dobrze zrobionego połączenia z modelem, to zawsze jest prawa ręka za lewe ucho, potem puścić skrypt, a potem szukać gdzie linka jeszcze brakuje.

Ogólnie to jest tak, że MDD to świetny pomysł, tyle że w praktyce nikt nie ma czasu i szmalu żeby to zrobić. Guglanie za projektami które naprawdę zostały zrobione przez MDD nie przynosi prawdziwych rezultatów, tylko linki do opracowań teoretycznych, materiałów reklamowo-szkoleniowych producentów narzędzi i do dyskusji, dlaczego tego nie ma.

W praktyce toole do modelowania są używane jako trochę lepsze narzędzia do rysowania diagramów, i tyle. To warto było by zmienić. Za zmienianie weźmiemy się w następnym odcinku.

-----------------------------------------------------------------------------------------------------------------------

Dotyczy:

Kategorie:Programowanie

3 komentarze

Czas nieutracony (5) – Metamodel

Jak napisałem w poprzednim odcinku, na początku nie doceniłem stopnia komplikacji metamodelu AUTOSARa. A było to tak:

  • Metamodel definiuje mnóstwo klas obiektów i relacje między nimi (parent-child i asocjacje), To jeszcze nie jest nic specjalnego, mimo że obiektów jest mnóstwo.
  • Metamodel jest dystrybuowany jako projekt w EA. Można go sobie wyeksportować w formacie XMI, czyli wariancie XMLu. Jest też w formacie Ecore.
  • Parsowanie XMLa nie jest żadnym problemem, wygenerowanie wczytanej informacji tak, jak potrzebuję to też trywiał.

No i ta trywialność mnie zmyliła. Przeoczyłem jedną, bardzo istotną rzecz: Typowy projekt w automotive musi obsługiwać warianty. O co chodzi? Po prostu ten sam kod jest używany na przykład w różnych modelach samochodów, z różnym wyposażeniem. Albo może współpracować na przykład z wyświetlaczami od różnych dostawców. To są właśnie te warianty. Typowo wariant wybiera się przy kompilacji przez ustawienia jakichś #define (pre-build) albo w jakiś sposób wybiera konfigurację przy wykonaniu programu (post-build), ale AUTOSAR usystematyzował to. Technicznie (i w uproszczeniu) wygląda to tak, że do wielu obiektów można podczepić obiekt klasy VariationPoint, w którym jest zapisane (jako logical expression), dla jakich wariantów dany obiekt obowiązuje, i kiedy najpóźniej ma nastąpić wybór wariantu.

No i w czym problem?

  • Metamodel nie zawiera obsługi wariantów wprost - obiekty które mogą mieć warianty są tylko oznaczone odpowiednim stereotypem.
  • Żeby metamodel dał się używać w praktyce, trzeba go przetransformować do takiego z wariantami. Transformacje modyfikują strukturę metamodelu i dodają nowe obiekty.
  • Jest w opisie standardu dokument opisujący te transformacje, ale:
    • To jest skomplikowane jak jasna cholera.
    • W paru miejscach transformacje są niedospecyfikowane.
    • W innych miejscach dokument ma oczywiste błędy. Drobne, ale trzeba je znaleźć.
    • W praktyce trzeba zajrzeć do rzeczywistych plików zrobionych w działających narzędziach, żeby zobaczyć jak naprawdę ma być (a przynajmniej mieć tam takie same błędy jak wszyscy 🙂 - to się nazywa "kompatybilność").
  • No i oprócz tego same metamodele mają trochę błędów, zwłaszcza we wczesnych wersjach, i trzeba co nieco skorygować ręcznie.

No dobrze, powiecie, ale przecież ktoś już to musiał zrobić, inaczej nie istniałyby jakiekolwiek narzędzia do tego AUTOSARa?

Tak, zrobiło to konsorcjum, w Javie, jako plugin do Eclipse. Znaczy to jest wygenerowany handler do plików ARXML i do zarządzania tymi obiektami. Nazywa się to Artop, i jest dostępne po rejestracji. Wszyscy (chyba z wyjątkiem IBMa, który raczej zrobił wszystko ręcznie, i LieberLiebera, który na pewno zrobił ręcznie) używają tego Artopa. Wyjaśnia to, dlaczego wszystkie toole do AUTOSARa bazowane są na Eclipse - po prostu nikt inny nie przebrnął przez ten problem i nie zrobił swojego handlera.

Logo Artop

Logo Artop

Jak możecie się domyślać, nikt poza mną. To była druga najbardziej skomplikowana rzecz, jaką w życiu robiłem, dwa miesiące mi zajęło żeby doprowadzić to do działania, żeby móc importować i eksportować pliki AUTOSARowe zgodnie z metamodelem dla danej wersji. I jeszcze jak potem intensywnie rzecz testowałem, poznajdowałem i poprawiłem trochę błędów i problemów, co też dobry tydzień zajęło. Ale działa - jako jedyny na świecie niezależny taki handler. Nie wrzucam kodu transformera na żadną chmurę, githuba, ani nic podobnego - tylko na moje serwery niedostępne z zewnątrz, nie mogę ryzykować, że wycieknie.

Moje podejście jest inne, niż w Artopie - oni na podstawie metamodelu generują kod w Javie, ja generuje pliki z danymi metamodelu, interpretowane przez mój kod napisany ręcznie. Moje podejście jest elastyczniejsze - generuję raz, i używam do dowolnych celów, oni dla nowego celu muszą modyfikować generator i generować ponownie. Oprócz tego oni mają - według mnie - błędną koncepcję obsługi plików wygenerowanych według różnych wersji specyfikacji - używają najnowszej znanej wersji i bazują na kompatybilności wstecznej, a to może robić problemy. Ja obsługuję każdy plik w jego indywidualnej wersji, również jak są wczytane jednocześnie.

W następnym odcinku parę generalnych uwag na temat MDD.

-----------------------------------------------------------------------------------------------------------------------

Dotyczy:

Kategorie:Programowanie

Skomentuj

Czas nieutracony (4) – Trigger

Następny mój projekt był dla gwiazdkowców.

Wyświetlacze S-Klasse

Wyświetlacze S-Klasse (Źródło: Materiały prasowe Daimler AG)

Tu nie był to cluster, tylko te dwa wyświetlacze, ten po prawej miał touch. Obraz dla nich był generowany przez inny kawałek sprzętu, nie od nas. Kod był w bardzo dużej części wspólny dla obu urządzeń, oba miały też mniejsze wersje dla E-Klasse.

Sytuacja rynkowa zmieniła się tymczasem:

  • Moje korpo zrezygnowało z tworzenia własnych modułów standardowych, i po prostu kupiło firmę tworzącą takie. Na największego na rynku Vektora nie mieli dość kasy, kupili drugą firmę w kolejności - Elektrobit, z ich Tresosem.
  • Korporacyjne narzędzie do ARXMLi zrobiło się abandonware, ale jest używane do dziś, bo nie ma nic lepszego do dyspozycji.
  • Vektor udoskonalił swoje narzędzie do konfiguracji modułów, ale ono jest w korpo politycznie niekoszerne. To narzędzie też jest w Eclipse. Potrafi robić również diagramy, ale w ograniczonym asortymencie i nie w UMLu.
  • Pojawiło się inne narzędzie do ARXMLi, francuskie, firmy Dassault (tak, ci od samolotów), też na bazie Eclipse, nazywa się Autosar Builder. Ładnie wygląda, ma dużo teoretycznie świetnych narzędzi, ale to niestety typowy przykład co wychodzi, gdy narzędzie tworzy ktoś, kto go nie używa. To się po prostu do niczego nie nadaje i szybko wypadło z obiegu.

Ten projekt był pierwszym w korpo, w którym użyto modułów i narzędzi od kupionego właśnie Elektrobitu. No i oczywiście to ja miałem doprowadzić to wszystko do działania. Przećwiczyłem generację projektu w różnych kombinacjach dobre kilkaset razy, zrozumiałem wszystko, doprowadziłem rzecz do działania, ale MDD nie było w tym nawet śladu.

Ale pewnego dnia pojawił się Autosar Engineer, małej firmy LieberLieber z Wiednia. Był to plugin do Enterprise Architecta. Obejrzałem go - i poczułem się poważnie ztriggerowany. A jeszcze poważniej gdy ktoś zaproponował, żeby go użyć w projekcie. Już od dłuższego czasu planowałem takie narzędzie zrobić, to miało być przecież moje!

(nie chcę linkować do stron LieberLiebera, istnieje niezerowe prawdopodobieństwo, że przez analitykę znajdą źródło linka, przetłumaczą sobie googlem i teraz oni poczują się ztriggerowani).

Wiec przyjrzałem się temu dokładniej. Oni zrobili to tak:

  • Wybrali sobie z AUTOSARa trochę co częściej używanych obiektów
  • Zrobili ręcznie profil UML i MDG Technology z tymi obiektami.
  • Lekko scustomizowali EA tak, jak on na to pozwala w łatwy sposób.
  • Dorobili parę funkcji przez API EA, parę ikonek i obrazków i tyle.

To było naprawdę mało, i to mnie ruszyło. Ponieważ miałem już sporo doświadczenia z EA (chociaż ponad 10 lat wcześniejszego) i wstępną analizę problemu już robiłem to stwierdziłem, że przecież w dwa tygodnie mogę mieć tyle samo, a w cztery coś znacznie lepszego!

Więc zacząłem. Kupiłem Enterprise Architecta (dał się odliczyć od podatku 🙂 ) wziąłem Visual Studio Community Edition i ostro ruszyłem. W Javie napisałem wczytanie danych z metamodelu AUTOSARa, zagenerowałem z tego pliki profili i technology dla EA i w C# porobiłem trochę potrzebnej funkcjonalności jako plugin EA.  Całość nazwałem dumnie MaximumAUTOSAR, że niby ma to być docelowo AUTOSAR to the max. W cztery tygodnie faktycznie miałem coś o wiele lepszego niż ten LieberLieber, ale oprócz tego bardzo istotny wniosek - że tak zrobione, to nigdy nie będzie dobre. Z dwóch przyczyn:

  • Pierwsza to braki w API EA. Paru absolutnie podstawowych rzeczy nie dało się zrobić customizując ich standardowy Project Manager i inne okienka.
  • Druga leżała po stronie AUTOSARa i mojej. Moim założeniem było że wezmę sobie metamodele udostępniane przez konsorcjum i przetransformuję je programowo na pliki profilu/technologii EA. I tu nie doceniłem problemu. Szczegóły w następnych odcinkach.

Tak więc pojawiło się prawdziwe wyzwanie - nikt na świecie dotąd nie zrobił odpowiedniego narzędzia do AUTOSARa, i nie wyglądało żeby ktoś - poza mną - był w stanie to zrobić. Padł na tym nawet IBM, a wszyscy inni ograniczali się do rozwiązań bazujących na Eclipse (nie bez przyczyny - o tym dalej). A w Eclipse nie za bardzo da się zrobić modeling tool (chociaż niektórzy próbują, na przykład coś takiego).

A dlaczego nikt poza mną ma nie być w stanie? Bo to jest tak:

  • Fachowcy od takich narzędzi nie mają pojęcia o AUTOSARze i nigdy nie robili aktywnego developmentu w tej działce (to był przypadek IBMa i Dassault), stąd nie wiedzą, co jest naprawdę potrzebne i jak to ma działać.
  • Fachowcy od AUTOSARa nie mają pojęcia o robieniu takich tooli (cała reszta próbujących).

I na placu boju pozostaję ja, cały na biało.

Oprócz tego wkrótce LieberLieber wywalił cały ten projekt do kosza, więc na boisku zostałem prawie sam. Prawie, bo jest jeszcze jeden team: jacyś ludzie zrobili support AUTOSARa w MatLabie. Umieją wczytywać i wypisywać te ARXMLe i cośtam z tego generować. Na szczęście nie są oni dla mnie prawdziwą konkurencją, bo MatLab zasadniczo nie umie w UMLa i design (on nie do tego został wymyślony), i prawdziwe MDD to to jednak nie jest.

Ciąg dalszy oczywiście nastąpi.

-----------------------------------------------------------------------------------------------------------------------

Dotyczy:

Kategorie:Programowanie

5 komentarzy

Czas nieutracony (3) – Kontakt

Moim pierwszym projektem AUTOSARowym był taki dla trójliterkowców.

Cluster BMW Gen4

Cluster BMW Gen4 (Źródło: gdzieś z sieci)

W tym okresie na poważnie zaczęły wchodzić clustery całkowicie wyświetlaczowe, ale niektórzy klienci mieli wątpliwości. Ten klient uważał, że użytkownicy chcą widzieć prawdziwe, trójwymiarowe wskaźniki, a nie płaski obraz. Robili u nas dla nich testowo modele z wyświetlaczem 3D, ale klient zdecydował się na cluster ze wskazówkami i sporym wyświetlaczem (zwracam uwagę, że dolne części dużych wskaźników są rysowane na wyświetlaczu). Ale żeby przyzwyczajać klientów do nowej technologii, szybka miała być ciemna. W związku z tym widać było tylko to, co świeci, i cluster wyglądał wcale nie 3D, tylko bardziej płasko niż odpowiednio narysowany obraz na płaskim wyświetlaczu. Zdjęcie jest znalezione w sieci, tu szybka jest całkiem przejrzysta, w sumie nie wiem kiedy to zmieniono. Przy całym developmencie mieliśmy tylko przyciemniane szybki. Ale dość dygresji.

To był też pierwszy prawdziwie AUTOSARowy projekt w fabryce, w związku z tym wszystko dla wszystkich było nowe. Zacznijmy od ówczesnego stanu rynku w tej działce:

  • Moje korpo (w końcu jeden z głównych członków konsorcjum) zrobiło własne moduły standardowe i własne narzędzie do ich konfiguracji i robienia ARXMLi dla własnych modułów. Narzędzie było zrobione na bazie Eclipse, moduły miały duże braki w funkcjonalności.
  • Moduły MCAL były dostarczone przez producenta procesora (Renesas) i konfigurowane przy pomocy narzędzia zwanego Tresos, zrobionego przez firmę Elektrobit z Erlangen. To narzędzie było też oparte na Eclipse.
  • OS (system operacyjny) został kupiony od firmy Vektor Informatik. To jest wiodąca firma z branży narzędzi dla branży okołosamochodowej, wybiła się ona głównie na programie i sprzęcie do symulacji komunikacji na magistrali CAN, zwanym CANoe.
  • Oprócz tego parę innych, mniejszych firm od narzędzi próbowało wtedy wejść na rynek AUTOSARa, ale bez większych sukcesów.

Zacząłem czytać specyfikację AUTOSARa, ale potrwało ze dwa miesiące zanim zacząłem chociaż z grubsza rozumieć, co tam jest napisane. Tymczasem zostałem poproszony żeby zrobić skrypty do generacji kodu przy pomocy tego korporacyjnego narzędzia, i tak się zaczęło.

Im dalej wgłębiałem się w specyfikację, tym bardziej widziałem, że to wszystko jest robione z myślą o modelowaniu, znaczy MDD (Model Driven Development). I to mi się podobało. Bo:

Mój pierwszy projekt w automotive, około 2001, był robiony w Rhapsody (wtedy jeszcze firmy I-Logix z Izraela), całkowicie MDD, z generacją kodu z modelu. Całego kodu - przede wszystkim ze statechartów. I wyszło nieźle. To był okres hype na modelowanie, wszyscy tego próbowali. Jeszcze następny projekt - nie w automotive - robiłem w MDD, z Enterprise Architect, tu akurat to ja opracowałem cały proces, i efekty były świetne. Potem hype opadł, bo w wielu zastosowaniach generacja kodu z modelu była zbyt wolna, albo ludzie mieli zbyt wygórowane oczekiwania, albo robili coś źle... Ale według mnie MDD to jest ten "właściwy" sposób robienia softu.

Więc zacząłem rozglądać się za narzędziem. Wcześniej w korpo używali Borland Together Architect, ale to była beznadzieja. Zauważyłem jednak, że właśnie przeszli na Rhapsody, tymczasem IBM Rhapsody. A po dokładnym obejrzeniu go odkryłem, że jest tam coś do AUTOSARa.

Coś tam było, ale dokumentacji do tego było wszystkiego kilka stron gdzieś bardzo głęboko w sieci, te strony mówiły o AUTOSARze v3.x, a dołączony pakiet implementował wersję 4.0.2. Co najmniej połowa informacji na tych stronach już na starcie nie zgadzała się z rzeczywistością. Musiałem mocno poeksperymentować, żeby dojść jak to w ogóle da się używać i co to robi. No ale jakieś ARXMLe do modułów dało się w tym wygenerować. Udało mi się też połączyć je z kodem, ale wygodne w użyciu to nie było. Przy generacji kodu pojawił się kolejny problem - generator kodu Rhapsody był w roku 2001 w pełni konfigurowalny i open source, w 2013 już nie. Konfigurować dał się on tylko setkami properties w ustawieniach, z których jakieś 3/4 było nieudokumentowane, przy większości trzeba było w ogóle wiedzieć, że takie nigdzie nie opisane property w ogóle istnieje. Do tego ten generator kodu był zrobiony dla programów pecetowych, był tam jakiś wbudowany scheduler (zwany frameworkiem), który oczywiście totalnie nie pasował do pojedynczego modułu schedulowanego z zewnątrz istniejącym schedulerem.

Po dłuższych poszukiwaniach znalazłem jakiś dokument opisujący oficjalnie niesupportowany wariant generowania kodu bez tego frameworku, i nawet udało mi się coś z sensem wygenerowac. Po drodze udało mi się nawiązać kontakt z dwoma głównymi developerami Rhapsody, byłem takim key userem tego całego ficzera, że dwa razy kopsnęli się do mnie z Izraela do Niemiec, żeby przedyskutować ze mną moje problemy. Nawet dołączyli rozwiązanie części tych problemów do następnego releasa Rhapsody (wersja 8.1.3, jeżeli dobrze pamiętam), ale nie przeszedłem na nią, bo pozmieniali tyle innych rzeczy, że nie udało mi się dopasować projektu do tej wersji w rozsądnym czasie.

Jednym z problemów było to, że po każdej generacji kodu musiałem robić drobne poprawki w generowanym kodzie. Ja mogłem z tym pracować, twardy jestem, ale nie dało się tego dać do ogólnego użytku. Ale nawet w takiej wersji uratowałem przed skancelowaniem przez klienta (i paroma bańkami w plecy dla korpo) projekt pochodny od tego pierwszego, robiąc statecharty i generując z nich kod. To była ta akcja z wyjazdem do Meksyku, o której pisałem.

Cluster BMW Gen 3.1

Cluster BMW Gen 3.1 (Źródło: gdzieś z sieci)

Jak widać, ten cluster ma też fragment zegara rysowany na wyświetlaczu, ale tu klient od razu zrezygnował z ciemnej szybki. Nie wiem czemu podświetlenie jest na pomarańczowo - sam zmieniałem je na białe, bo klient już pod koniec projektu powiedział, że pomarańczowe jest odbierane jako dziaderskie i żeby to zmienić. No ale kolor podświetlenia był konfigurowalny przez coding, pewnie w niektórych wersjach wrócili do pomarańczowego

Niedawno zajrzałem, co IBM zrobił przez te kilka lat z supportem AUTOSARa w Rhapsody - i nic nie zrobił. Nadal znajdują się dokładnie te same strony z opisem do od lat nieaktualnej wersji, nic się nie zmieniło, sprawa umarła, największy gracz odpadł.

No ale to nie koniec. Dalej w następnym odcinku.

-----------------------------------------------------------------------------------------------------------------------

Dotyczy:

Kategorie:Programowanie

Skomentuj

Czas nieutracony (2) – Standardy

Z poprzedniego odcinka można wywnioskować, jakie były wtedy największe problemy w software developmencie dla automotive:

  1. Wynajdywanie koła ciągle od nowa - każdy dostawca wymyślał swoje rozwiązania dla standardowych funkcji systemu, a i to nie tylko raz. To są wielkie koszty i duże ryzyko że czegoś się nie uwzględniło albo nie przetestowało dobrze.
  2. Brak jakichkolwiek standardów w kodowaniu specyficznych dla projektu modułów - to jest C, tu można wszystko. A jak można wszystko, to na pewno znajdzie się ktoś, kto zrobi coś paskudnego.

AUTOSAR (uwaga: piszę tu o wariancie zwanym Classic, tymczasem powstał jeszcze wariant Adaptative, przewidziany dla developmentu w C++ i raczej dla tych części nie real-time) stara się rozwiązać oba te problemy. Przy pierwszym: Do standardowej funkcjonalności wymyślono standardowe moduły, z dobrze wyspecyfikowanym API, konfigurowane przy pomocy plików XML (rozszerzenie .arxml). Idea jest taka, żeby te standardowe moduły były produkowane przez wyspecjalizowane firmy, a wszyscy mają je po prostu kupować i stosować. Wymyślono również standardowe moduły driverów sprzętu - producenci używanych procesorów dostarczają te drivery (zwane MCAL - MicroController Abstraction Layer) użytkownikom.

Drugi problem ma załatwić standardowa metodologia tworzenia modułów, Idea jest taka, że tworzymy opis modułu z jego portami, interfejsami itd. w ARXMLu. Od swojej strony uzupełniamy go tylko trochę kodem, a połączenia międzymodułowe są również definiowane w ARXMLu. W trakcie budowania systemu generowany jest kod "klejący" te moduły.

Logo AUTOSAR

Logo AUTOSAR

Ogólnie idea nie jest zła. Zalety:

  • Moduły standardowe mogą być porządnie zrobione i solidnie przetestowane przez wyspecjalizowane zespoły, koszt tego rozkłada się na mnóstwo projektów, a nie tylko na kilka u jednego dostawcy.
  • Moduły specyficzne dla projektu dostają sensowne ograniczenia swobody robienia głupot.
  • Reusowalność modułów jest lepsza, dzięki porządnej, formalnej definicji ich interfejsów.
  • Rozwiązanie idzie cokolwiek w modnym obecnie kierunku low code. To nie jest złe.

Są też problemy:

  • To jest jednak zasadnicza zmiana paradygmatów, z niskopoziomowego rzeźbienia w C na modelowanie obiektów. Niestety użytkownicy (czytaj: developerzy) nie są w szerokiej masie do tego przygotowani.
  • Przy modułach standardowych problem w sumie tylko przesunął się z poprawnego kodowania na poprawne konfigurowanie, ale nie stał się przez to wiele prostszy. A nawet przeciwnie - specyfikacja jest o wiele bardziej złożona niż własne rozwiązania, ma o wiele więcej możliwości i jest trudniej.
  • Nie wszystko wyszło super - są kawałki w których specyfikacja nie jest zbyt dobra i trzeba mocno kombinować, albo wręcz ją omijać.
  • W specyfikacji przyjęto pewien model hardware, który nie zawsze jest spełniony. Na przykład w aktualnym projekcie używamy procesora który jest de facto niekompatybilny z AUTOSARem w jednym punkcie (długo by opisywać, ale chodzi o pewne, dość nieoczekiwane zależności w sprzęcie) i trzeba było się narobić żeby ten problem ominąć.

Pierwszą jako-tako nadającą się do użytku wersję specyfikacji AUTOSARa wypuszczono w roku 2007 jako wersję 3.0, a w końcu 2009 pojawiła się wyraźnie lepsza wersja 4.0. Podejście proponowane przez konsorcjum było jednak na tyle inne od dotychczasowego, że akceptacja standardu była bardzo powolna. Najpierw projekty tylko eksperymentowały z nową technologią. No ale członkowie konsorcjum chcieli wreszcie mieć coś z tych lat wkładania kasy, i powoli zaczęli wymuszać używanie nowego standardu przez dostawców. Pierwszy całkiem AUTOSARowy projekt zrobiony u nas zaczął się gdzieś w 2013, i ja tam trafiłem już w stosunkowo wczesnej fazie.

Dalej w następnym odcinku.

-----------------------------------------------------------------------------------------------------------------------

Dotyczy:

Kategorie:Programowanie

Skomentuj

Czas nieutracony (1) – Wstęp

Trzy lata to sporo czasu, uzasadnione jest pytanie co ja właściwie robiłem, że nie miałem czasu nawet na naprawienie bloga. Bardzo chętnie o tym opowiem, opowieść będzie dłuższa. Czas nie był zmarnowany, stąd tytuł (zapożyczony oczywiście). I uprzedzam z góry, że cykl będzie zawierać spore elementy autoreklamy 🙂 No i pewnie wykorzystam to, co tu piszę jako pierwszy szkic szkicu moich przyszłych prezentacji.

Zacznijmy od tego, że praca w branży samochodowej nie zaspokaja mojej potrzeby kreatywności. Typowy projekt w tej branży to implementacja dokładnych requirementów klienta. Nieważne jak dobre są twoje pomysły, trzeba spełnić requirementy i już. Niektóre z tych requirementów są negocjowalne, ale dotyczy to raczej zbyt wygórowanych wyobrażeń klienta co do tego, co jest możliwe. Nowa funkcjonalność, albo znaczące zmiany w zdefiniowanej funkcjonalności mają przyzerowe szanse na akceptację przez klienta.

W związku z tym można coś tworzyć jedynie w architekturze, implementacji i toolingu. Z tym że z tym toolingiem to też nie tak prosto - w korpo jest specjalny dział, który zajmuje się toolingiem i przeforsowanie swoich pomysłów na skalę większą niż aktualny projekt jest mało realne.

Mój pierwszy projekt w automotive robiłem około roku 2001 (Headunit AUDI C6, to ta skrzyneczka ze szczeliną na CD i przyciskami, ta w głębi).

Małe stanowisko testowe elektroniki do Audi A6

Małe stanowisko testowe elektroniki do Audi A6

Cały nasz zespół był nowy w tej działce, musieliśmy nauczyć się mnóstwa rzeczy, jak to się robi w automotive. A robi się tak:

  • Większość kawałków do automotive to są rzeczy real-time (zainteresowanym radzę nie czytać hasła z polskiej wiki, bo bez sensu jest) - znaczy muszą reagować w czasie nie dłuższym niż zdefiniowany. W większości wypadków nie ma żadnego GUI.
  • Jeżeli jakieś GUI jest (na przykład cluster, navi czy HUD), to typowo rozdziela się część real-time i część od GUI. Znaczy każda z tych części ma osobny core procesora (każdy core może być totalnie inny), albo mieć swój procesor.

Dalej skupimy się na tej części niegraficznej - bo jednak ta grafika to jest w nielicznych kawałkach elektroniki samochodowej. Więc te kawałki niegraficzne:

  • Są podłączone do jakiegoś busa, zazwyczaj CAN. No i oczywiście muszą obsługiwać komunikację w dwie strony i z wymaganiami (teraz wiele telegramów jest E2E protected i/lub szyfrowanych)
  • Ponieważ to jest real-time, to musi w tym chodzić regularny multitasking, z przerwaniami oczywiście też.
  • Każdy kawałek zapamiętuje swoje błędy, czyli musi mieć pamięć nieulotną.
  • Ostatnimi czasy w to wszystko wchodzi poważne security z kluczami publicznymi i prywatnymi, certyfikatami, Certificate Authority itd.
  • Część z tych kawałków jest istotna dla bezpieczeństwa i w tym momencie wchodzą wymagania functional safety, z wszystkimi tego konsekwencjami.
  • Używany sprzęt jest bardzo różny, procesory użyte w kolejnych projektach mogą się różnić wszystkim, nawet byte orderem, i trzeba o tym pamiętać przy kodowaniu.
  • Językiem w którym to się pisze jest najczęściej C, znacznie rzadziej C++ (to raczej przy tych częściach z GUI, ale nie tylko).
  • Niemal każde urządzenie jest produkowane w różnych wariantach, na przykład do różnych modeli samochodów, albo może używać przykładowo wyświetlaczy od różnych producentów. W związku z tym, kod zawiera mnóstwo konstrukcji #ifdef #else #endif.
  • Programiści pecetowi nie zdają sobie tego sprawy, ale w embedded pamięć występuje w wielu rodzajach w jednym systemie. Pecet ma RAM i już - w embedded mamy szybki RAM, wolny RAM, szeregowy RAM, video RAM, code FLASH, data FLASH, EEPROM, RAM z podtrzymaniem, ..., każdy rodzaj ma inne właściwości, prędkość, sposób dostępu ... . I przy każdym obiekcie musimy powiedzieć, w której pamięci on ma wylądować. I pilnować, żeby się zmieściło. Do tego bywa że na przykład, że dostęp do adresów nieparzystych jest o wiele wolniejszy niż do parzystych, i trzeba to uwzględniać.
  • Przy programowaniu na pececie operujemy na abstrakcjach sprzętu. Mechaniczny wyłącznik ma na pececie stany wyłączony i włączony, a w embedded musimy uwzględniać na przykład drgania styków. Innego sprzętu to też dotyczy - trzeba uwzględniać całą fizykę stojącą za sprzętem.
  • O, fizyka - pamięci EEPROM/FLASH mają ograniczoną ilość zapisów, które są w stanie znieść, i trzeba liczyć, czy to wystarczy na planowany czas życia samochodu. W Tesli dowiedzieli się o tym dopiero niedawno i musieli zrobić recall na sto kilkadziesiąt tysięcy samochodów z wymianą sprzętu, bo coś bez umiaru pisało logi do flasha.
  • W pececie nie musimy martwić się zasilaniem - ono po prostu jest. W samochodzie musimy uwzględniać, że napięcie zasilania może być zbyt niskie lub zbyt wysokie (chwilowo lub trwale), i odpowiednio reagować.
  • Podobnie z temperaturą - jak urządzenie robi się za gorące, trzeba reagować (na przykład wyłączając coś, co się grzeje).
  • I tak można jeszcze długo - w automotive praktycznie nie występują programiści po "normalnej", pecetowej informatyce. Niemal wszyscy są po studiach mniej lub bardziej związanych z elektroniką, informatycy którzy tu czasem trafiają wkrótce uciekają z krzykiem.
  • Używany procesor nigdy nie jest za mocny - zawsze jest dobrany tak sknersko, że trzeba się nagimnastykować żeby się wyrobił. Podobnie pamięci nigdy nie ma za dużo.

Dla porządku jeszcze trochę o kawałkach z GUI:

  • GUI zazwyczaj chodzi na derywatach UNIXa, z klasycznym POSIXowym API.
  • Część graficzna ma często podłączony jakiś mocniejszy bus, na przykład Ethernet albo MOST.
  • Języki programowania są tu różne, najczęściej to C++, ale widziałem na przykład projekt w Javie.

Jeszcze jakieś 10 lat temu, każda z firm robiących te kawałki prawie wszystko robiła sama - udział standardowego kodu był znikomy. Projekty dla różnych klientów przez jedną firmę miały często tą samą funkcjonalność robioną całkiem inaczej, reusability było niewielkie. To jest oczywiście koszt i potencjalne ryzyko, więc większość wiodących firm samochodowych i główni poddostawcy zawiązali w roku 2002 konsorcjum, które miało ten stan rzeczy zmienić. Nazwano to AUTOSAR. Założenia AUTOSARa omówię w następnej notce, a potem dojdę do miejsca, w którym wkraczam do gry 🙂

-----------------------------------------------------------------------------------------------------------------------

Dotyczy:

Kategorie:Programowanie

5 komentarzy

Twit Programmers of the Year (6)

Blog robi się powoli monotematyczny, dziś znowu o programowaniu, głownie na Androida.

Klient już czwarty tydzień załatwia papiery, a oczywiście terminy zakończenia poszczególnych etapów już ustalone i potem czasu będzie mało. No ale nie moje zmartwienie, ja zrobię co się da, ale tym razem o nadgodzinach mogą zapomnieć. Za to siedzę w domu i rozpracowuję prywatne programowanie pod Androida na koszt pracodawcy. Całkiem dobry układ. Jakbym był na własnym rozrachunku, to mogłoby boleć, a tak nie mam stressu (oczywiście poza stressem związanym z oddawaniem co miesiąc braterskiej części tego co klient płaci pracodawcy, ale coś za coś).

Do mojego nowego komputera dokupiłem porządny zasilacz. Dwa tej firmy (BeQuiet!) już w domu miałem, do serwera kupiłem nówkę, modularnego (znaczy kabelki dołącza się według potrzeby) serii 8 (im mniejszy numer, tym starszy, aktualne serie to 11), drugi to była używka dla syna, niemodularny serii 8 (syn ma komputer w normalnej obudowie mini tower, więc kabelki nie przeszkadzają specjalnie w przepływie powietrza). Teraz też nastawiłem się na używkę na eBayu, modularnego serii 7 lub 8. Prawie aktualne (serii 10) jako używki chodzą po 70-80 EUR, jak mocne to nawet wyżej. Serie 7 i 8 dają się kupić za jakieś 35-40 z wysyłką. Udało mi się wylicytować za zaledwie 31 z wysyłką, bo sprzedawca się trochę przechytrzył wystawiając cenę startową aż 25 EUR i nikt poza mną się nie zainteresował. A zasilacz jest z bardzo drogich serii high-endowych (Dark Power Pro P7), wygląda na nie używany (niemal wszystkie kabelki mają jeszcze oryginalne zawieszki), jak go obejrzałem to szczęka mi opadła. Już opakowanie wyraźnie różni się od tych tańszych (ma okienko, kabelki pakowane są indywidualnie w kartoniki), zasilacz jest trochę większy niż standardowy (znaczy pasuje jako ATX, tylko w jedną stronę jest trochę dłuższy, w moją małą obudowę wszedł bez problemu). Kabelków jest duży asortyment w różnych kombinacjach, wentylator zasilacza jest podłączany do złącza monitoringu na płycie głównej, a zasilacz może jeszcze sterować czterema dodatkowymi wentylatorami. Praktycznie go nie słychać, nawet z bliska. Super rzeczy, te zasilacze, polecam.

Decyzja o zrobieniu sobie komputera z 8GM RAM była bardzo dobra - system + Thunderbird + Firefox + inne drobiazgi + Android Studio + emulator biorą łącznie 6-6,5 GB, jeżeli ktoś ma zamiar próbować robić apki na 4GB to odradzam z góry, szkoda nerwów.

Wróćmy do programowania. Próbuję robić aplikację, i Android nie za bardzo mi się podoba. Znaczy API sporo potrafi, jest tam trochę niezłych koncepcji, ale wyraźnie za mało zastanawiali się nad usability. Bo wygląda to tak:

Aplikacja Androidowa zbudowana jest z Activities. Activity (upraszczając) to jest screen + kod do niego, ma to swój wieloetapowy lifecycle, można wydzielić sobie reusable kawałki GUI zwane Fragment. Fragment ma znowu swój lifecycle, trochę inny niż Activity. No i porządnego, pełnego diagramu tych lifecykli nie znajdziecie na http://developer.android.com, trzeba szukać gdzie indziej. Zasadniczy problem polega jednak na tym, że w Androidzie wszystko jest asynchroniczne, nie ma nawet czegoś takiego jak windowsowy dialog modalny. Nawet okienko w rodzaju Yes/No/Cancel jest niemodalne, aplikacja biegnie dalej i trzeba wszystko synchronizować we własnym zakresie. Nie byłby to aż taki wielki problem, gdyby nie to, że ma to również znaczenie podczas lifecycle Activity/Fragmentu. Na przykład mogą one wymagać uprawnień dostępu do jakichś serwisów (na przykład kamery). I jak praw nie ma to albo trzeba o nie interaktywnie zapytać, albo rzucić jakimś błędem. No ale to jest w trakcie startu, nasz kawałek jeszcze nie jest w żadnym stabilnym stanie! Nie da się zatrzymać startu, a o wyniku zapytania użytkownika (czyli czy w ogóle jest sens startować) dowiemy się dopiero później. Przecież to wcale nie chce współgrać ze sobą! Zacząłem więc kombinować jak powinna wyglądać architektura standardowej aplikacji, żeby to wszystko sensownie działało i to wcale nie jest proste. Poguglałem i widzę, że co bardziej kumaci deweloperzy też mają podobne uwagi i kombinują różne rozwiązania. Muszę jeszcze trochę poczytać, co proponują. Na razie znalazłem rady żeby robić Reactive Programming przy pomocy JavaRx, no jest to jakaś propozycja, ale nie jestem całkiem przekonany czy będzie to pasować do moich koncepcji.

Ale tak według mnie, to powinno być zadanie projektantów systemu! Jeżeli każdemu deweloperowi każemy wymyślać koncepcje, jak by tu ogarnąć chaotycznie zaprojektowany system, nie dając mu nawet szkicowych szablonów rozwiązań, to z góry można założyć, że minimum dziewięćdziesiąt kilka procent wymyślonych rozwiązań będzie marnych. Nawet jak deweloper jest ogólnie dobry, to dopiero po paru skończonych aplikacjach będzie wiedział, co robił źle. Co się dzieje jak nie ma patternów to ja widzę na codzień w pracy. Na moje oko to Androidowi brakuje jakiejś porządnej warstwy albo frameworku żeby łatwo dało się pisać bardziej złożone aplikacje. Bo proste quick and dirty idzie łatwo i przyjemnie, ale porządne, z pełną obsługą błędów i wszystkimi szykanami to duży problem. Powiedziałbym, że to prawie jak programowanie aplikacji windowsowych bez MFC. (Tylko nie bierzcie tego porównania zbyt dosłownie - API Androida jest znacznie bliższe MFC niż czystym Windowsom z ręcznie robionym event loopem, w końcu sporo lat minęło od tamtych czasów, tyle że API Androida jest o wiele bardziej skomplikowane niż windowsowe).

A tu jeszcze dokłada się fakt, że system jest w ciągłej zmianie. Nowe idee się pojawiają, stare zmieniają się (i to często więcej niż raz), jeżeli aplikacja ma chodzić na iluś wersjach wstecz to zaczynają się schody. Google dostarcza biblioteki robiące kompatybilność wsteczną, ale o dokłada tylko następny stopień złożoności - której trzeba użyć, a bez której można się obyć. A potem aplikacja na latarkę ma dwa megabajty, bo ciągnie ze sobą bez sensu ileś bibliotek kompatybilnościowych - nie są reusowalne w systemie, o nie. Ma to swoje uzasadnienie w koncepcji systemu (każda aplikacja to osobny user unixowy i nie ma sharingu czegokolwiek wprost między aplikacjami, zawsze musi to iść przez mechanizmy systemowe), ale skutki są niemiłe.

Dla ilustracji: Najstarsze urządzenie Androidowe jakie w domu mam, ma wersję Androida 4.1.2 (kryptonim: Jelly Bean, co to za US-amerykański pomysł, żeby nazywać wersje od jakichś obrzydliwych słodyczy, Lollipop, Marshmallow, rzygać mi się chce jak to czytam) to jest API numer 16. Logiczne więc, że chcę żeby moje apki chodziły przynajmniej od tej wersji. Ma to oczywiście również związek z wielkością rynku docelowego - w użyciu są urządzenia rożnych wersji, im wcześniej zaczynać, tym większa ilość potencjalnych klientów. Startując od API 16 pokrywamy jakieś 96% używanych na świecie urządzeń, im późniejsze API tym urządzeń mniej. Nadchodzący Android 8 (SDK i emulacja już jest, można sobie obejrzeć) to będzie API 26. W wersjach 4.x prawa dostępu były akceptowane przez użytkownika podczas instalacji, przy braku akceptacji aplikacja nie była instalowana. W późniejszych wersjach użytkownik był pytany dopiero przy starcie aplikacji i mógł odpowiedzieć tak albo nie, zależnie od humoru, a aplikacja mogła mu pokazywać wyjaśnienie, po co potrzebuje dostęp do tego. No i to oczywiście są kompletnie różne koncepcje, jednolite obsłużenie tego żeby chodziło w dowolnej wersji jest trudne. Ponieważ jest trudne, to Google wrzucił na GitHuba całkiem niezłą bibliotekę do tego (nazywa się easypermissions), zastrzegając sobie przy tym brak jakiejkolwiek odpowiedzialności i wsparcia, ale ja się pytam, dlaczego to nie jest wprost w API, a przynajmniej w SDK? I skąd początkujący developer ma wiedzieć, że takie rozwiązanie w ogóle jest, a nawet, że go potrzebuje?

Co do marnej obsługi wyjątków, na którą narzekałem poprzednio to powoli widzę, dlaczego nie dało się zrobić jej porządnie, z checked exceptions, ale oczywiście to nie jest komplement. Znalazłem natomiast, co można zrobić z nieobsłużonymi wyjątkami - jest taki serwis, do którego informacje o wyjątkach mogą być wysyłane. Nazywa się to fabric, wymyślił to Twitter, teraz należy do Googla. Ze dwie linie w programie, rejestracja w sieci i można mieć informacje o wszystkich nieobsłużonych wyjątkach w swojej aplikacji u dowolnego użytkownika z wszystkimi danymi (stack trace, sprzęt, czy rootowany, wersja systemu itd.). Do tego można mieć jeszcze life data o swojej aplikacji - ilu użytkowników używa jej w danej chwili, chyba nawet można wiedzieć co robią (jeszcze nie sprawdzałem tak dokładnie). Z jednej strony piękna rzecz przy developmencie, z drugiej to aż się zimno człowiekowi robi - przy każdym starcie aplikacji wysyłany jest do Google również AdvertisingId, co pozwala imiennie zidentyfikować każdego użytkownika z wszystkimi jego najprywatniejszymi danymi. Deweloper oczywiście tego nie dostaje do ręki, ale Google to ma. Podobno większość aplikacji używa tego fabrica, więc żadna różnica czy ja go użyję, czy nie - Google ma użytkownika na talerzu i tak. No i jeszcze trzeba zainstalować plugin u siebie, w Android Studio, i ten plugin zna każdy projekt w workspace. Kto zagwarantuje, że Google nie ogląda sobie tych projektów żeby wyłapać nowe idee i wejść z tym samym wcześniej?

Pamiętam hejt na Microsofta ćwierć wieku temu (Gates w mundurze SA, z flagą w której swastyka została zastąpiona logo Windowsów, na czele rzeszy SA-manów, pod hasłem "Ein Reich, ein Führer, ein OS") , pamiętam jak mieli koncepcje żeby Windowsy były na wszystkim (Windows for Pen, Windows for TV...), wczesne reklamy Apple sugerowały że Microsoft to Wielki Brat. No ale przecież najdalej posunięte pomysły MS to było małe miki w porównaniu z tym co robi "Don't be evil" Google. A Google jakoś nikt w podobny sposób nie karykaturuje.

Rysunek o MS  znalazłem tylko we fragmencie, pewnie pousuwali te całe ze względu na tekst.

Ein Reich, ein Führer, ein OS - to była gruba przesada

Ein Reich, ein Führer, ein OS - to była gruba przesada

-----------------------------------------------------------------------------------------------------------------------

Dotyczy: ,

Kategorie:Programowanie

14 komentarzy

Twit Programmers of the Year (5)

W pracy skończył mi się projekt, inny dział chce mnie koniecznie do innego projektu, tym razem dla klienta z trójramienna gwiazdą, ale zanim papiery załatwią to jestem w domu na koszt firmy. Pierwszy raz w życiu nie mam bieżącego projektu. Całkiem fajnie - wyporządkowałem już pół piwnicy i dalej walczę z programistycznymi twitami od Androida.

 Miałem już wszystko poustawiane, w Eclipsie, domowy serwer Git-a, Jenkins, itd., wymyśliłem czym się pobawię na początek i zacząłem ściągać przykładowe aplikacje do analizy. Na początku wziąłem jakieś stare, i wszystko było OK. Potem zassałem coś aktualnego od Googla i nie poszło. Bo chciało mieć niejakiego Gradla, to taki nowy pomysł na make. To dołożyłem Gradla, ale dalej coś się nie zgadzało. To zaktualizowałem Android SDK i dopiero się zaczęło. Nic już się nie chciało kompilować. Po dłuższej chwili ciężkiej walki poczytałem co o tym piszą w sieci i wyszło, że Google wycofał się z supportu developmentu pod Eclipse w końcu zeszłego roku, a całkiem niedawno poprzestawiał coś w SDK tak, że w Eclipse nie ma już szans. Tylko Googlowe Android Studio. (Uprzedzając wypadki - jak się cofnąć z wersją SDK Tools, to Eclipse jeszcze działa, przynajmniej z projektami w starej strukturze).

Cóż było zrobić - zainstalowałem Android Studio. No i mać, mać, mać, ono na 4GB RAM pod Linuxem się ślimaczy! Mam wystartowany tylko browser (w końcu muszę mieć doku) i Android Studio i po chwili 1 GB w swapie. Tak się nie da pracować! O puszczeniu równolegle emulatora Androida mogę zapomnieć.

No i znowu - co zrobić, trzeba nowy komputer. Mojemu notebookowi 7 lat stuknęło, dotąd wystarczał, ale pamięci rozszerzyć się nie da. Ale teraz koncepcja będzie inna. Notebook ma w zasadzie tylko dwie zalety:

  • Wszystko jest w jednym kawałku i łatwo go przenieść albo zabrać ze sobą
  • Ma w środku UPS-a (w pierwszym świecie nie jest to jednak specjalnie potrzebne, sprawdzić czy nie USA)

Poza tym same wady, a największa to to, że musisz zaplanować i zapłacić już dziś, twoje potrzeby na jutro i pojutrze. Jak się nagle pojawi całkiem nowa, niezaplanowana potrzeba w sprzęcie, to notebook musi być nowy. A jak zaplanowałem moje potrzeby na jutro, to wyszedł mi notebook z kategorii 1000+ EUR. Sorry, ale nie. Nie przy takich wadach:

  • Jak wypasiony taki notebook by nie był, to i tak wszystko w nim jest w wersji spowolnionej w porównaniu z desktopem.
  • Klawiatura zawsze jest w niestandardowym układzie, nawet jak to jest 18''. Do tego klawisze o krótkim skoku, i od pewnego czasu wszyscy robią takie, żeby się nie dało wyczuwać granic miedzy nimi. Po podświetleniu bajerancko wygląda, ale dobrze pisać na tym się nie da. I zazwyczaj jest za wysoko.
  • Teoretycznie można podłączyć klawiaturę na USB, ale wtedy ekran wychodzi za daleko.
  • Można podłączyć drugi ekran, ale wtedy nie da się mieć klawiatury na środku (czytaj: Co chwilę trzeba kręcić głową), albo patrz punkt poprzedni.
  • Przy pracy kabelek i tak trzeba mieć, do prądu, nie wierzcie w reklamy o bezkabelkowej wolności
  • Podłączenie do serwera idzie przez WiFi (czyli trochę wolne), albo trzeba mieć drugi kabelek.
  • Te twity od notebooków wymyśliły sobie kiedyś dotykowe wyłączniki, zwłaszcza do WiFi. Autora rozwiązania należałoby dla przykładu rozstrzelać - w większości notebooków z jakimi miałem do czynienia bardzo łatwo jest dotknąć  tego wyłącznika przypadkiem, potem nagle nie ma połączenia z siecią i nie wiadomo dlaczego. Gdyby był mechaniczny, to by się  wyłączenie poczuło, a tak co i raz ciśnienie skacze.

I tak dalej. Więc nowa koncepcja: skręcę sobie desktopa wykorzystując część elementów które już mam (zasilacz, karta graficzna, dysk z notebooka (bo miałem w nim dwa)), tylko Linux. Pracuję na stole, komputer będzie na półce, do monitora pociągnę jakieś 3,5 m kabelka i będę mógł pracować jak dotąd, a po robocie odstawić monitor na półkę i mieć wolny stół. I tak:

  • Obudowę kupiłem taką samą jak do serwera. Przy okazji się okazało, że Cooltek nie jest jej producentem, robi je firma Jonsbo i oni mają jeszcze kilka innych wariantów małej, zgrabnej obudowy na płytę w formacie MicroATX i zasilacz ATXowy. Niestety żadna z nich nie ma miejsca na dysk optyczny, ale to nic, później dokupię zewnętrzny na USB.
  • Wentylator zasilacza z piwnicy hałasuje przy starcie, ale potem się uspokaja. To też nic, wkrótce kupie używany zasilacz firmy BeQuiet. One są takie świetne, że naprawdę nie warto kupować nówki sztuki, paroletnia używka chodzi kolejne lata bez zarzutu. A nówki tanie nie są.
  • Kupiłem najtańszą płytę główną jaką się dało, za 40 EUR (po przeczytaniu testu, z którego wyszło że nie ma różnicy w prędkości między tą, a znacznie droższymi).
  • Procesor też był najtańszy (za niecałe 30 EUR). I tak według indeksów prędkości jest dwa i pół raza szybszy od tego z notebooka, a jeszcze różnica w prędkości busa, VT (Virtualisation Technology) support, ...
  • 8GB RAM DDR4 nie daje się kupić za bezcen.
  • Dysk 2,5'' z notebooka jest całkiem spoko, jest i tak dwa razy szybszy od tego, który był tam oryginalnie.
  • Kupiłem set klawiatura/mysz bezprzewodowe, Cherry, teraz wreszcie daje się pisać w tempie i bez zmęczenia.
  • Monitor miał być 22'' (bo tyle miejsca jest na niego na regale), miał mieć VGA, DVI i HDMI + głośniki i wyjście na słuchawki. Tu wyszło, że w rachubę wchodzi tylko jeden model Iiyamy. Też jest spoko.
  • Do monitora pociągnąłem cztery pięciometrowe kabelki (zasilanie, HDMI, audio i USB, USB musiał być z repeaterem). Kabelki owinąłem razem taką spiralą, w sumie jest to jak jeden grubszy kabel, handling jest świetny.
  • Dałem sobie spokój z Windowsami, i tak coraz rzadziej w ogóle bootowałem na Win. A używałem raptem ze trzy programy bez odpowiedników linuksowych (IrfanView, Picture Shark, Elster Formular, ...), teraz się okazało, że dały się bez problemów zainstalować pod PlayOnLinux

W sumie całość, włącznie z kabelkami kosztowała 350 EUR, czyli jakąś jedną trzecią tego co poszłoby na notebooka. Chodzi super, jak wcześniej emulator Androida startował ponad cztery minuty, to teraz poniżej 30 sekund. Instalacja drivera do nVidii była nietrywialna i nie dla początkujących linuksiarzy, ale nie jestem początkującym linuksiarzem. Za to teraz emulowane urządzenie Androidowe chodzi w takim samym tempie jak prawdziwe (o ile nie szybciej).

Ale oczywiście nie obyło się bez spotkań z programistycznymi twitami. Na przykład: klawiatura bezprzewodowa chodzi z baterii i oczywiście nie ma LEDów do capslocka i numlocka. Żeby wiedzieć jaki jest ich stan, trzeba mieć jakiś kawałek programu. No i na Linuxa w zasadzie jest taki, sztuk jeden. Obsługuje on wszystkie trzy klawisze, ale miejsce do pokazywania jest tylko jedno. A przy każdej zmianie pokazuje się na ekranie notyfikacja. To jest tak głupie i niepraktyczne, że nie wiem nawet jak to skomentować. Poradziłem sobie instalując taki kombajn, co na bieżąco wykresy wszelakie pokazuje (zajętość pamięci, obciążenie procesora, temperatury, swap, transfery dysku, ...)  i jeszcze krawaty wiąże i usuwa ciążę, ale jak powyłączać wszystko inne, to można go mieć za wskaźnik tych locków. Też głupota, ale co zrobić.

Następny problem jest, że mój komputer stoi teraz prawie za mną i żeby zobaczyć diodę od HDD to muszę się obrócić. Programu do pokazywania symulacji takiego LED-a na ekranie nie ma. W zastępstwie można najwyżej pokazywać wykresiki transferu do dysku, robi to również ten kombajn, co pokazuje locki. Dobre chociaż to.

A teraz Android Studio, to w zasadzie jeden wielki twit.  W sieci spotkałem wypowiedzi, że jest lepsze od Eclipsa, bo to co w Eclipsie szło ciężko, to tu idzie łatwo. Sorry, ale nie mogę tego potwierdzić. Zgoda, ono ma dobre chęci i chce na każdym kroku ułatwić, podpowiedzieć i zapobiec błędom. Tyle że skutek jest taki, że żeby zrobić całkiem podstawowe rzeczy to trzeba program wykiwać robiąc je na boku, w czym innym. Na przykład:

  • Jak chcieć założyć testy, czy to jUnitowe, czy na urządzeniu, trzeba umieścić je w bardzo konkretnych katalogach. I tych katalogów NIE DA się utworzyć w GUI Android Studio! Trzeba zrobić to normalnie, na dysku, czy to w CLI, czy w jakimś file managerze, ale nie w Android Studio!
  • Jeszcze gorzej: Nawet jak te katalogi utworzyć, to ich w Android Studio nie widać, dopóki nie ma w nich jakiegoś pliku! Czyli trzeba utworzyć tam jakiś plik, nawet pusty, dowolnym narzędziem, dopiero potem da się cokolwiek z tymi katalogami zrobić! To już nie Twit of the Year, to Twit of the Century!
  • Menu kontekstowe pozwala na utworzenie najmniej pięćdziesięciu różnych klas obiektów, ale nie tych, które są potrzebne - na przykład absolutnie podstawowe pliki build.gradle. I znowu trzeba je zakładać czymś innym.
  • AS reaguje standardowo tylko na klawisze kursora, a nie na te z bloku numerycznego. Można zamienić na te z bloku numerycznego (a ja zaczynałem od klawiatury AT i umiem tylko na tych), ale wtedy klawisze kursorowe są ignorowane. No mać, to aż takie trudne, żeby reagować na dwa różne?

Muszę przyznać, że chociaż import projektów Androidowych z Eclipsa działa dobrze. Ale dalej jest gorzej:

Chciałem przećwiczyć cały proces aż do Jenkinsa i ślicznych wykresów tendencji. Więc do zaimportowanego z Eclipse starego przykładu dorobiłem lokalne testy jUnitowe, takie byle by jeden był OK, a drugi failed, zacheckinowałem do Gita, puściłem build na Jenkinsie. No i wszystko cacy, tyle że protokołu z testów nie było. No i zaczęło się grzebanie. Okazuje się, że to dłuższa historia, pełna twitów. Sam muszę sobie to trochę uporządkować.

  • Jeżeli dobrze zrozumiałem, to Google przez długi czas uważało, że zautomatyzowane testy mają sens tylko na urządzeniu albo w emulacji. Jakiekolwiek unit testy na pececie były be  (facepalm!)
  • Ponieważ ludzie tak nie uważali (szacun), powstał niezależny framework do testowania na pececie zwany Robolectric.
  • Niedawno Google trochę pomroczność przeszła i zaakceptowali i wprowadzili do struktury projektu lokalne testy jUnitowe. Niestety, jednocześnie coś się pozmieniało i z Robolektrikiem są jakieś problemy (chyba na podobnej zasadzie jak z Eclipsem, to pewnie wykańczanie konkurencji).
  • Problem z raportami z jUnita polega na tym, że w Eclipsie raporty robił specjalny task Anta, którego nie zrobiono w Gradlu dla Androida.
  • W Gradlu można by ustawić generację raportu jUnita, ale tylko dla kawałka czysto jUnitowego. Ustawienie jUnit gryzie się z ustawieniem Android i nie da się ich użyć jednocześnie.
  • Podejrzewam, że dałoby się zrobić osobny build.gradle w katalogu testów lokalnych i tam ustawić że to jUnit, ale jeszcze jestem słaby w Gradlu i będę musiał trochę popróbować.

Przyznacie chyba, że testy automatyczne nie pozostawiające po sobie protokołu są jakieś takie nie ten tego...

 Ale teraz wyśmieję każdego, kto powie że Google zatrudnia świetnych programistów.

-----------------------------------------------------------------------------------------------------------------------

Dotyczy: ,

Kategorie:Programowanie

17 komentarzy

Twit Programmers of the Year (4)

W pracy kończy mi się walka z programistycznymi twitami, przynajmniej w tym projekcie. Startuje powoli następny, oczywiście znowu o stopień trudniejszy (teraz będzie dużo wariantów z różną funkcjonalnością i procesor z symmetric multicore). No ale trzeba oszczędzać i pewnie mnie przy nim nie będzie, przynajmniej na początku (pewnie zawołają mnie dopiero jak się zacznie walić i palić) . Zobaczymy gdzie teraz trafię.
Ale za to w domu zabrałem się za eksperymenty z Androidem. Na początek spróbowałem działać z sensorami i też od razu natknąłem się na mnóstwo twitów:

  • Na początek zrootowałem swojego tableta (Acer Iconia A700). Nawet łatwo poszło.
  • Wgrałem mu custom recovery, całkiem fajnie działa
  • Wgrałem też mu custom system (CyanogenMod). Tu był problem - jest dużo programów instalujących ten system na zrootowanym urządzeniu, tyle że całkiem niedawno ten projekt przemianował się (na LineageOS) i w ogóle coś się pozmieniało i te starsze wersje zginęły z sieci. Żaden z instalatorów nie działa. Na szczęście znalazłem gdzieś w sieci odpowiedni kompilat (samemu skompilować jeszcze mi się nie udało) i wgrałem go na tableta. I to jest dobre, oryginalny Android ślimaczył się już straszliwie, a ten chodzi całkiem przyjemnie, można było wywalić cały bloatware i ma to parę funkcji więcej.
  • Pisałem wcześniej o problemach z emulatorem Androida, dałem sobie z nim spokój. USB debugging chodzi bardzo dobrze. Potem kupię sobie parę używanych urządzeń z różnymi rozdzielczościami.
  • USB debugging chodzi, tyle że nie na moim telewizorze. Philips ma politykę, że ich telewizory są nierootowalne, soft można instalować tylko z Google Play, a USB debugging mimo że można odblokować, to nie chodzi (tu jeszcze potencjalny problem połączenia USB-A z USB-A). Chociaż ostatnio trochę odpuścili, po niedawnym updacie opcja instalacji z innych źródeł się pojawiła, i co nieco narzędzi poinstalowałem. Debugging ma móc chodzić przez Ethernet, podobno komuś się z tym modelem telewizora udało, mi jeszcze nie. W ogóle to motywacja Philipsa jest "Bo jak zbrickujesz sobie telewizor za 2500 EUR to będziesz płakał" - tyle że mój telewizor był tańszy od mojej komórki i niewiele droższy od mojego tableta. Uprzedzając pytanie: Nie, nie mam komórki za 2500+.
  • No to zacząłem od tableta. Na początek postanowiłem zapoznać się z obsługą sensorów. Jest do tego mnóstwo przykładowego kodu w sieci.
  • Analiza kodu i zależności fizycznych pokazała, dlaczego niemal wszystkie (o ile nie wszystkie) programy robiące za kompas są do niczego. Przyczyny są dość skomplikowane, ale do pojęcia. Objaśnię je, bo to ciekawe:
    • Niemal każda komórka ma akcelerometr, którym można ustalić kierunek "w dół" (to tam, gdzie statycznie mamy przyspieszenie 1g), żyroskop do obrotów i magnetometr, pokazujący kierunek na magnetyczną północ
    • GPS podaje geolokalizację urządzenia, ale nie w którą stronę jest obrócone, więc GPS się do kompasowania nie nadaje.
    • Magnetometr podaje kierunek wprost (przez Ziemię) do bieguna magnetycznego.  Znaczy to jest (jak u nas) jakieś 40º do poziomu.
    • Duża część programów na kompas bierze po prostu składową magnetyczną w płaszczyźnie urządzenia, relatywnie do jego osi Y. Ale jak trzymać urządzenie w ręku i pochylić je trochę do siebie, to ta płaszczyzna ustawia się paskudnie blisko prostopadłości do żądanego wektora, całą dokładność szlag gwałtowny trafia i kompas kręci się na chybił-trafił.
    • Sytuację może poprawić użycie kombinacji  sygnałów z akcelerometru i magnetometru.
    • W zasadzie coś takiego jest dostępne jako wirtualny sensor pozycji urządzenia, tyle ta funkcja zrobiła się deprecated lata temu (od v2.2.x, około 2010).
    • Ponieważ nowe rozwiązanie wymaga jednego calla więcej i trochę zrozumienia (słowo kluczowe: quaternion), prawie nikt nie jest w stanie tego pojąć i prawie wszyscy robią to po staremu.
    • Nawet po nowemu, to pokazuje kierunek na północ magnetyczną, a nie na "prawdziwą" północ.
    • Znając geolokalizację (z GPS-u) można od systemu dostać wartość poprawki żeby pokazać prawdziwą północ, ale nie znalazłem jeszcze ani jednego przykładu żeby ktoś to zrobił. Ja też jeszcze nie załapałem w którym momencie trzeba wykonać jaką operację na quaternionach, ale dojdę do tego.
    • Nawet jak zrobić to dobrze, pokazywany kierunek będzie zakłócany przez zewnętrzne pola magnetyczne.
    • Generalnie wszystkie te programy są zrobione maksymalnie prosto - obracają obrazek igły kompasu zależnie od danych z sensora. Nie będzie to sensownie działać (nawet porządnie zrobione) jak nie trzymać komórki poziomo. Mam pomysł znacznie lepszego interfejsu użytkownika. I jeszcze parę innych pomysłów na aplikacje związane z kompasem.
    • Dlaczego cała ta kombinacja składowych do orientowania się na prawdziwą północ nie jest dostępna jako proste API?
  • Jeszcze generalna uwaga co do API Androida: W całym tym API nie są w ogóle deklarowane wyjątki jakie funkcje mogą rzucać (deklaracja throws). Jak dla mnie to jest zupełnie podstawowy brak w designie - nieprzemyślana obsługa błędów.

Ładnie się zaczyna. Ciekawe jak będzie dalej.

-----------------------------------------------------------------------------------------------------------------------

Dotyczy: , ,

Kategorie:Pomyślmy, Programowanie

24 komentarze