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

Warto zobaczyć: Musée Nissim de Camondo, Paryż

Notka mi się mocno przeleżała, większość jej napisałem prawie 5 lat temu (sic!), zdjęcia i ceny są z 2016. Ale chciałem się podzielić.

Muzeum Nissim de Camondo jest nie za bardzo znane, trafiliśmy tam tylko dlatego, że żona obejrzała w telewizji film dokumentalny o malarce Élisabeth Vigée-Lebrun i chciała zobaczyć jakieś jej obrazy na żywo. Nie chcieliśmy iść jeszcze raz do Luwru, ale znaleźliśmy że w Camondo są dwa.

Obraz Élisabeth Vigée-Lebrun

Obraz Élisabeth Vigée-Lebrun

Wybraliśmy się więc. No i muzeum było bardzo interesujące, ale zupełnie inne niż się spodziewałem.

Muzeum Nissim de Camondo

Muzeum Nissim de Camondo

Najpierw historia, jak to zwykle w tych sferach smutna. Rodzina Camondo pochodziła z hiszpańskich Żydów. W 1492 w Hiszpanii zarządzono, że miejscowi Żydzi muszą się przekonwertować na katolicyzm, albo wyemigrować. Rodzina wyemigrowała więc do Wenecji. Tam mieszkali do 1798, a potem przenieśli się do Istambułu i zajęli się bankowością. Szło im naprawdę dobrze i już w 1802 założyli własny bank. Wkrótce zrobili się obrzydliwie bogaci i obsługiwali bankowo nawet Imperium Osmańskie jako partner preferowany. W 1869 przenieśli się z pieniędzmi i biznesem do Paryża. Tam też szło im świetnie. W 1873 kupili oni sobie pałacyk położony w bardzo drogiej lokacji w Paryżu. I w tym miejscu mieści się dziś muzeum, ale to wcale nie koniec tej historii. W 1910 Moïse de Camondo, jedyny potomek rodziny odziedziczył wszystko. Był tak obrzydliwie bogaty, że już wcale nie musiał zajmować się biznesem, tylko mógł wydawać pieniądze prawie bez ograniczeń. Zaczął od zburzenia pałacyku i kazał zbudować sobie nowoczesny dom, ten który teraz możemy zwiedzać. Dom miał przede wszystkim mieścić jego starannie wybraną kolekcję sztuki, a oprócz tego odbywać w nim się miały imprezy.

Moïse de Camondo miał dwoje dzieci: syna Nissima de Camondo i córkę Béatrice de Camondo. Z żoną się rozwiódł dość szybko, bo jego małżeństwo było raczej z umowy handlowej, niż z miłości. Potem wybuchła WWI i Nissim poszedł do wojska. Zaczynał od piechoty, a  potem poszedł do lotnictwa. No i nie dożył końca wojny - w 1917 zginął w walce powietrznej. Ojciec, Moïse, już się z tego nie podniósł. Praktycznie nie wychodził ze swojego wspaniałego domu i nie przyjmował gości. W jego supernowoczesnej kuchni kucharze przygotowywali mu posiłki, które zjadał w kącie najmniejszego pomieszczenia w domu. Siedział stale w jednym tylko pokoju. Przed śmiercią zapisał swój dom ze wszystkimi zgromadzonymi dziełami sztuki państwu francuskiemu, a po jego śmierci, w 1935 zrobiono tam muzeum imienia jego syna.

To jeszcze nie koniec smutnych historii - była jeszcze jego córka. Córka miała też córkę i syna. Była baaardzo bogata, dobrze ustawiona i skonwertowana na katolicyzm, więc po zajęciu Francji przez Niemców myślała, że jej żydowskie pochodzenie to przy tym drobiazg. Nawet nie przeniosła się do strefy Vichy, co jej radzono. Niestety myliła się. Wraz z dziećmi zginęła w 1944 w Oświęcimiu.

No ale jak już wiadomo z notki o Oplach, wielkie pieniądze szczęścia nie dają. Nic nowego, zajmijmy się więc muzeum. To muzeum pokazuje życie codzienne obrzydliwego bogacza sprzed stu lat. Interesujące jest, co się od tego czasu zmieniło - co jest nadal zastrzeżone dla bogaczy, a co stało się dostępne dla klas niższych.

Pierwsza obserwacja nie jest specjalnie zaskakująca - wielkie powierzchnie w dobrej lokalizacji to nadal coś tylko dla bogaczy. Dalej jest ciekawiej:

Łazienka bogacza jest wielka, nieźle wyposażona nawet według współczesnych standardów (chociaż coś w rodzaju umywalki do mycia stóp nie występuje współcześnie, przynajmniej w łazience w domu), ale dziś zaskakuje surowym wystrojem. Wszystko białe z niebieskimi akcentami, raczej mat. Grzejnik robiący za wieszak na ręczniki całkiem jak współczesny nam. W sumie dziś nawet plebs może mieć lepszą łazienkę (a gorszą głównie pod względem powierzchni).

Muzeum Nissim de Camondo - łazienka

Muzeum Nissim de Camondo - łazienka

Bogacz miał w domu windę. Nie zamierzam porównywać jej z windą w bloku, ale widziałem już domy klasy średniej, w których winda była, i było to w Polsce

Muzeum Nissim de Camondo - winda

Muzeum Nissim de Camondo - winda

Kuchnia bogacza była w standardach profesjonalnych i mogła obsłużyc sporą imprezę, na moje (amatorskie) oko dałoby się w niej pracować również dziś. Oczywiście bogacz nie gotował sam, więc porównanie z kuchnią w mieszkaniu lub domku nie ma sensu.

Muzeum Nissim de Camondo - kuchnia

Muzeum Nissim de Camondo - kuchnia

Wystrój pokojów nie jest osiągalny dla współczesnego, nie obrzydliwie bogatego człowieka, a nawet daleko nie wszyscy dzisiejsi obrzydliwie bogaci potrafiliby dobrać przedmioty tak pasujące stylistycznie. No ale Moïse de Camondo nie zajmował się praktycznie niczym innym, niż tylko szukaniem pasujących przedmiotów do swojego domu.

Biblioteka może i ładnie zrobiona, ale w niej głównie pisma i książki (i katalogi aukcji) na temat obrazów i innych przedmiotów do jego domu.

Muzeum Nissim de Camondo - biblioteka

Muzeum Nissim de Camondo - biblioteka

Uważam, że pan Camondo zmarnował sobie życie  na rzeczy może i ładne i cenne, ale w szerszym kontekście puste i bezwartościowe. Wartościowa okazała się tylko rodzina, ale dopiero po tym jak i to spieprzył.

Ale muzeum jest interesujące i warto zobaczyć.

Adres:

Musée Nissim de Camondo

63 Rue de Monceau, 75008 Paris

Otwarte:

  • od środy do niedzieli, 10-17:30
  • W poniedziałki i wtorki zamknięte

Wstęp:

  • Dorośli 9 EUR
  • Osoby poniżej 26 lat za darmo

Audioguide w cenie biletu

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

Dotyczy: , , ,

Kategorie:Warto zobaczyć

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

Blog: The Resurrection

Trzy lata minęły, i po trzech latach blog zmartwychwstał. Co się działo? To dłuższa historia. Na razie opowiem, co się stało od strony technicznej.

WordPressa zainstalowałem w samym końcu roku 2012 i była to wersja 3.5. Potem, w początku maja przeszedłem na multisite i do tego zrobiłem nową instalację wersji 3.5.1. Dalej zdarzył się update do 4.0 i wszystko się posypało - tam została zmieniona struktura katalogów w których trzymane są obrazki. Ponieważ obrazków miałem dużo, spatchowałem jeden plik z core WordPressa, żeby nie musieć przerabiać swojej biblioteki obrazków i wszystkich linków do nich.

Trudno się jednak dziwić, że nabrałem niejakiej nieufności co do updatów. Potem przyszło 4.0.1, tam też zrobiłem patcha, ale w innym miejscu. Było z tym niestety sporo roboty, więc do następnych wersji podchodziłem jak pies do jeża - czyli omijałem je z daleka. Potem zająłem się własnym projektem i blog poszedł w odstawkę.

A po pewnym czasie provider powiedział, że ta wersja PHP na której działałem (5.6 jeżeli dobrze pamiętam) wypada, a jeżeli chcę ją dalej mieć, to miesięcznie ileśtam się należy. Co było zrobić - przeszedłem na 7.x.

Tyle że w tym momencie nie dało się już do bloga zalogować, a ja naprawdę nie miałem czasu się tym zająć. I tak to szło, już od jakichś dwóch lat.

No ale ostatnio dojrzałem powoli, żeby coś z tym zrobić. Przerzuciłem pliki bloga i dump bazy danych na mój serwer w domu, przekierowałem dostępy w DNS-ie na niego, i wyszło że w domu mam ten sam problem co na hostingu. A zreprodukowanie błędu to już połowa sukcesu.

Porobiłem trochę eksperymentów z różnymi wersjami WordPressa i PHP, i blog ruszył u mnie lokalnie. Zintegrowałem aktualnego WordPressa 5.8 i przerzuciłem go znowu na hosting. Tam nie ruszyło bezproblemowo, ale zidentyfikowałem plugin który robił problemy, i poszło.

Teraz podsumowanie:

  • Okazało się, że ten mój drugi patch WordPressa był super - bo nie jest w pliku core, tylko w hooku który jest obsługiwany również przez następne wersje. Mój lęk przed update okazał się całkowicie nieuzasadniony.
  • Wszystko co działa na hostingu wymaga nieustannej uwagi.
  • Przerwa w blogowaniu była mi potrzebna - o tym jeszcze napiszę.

Czyli: Blog wróci.

 

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

Dotyczy:

Kategorie:Organizacyjne

7 komentarzy

2001 skończył sie już dawno, gdzie Odyseja Kosmiczna? (czyli: Warto zobaczyć – Muzeum Filmu, Frankfurt)

(Sorry, ja wiem, tekst słaby, zdjęcia bez tagów i opisów, ale nie jestem akurat w nastroju do pisania)

W sobotę była u nas Noc Muzeów, jak nigdy nie korzystaliśmy z tego, tak tym razem postanowiliśmy się wybrać. Podstawowym argumentem były wystawy okresowe, i to trzy na raz: Rubens w Städlu, Jil Sander w Muzeum Stuki Użytkowej (to głównie żona), do trzeciej dojdę. A oprócz tego niedawno zbudowali u nas na nowo Muzeum Historyczne, jeszcze nie byliśmy. No i bilet na Noc Muzeów kosztuje 14 euro na dorosłego a 29 na rodzinę, każde odwiedzone z osobna wyszłoby znacznie drożej, więc czemu nie.

No i Rubens mnie nie za bardzo rusza, Jil Sander wcale, co do Muzeum Historycznego mam mieszane uczucia (ale może musimy pójść na spokojnie i nie koło północy). Ale trzecia wystawa okresowa była naprawdę dobra - w Muzeum Filmu było o "2001: Space Odyssey".

Muzeum Filmu jest samo w sobie całkiem niezłe i polecam. Jest tam też kino, w którym pokazują filmy stare i wartościowe, niekoniecznie blockbustery. No i robią tam ciekawe wystawy okresowe. Na przykład w zeszłym roku był Aardman. No i teraz "2001: Space Odyssey".

Na wystawie masa ciekawostek. Film każdy widział, więc nie ma co pisać, trzeba zobaczyć chociaż zdjęcia.

Modele:

DSCF3801_small

Orion-III

DSCF3808_small

Moonbus

DSCF3817_small

EVA Pod

Skafandry i kostiumy z filmu, większość oryginały:

DSCF3797_small

Kostium małpoluda (oryginał)

DSCF3792_small

Skafander księżycowy (oryginał)

DSCF3820_small

Skafander (kopia)

Gadżety:

DSCF3829_small

HAL 9000 (kopia)

DSCF3795_small

Zegarek

Wystawa jest jeszcze do 23 września.

Adres:

Deutsches Filmmuseum
Schaumainkai 41
60596 Frankfurt am Main

Otwarte:

  • Wtorki: 10 – 18
  • Środy: 10 – 20
  • Czwartki-niedziele: 10 – 18
  • W poniedziałki nieczynne

Wstęp:

Ekspozycja stała: Normalny: 6,00€, ulgowy: 3,00€, dzieci poniżej 6 lat za darmo

Wystawa okresowa: Normalny 10€, ulgowy 8€ (czyli warto było pójść na bilet rodzinny Noc Muzeów)

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

Dotyczy: , , ,

Kategorie:Warto zobaczyć

4 komentarze

Jajako inżynier o katastrofie w Smoleńsku (7)

Jak można było przewidzieć, Smoleńsk to neverending story. Ściągnąłem sobie "raport techniczny" i twarz mnie boli od nieustannego facepalmowania ręką, oburącz, stopą, obunóż i wszystkimi mackami naraz. Uwaga, mogą padać słowa powszechnie uważane za obraźliwe.

Ten "raport" jest paskudnie niebezpieczny dla nieprzygotowanych fachowo. Na pierwszy rzut oka wygląda poważnie i profesjonalnie, żeby zobaczyć gdzie kłamie i/lub manipuluje trzeba już odrobinę wiedzy.

Znaczy jedną rzecz można zauważyć również po prostu krytycznie myśląc: "Raport" wcale nie ukrywa, że jest pod tezę. Tam nie ma słowa o rozważaniu przyczyn katastrofy zamachu innych niż wybuch. Już we wstępie padają wszystkie tezy, potem jest tylko cherrypicking "faktów" mających ją potwierdzić. A nad tymi "faktami", a zwłaszcza podstawowymi błędami metodologicznymi i poznawczymi, oraz brakami wiedzy na poziomie szkoły średniej u autorów się teraz poznęcam:

  • "Na wysokości pozwalającej na bezpieczne odejście 1P wydał komendę o odejściu na drugi krąg potwierdzoną przez drugiego pilota (2P)." (str.5) Zajrzałem do stenogramu: "Odchodzimy" padło w momencie jak odczytywana wysokość zaczęła bardzo szybko spadać, chwilę wcześniej padło 60. Przypominam, że odczytywany był wysokościomierz radarowy, wysokość nad pasem wynosiła już tylko ze 40 metrów, a samolot opadał z prędkością kilku metrów na sekundę. (Patrz wykres w poprzedniej notce na ten temat) Jak to ma być wysokość bezpieczna, to komuś urwało od rzeczywistości.
  • "Jak-40 oraz Ił-76 i Tu-154M sprowadzane były za pomocą sprawnej stacji radiolokacyjnej precyzyjnego podejścia i lotniskowych urządzeń radiotechnicznych. Źródło: Prezentacja Podkomisji – 10 kwiecień 2017 r." (str. 13). Sorry (jeszcze jestem uprzejmy), ale własna prezentacja nie jest źródłem, na studiach powinni tego uczyć. Dla mnie to jest przyznanie wprost "o jakiejkolwiek metodologii nie mamy pojęcia".
  • "Załoga Tu-154M wykonywała wszystkie procedury podejścia do lotniska prawidłowo." (str.13). Taa, zwłaszcza poprawnie zareagowała na "Warunków do lądowania niet". Że nie wspomnę o zejściu poniżej minimów na które mieli uprawnienia. I o tym że te uprawnienia i tak były oszukane. I że w automacie schodzili na lotnisko bez ILS-u. I czytali niewłaściwy wysokościomierz. itd. itd. Ale to PiSowcy pisali, dla nich takie pierdoły są bez znaczenia.
  • "Kierownik Lotów (KL) nie poinformował załogi Tu-154M o zmieniających się warunkach atmosferycznych" (str.13). No bo "Nie ma warunków do lądowania" to znaczyło "Piwo jeszcze nie schłodzone i grilla nie rozpaliliśmy, ale pogoda piękna".
  • Cała dyskusja, co to kontrola lotów nie zrobiła źle (str.14). - Przecież to bezprzedmiotowe. Na cholerę sprowadzać dokładnie (i jak, skoro nic nie widać), skoro nie było zgody na lądowanie, a widoczność poniżej wszelkich minimów? (co ten "raport" skrupulatnie pomija). Komu normalnemu strzeliłoby do łba, że oni tam przylecieli na rozszerzone samobójstwo?
  • "Oderwana końcówka odejmowanej części lewego skrzydła posiada widoczne charakterystyczne cechy eksplozji (loki powybuchowe). Ten fragment skrzydła stanowi bezsporny dowód zniszczenia w wyniku eksplozji." (str.15, rys.2). Na zdjęciu mamy zniszczony fragment skrzydła, w którym blacha od strony krawędzi natarcia jest pozwijana na zewnątrz w spiralki, tak z półtora obrotu. Dowód że to była eksplozja jest eksperymentalny - na stronie 27 rys. 23 oni odpalili ładunek wewnątrz  podobnego skrzydła, i według nich efekt wygląda tak samo. Dla mnie wcale nie wygląda tak samo - blacha w eksperymencie też się zwinęła, ale nawet nie o 3/4 obrotu. To z grubsza zgodnie z moimi oczekiwaniami, ale jakoś mam poważny problem z wymyśleniem mechanizmu, żeby wybuchowo zwinąć ją o następne 3/4 obrotu. Przynajmniej tylko jednym wybuchem. Ja wiem, że "cała seria małych wybuchów" to była jedna z fabuł Głównego Zamachowca, a mordy zdradzieckie całymi miesiącami kombinowały jak ułożyć i zsynchronizować ładunki żeby blacha była ładnie pozwijana i fajnie wyglądała na zdjęciach, ale jednak nie. Nawet w filmie z Bondem by mi tytanowe  haki do zawieszania niewiary pękły przy czymś takim.
  • "Eksperymenty przeprowadzone przez Podkomisję w 2016 r. na wykonanym w skali 1:1 elemencie o podobnym kształcie i ciężarze do jednego z wiszących odłamków, wykazały, że potrzebna jest odległość co najmniej 100 m i wysokość nie mniejsza niż 26 m, aby taki odłamek wytracił prędkość i osiadł na gałęzi" (str.16). Nie bardzo zrozumiałem, na co to w intencji "ekspertów" ma być dowód, chyba na to, że ktoś kawałki blachy powiesił na drzewie. Tylko że jak ja się (amatorsko) znam na rzucaniu przedmiotami w atmosferze azotowo-tlenowej (z drobnymi domieszkami innych gazów) przy ciśnieniu rzędu 0.1 MPa, to drobne różnice w kształcie i wygięciu nieregularnego kawałka blachy, i drobne różnice w jego ustawieniu i rotacji przy rzucie dają olbrzymie różnice w jego zachowaniu. Próby z jednym tylko kawałkiem to sobie możecie wsadzić w dowolny otwór cielesny, one mówią wyłącznie o zachowaniu się tego jednego kawałka. Tu trzeba analizy statystycznej, a za robienie statystyki z jednej próbki powinno się wywalać ze studiów.
  • "Niektóre elementy konstrukcji wewnętrznej odejmowanej części skrzydła, które wg raportów MAK oraz Millera miały mieć kontakt z (bb), są wygięte na zewnątrz konstrukcji; na płaszczyźnie wierzchniej ku górze, na płaszczyźnie spodniej ku dołowi, a przy krawędzi natarcia ku przodowi, co świadczy o działaniu wysokiego ciśnienia wewnętrznego." (str.17, rys.7) (przypis tłumacza: (bb) to ta pancerna brzoza, czyli słowo-tabu). Generalnie na następnych stronach też, jak kawałek blachy wygięty jest na zewnątrz, to ma to być dowód na wybuch w środku. Tu mi się ulało. Słuchaj no jeden z drugim: jak masz kawał blachy na żebrach i podłużnicach i walniesz go poprzecznie, to w którą stronę ta blacha ma się wygiąć? Do środka? Przecież tam żebra i podłużnice przeszkadzają! A nawet jak nie ma żeber - zwiń sobie rurkę z kartonu i spłaszcz ją palcami (nie, puszka po piwie nie jest dobrym modelem, nie ma żeber i jest trochę za mało sztywna). I co, nie idzie na zewnątrz po bokach? I czy to znaczy, że odbywa się w niej cichy wybuch?  Takie obserwacje to się robi w przedszkolu, potem już powinno się wiedzieć.
  • Na str.27 autorzy dowodzą, że utrata 6,5 m jednego skrzydła to nie problem, można wyrównać lot i wylądować bezpiecznie, zmierzyli to w tunelu aerodynamicznym, a nawet się zdarzyło naprawdę  w locie PanAm 843. Komentarz: Tak, tak, w locie wznoszącym na 800 stopach to całkiem to samo co w przeciągniętym samolocie zawadzającym już o drzewa. Polski pilot spoko loko nawet na drzwiach od stodoły by z tego wyszedł (tylko potrzymaj mu piwo), ale (jak zwykle) Ruski przeszkadzali.
  • "Według tych danych i zapisów ATM QAR, uszkodzony samolot w konfiguracji do lądowania po kontakcie z brzozą w ciągu jednej sekundy musiałby się wznieść ponad 35 m do wysokości barycznej zapisanej w TAWS38, co prawie czterokrotnie przewyższa możliwości wznoszenia w pełni sprawnego samolotu Tu-154M." (str.29) Znaczy ma być niemożliwe i ktoś tu kłamie, nie powiem kto, ale jak palnę w ten rudy pysk...   No k... mać, według tej logiki szybowiec nie jest w stanie zrobić pętli, bo takich szybkich prądów wznoszących nie ma. Autor tezy do szkoły średniej odmaszerować, porobić dużą porcję zadań z rzutów pionowych, poziomych i ukośnych, jak już zrozumie zagadnienie i będą mu wychodzić poprawne wyniki, to wrócić i zrobić od nowa analizę. (EDIT: Pytanie zaliczeniowe dla autora tezy: TUTAJ video z kabiny szybowca robiącego trzy pętle pod rząd, wariometr to ten górny zegar po prawej. Proszę wyjaśnić jak to możliwe, że mimo braku silnika pokazuje on wysokie wartości dodatnie. Czas start.)
  • "Zdjęcie głównego pola szczątków ukazuje charakterystyczne położenie drzew w jego początkowej części - od strony północnej do przodu zgodnie z torem lotu samolotu, a od strony południowej do tyłu. Fakt ten wskazuje na oddziaływanie fali uderzeniowej."  (str.35). A może by tak rozważyć hipotezę, że samolot miał z tyłu przymocowane takie duże rury, coś jak komunistyczne odkurzacze Alfa K2, i całkiem jak te odkurzacze dmuchał nimi do tyłu, tylko trochę mocniej (ciekawe po co, co nie?). Do tego odkurzacza, w otwór którym powietrze wylatywało wkładało się taką wygiętą do góry rurkę, żeby wszystkiego nie zdmuchiwał. No i w tym samolocie komuś nie chciało się tych wygiętych rurek zamontować, i może ten dmuch aż drzewa poprzewracał?
  • "Kadłub znajdujący się między centropłatem a ogonem został znaleziony w pozycji odwróconej spodem do góry, z burtami wywiniętymi na zewnątrz. Takie zjawisko można zaobserwować tylko wówczas, jeśli na kadłub działa silne ciśnienie wewnętrzne, kiedy znajduje się on w powietrzu." (str.42). Może jednak zrobicie tą rurkę z kartonu i ściśniecie ją palcami? Możecie się sporo w ten sposób nauczyć.
  • "Na 175 częściach foteli eksperci prokuratury polskiej, przy pomocy specjalistycznych urządzeń w 2012 r., ujawnili liczne ślady materiałów wybuchowych." (str.43). To już parę lat temu obśmiewał chemik WO, więc ja nie muszę (bo śmiech śmiechem, ale powoli robi mi się niedobrze).
  • Na stronie 47 jest o tym, jak liczyli w symulacji destrukcję samolotu spadającego na twardy grunt i wyszło im całkiem co innego niż w rzeczywistości. I oczywiście ma to być dowód na to, że rzeczywistość się nie zgadza. No to już jest bardzo gruby kaliber nieogaru, ja bym za takie stwierdzenia bezpardonowo odbierał tytuły i uprawnienia zawodowe (if any). Wyjaśnienie dla mniej biegłych (EDIT: rozwinięte 15.04.2018): Model to tylko bardzo grube przybliżenie i działa nieźle tylko w normalnym zakresie pracy modelowanych elementów. Jak przekraczamy zakres odkształceń sprężystych, to nie bez znaczenia robią się rzeczywiste parametry każdego elementu, a one zawsze mają rozrzuty. Analiza destrukcji konstrukcji idzie jeszcze jakoś na przykład dla konstrukcji budowlanych, gdzie pracujemy z belkami, płytami i prętami, i jeżeli któryś z elementów będzie wyraźnie niedowymiarowany, to w ten sposób dojdziemy które miejsce strzeli pierwsze. A potem rozkład obciążeń się zmieni, znowu przeliczymy który teraz jest najbardziej obciążony i kiedy strzeli itd. To jest niby dość proste i w dzisiejszych czasach nawet enginy fizyki do gierek dają w miarę realistyczne animacje pracując na telefonie. Problem polega na tym, że jeżeli mamy kilka elementów którym wychodzi to samo obciążenie, to nie będziemy mogli powiedzieć który padnie pierwszy, bo to będzie zależeć od faktycznych parametrów tych elementów, staranności ich montażu itp., a tego w modelu nie ma. (Czy wspominałem już, że mój ojciec całe życie zawodowe zajmował się obliczaniem konstrukcji budowlanych? Trochę orientacji w temacie skapnęło i mi). Czyli: możemy policzyć sobie typowy przebieg katastrofy, ale niekoniecznie będzie on identyczny z rzeczywistym. I to był ten prostszy wypadek - budynku sprowadzalnego do kratownic, belek i płyt, niestety w samolotach pasażerskich zrezygnowano z konstrukcji kratownicowych gdzieś około Junkersa Ju-52. Potem robiono już konstrukcje skorupowe, i to się liczy jeszcze trudniej, zwłaszcza w zakresie niszczącym. Tu już znaczenie ma każde połączenie blach, każdy otwór na nit, każde wgniecenie od uderzenia w drzewo, zmiany zmęczeniowe materiału, struktura gruntu (oni liczyli dla twardego podłoża, to musi mocno zmienić przebieg destrukcji, wbrew ich gołosłownym zapewnieniom) itd. Czyli znowu: Jakieś tam idee dotyczące ogólnego przebiegu destrukcji można na podstawie takiej symulacji mieć, ale jak ktoś oczekuje że będzie dokładnie tak jak zamodelowane, to mu peron odjechał a program symulacyjny rzucił się na mózg i postrzeganie rzeczywistości.
  • "5. Gdyby działało tylko zderzenie z gruntem, odpadające fragmenty powinny być w jednym wydłużonym pasmie. Nie ma możliwości, by fragmenty były odrzucone kilkadziesiąt metrów w bok." (str.48). To na pewno Binienda, to jego symulacja. Debil. Chociaż nie, mam lepsze wyjaśnienie: Drogi przybyszu z Kosmosu, domyślam się, że niebo w twoim świecie jest czarne - idealnie sferyczne elementy poruszające się w próżni z pewnością leżałyby w jednym, wydłużonym paśmie. Ale my, tutaj na Ziemi, mamy taki funny thing called "atmosphere". Jak nieregularny kawałek blachy szybko leci w tej tzw. "atmosferze", to działają na niego siły zwane "aerodynamicznymi". Te siły są trudno przewidywalne dla nieregularnych, powyginanych kawałków rotujących losowo w dowolnych osiach, stąd lądują one w losowych miejscach, może się nawet zdarzyć, że niektóre polecą w kierunku przeciwnym do pierwotnego.
  • Na stronach 49 do 52 rozwodzą się nad drzwiami, które wbiły się na metr głęboko w grunt. "Symulacje przeprowadzone przez National Institute of Aviation Research (NIAR) w Stanach Zjednoczonych pokazują, że prędkość pionowa lewych drzwi (2L) potrzebna, aby wbić je całkowicie w ziemię i spowodować zniszczenia, jakie na nich zaobserwowano, musiałaby być większa niż V=120m/s. (Oznacza to, że pionowa energia kinetyczna drzwi, kiedy wbiły się w ziemię, była 100 razy większa niż energia, którą posiadałyby drzwi w wyniku jedynie pionowego ruchu samolotu)."  Newton się w grobie przewraca na sugestię, że tylko składowa pionowa prędkości ma znaczenie. (to nie moja manipulacja, dalej jest jeszcze rozwinięte, oni naprawdę uwzględniają tylko składową pionową). Owszem, niemożliwym jest, żeby idealnie sferyczne drzwi, poruszające się w próżni ruchem jednostajnym przy pominięciu składowej poziomej ich prędkości wbiły się tak głęboko w grunt. Ale jak komuś się wydaje, że drzwi o powierzchni rzędu półtora metra kwadrat będą z prędkością 270 km/h lecieć prościutko, to naprawdę należy podejrzewać, że niebo w jego świecie jest czarne, a na Ziemi jest od niedawna.
  • Na stronach 53 i 54 jest o tym "eksperymencie", gdzie wybuchali garaż blaszak z namalowanymi okienkami. To też już było nieźle obśmiane, ale ja serio chciałbym się dowiedzieć, jak duża była ta ich "bomba termobaryczna" i czy dałoby się ją wnieść na pokład w reklamówce (i po co). Myślę, że wątpię.
  • Jednym z dowodów na wybuch ma być "Rozpad samolotu na kilkadziesiąt tysięcy części." (str.56). Serio to ma być dużo? Kilkadziesiąt tysięcy to taki samolot ma samych nitów, jak plastiki pójdą w drzazgi też narobią masę kawałków. 100 foteli które rozpadły się na elementy składowe (str.42) już daje czterysta kawałków.  Ktoś tu nie ogarnia liczb przekraczających zakres liczenia na palcach (a na palcach binarnie można policzyć tylko do 1024. Chociaż jakby tak dołożyć palce od nóg?).

Można tak jeszcze długo, ale powoli mam dosyć. Przejdźmy do wniosków.

Co do autorów, to możliwości są dwie (z wariantami):

1. Oni są naprawdę tacy głupi. No cóż, ubolewać, odebrać tytuły i uprawnienia zawodowe (if any).

2. Oni nie są tacy głupi, tylko pierd..ą głupoty. Tu są dwa warianty:

2.1. Temat i wierzenia im się na mózg rzuciły. To jakby trochę okoliczność łagodząca, i w zasadzie redukuje ten podpunkt do punktu 1.

2.2. Te głupoty są świadome, dla pieniędzy, sławy, władzy itp. Tu nie powinno być pardonu. Odebrać tytuły i uprawnienia zawodowe (if any), ale nie ubolewać, tylko powsadzać. Kwalifikacji jest dość, na przykład oszustwo, niedołożenie należytej staranności (to jak się będą tłumaczyć, że nie wiedzieli), wyłudzenie wynagrodzeń itp., aż do pomocy w przygotowywaniu zamachu stanu.


EDIT: Uzupełnienia:

  • (22.04.2018) TUTAJ sam Binienda pokazuje jak zrobić te "loki wybuchowe" bez wybuchu, i że blacha wygina się na zewnątrz też bez wybuchu, czyli obala tezy z "raportu".
-----------------------------------------------------------------------------------------------------------------------

Dotyczy:

Kategorie:Katastrofa Smoleńsk

47 komentarzy