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

Czas nieutracony (9) – Trochę żelastwa

Przy okazji parę polecanek co do różnego sprzętu biurowego, w który zainwestowałem.

Headset Jabra Evolve2 65

W korpo używają headsetów firmy Jabra, dostałem do użytkowania przewodowy model entry level o nazwie Jabra Evolve 20. (Entry level w tej konfiguracji kosztuje u producenta aż 72 EUR :-)). Przy pandemicznych przenosinach do home office zabrałem go razem  firmowym notebookiem. No i on bardzo fajny jest, chociaż mocno plastikowy, tylko ten kabelek.

Jabra Evolve 20 SE (Źródło: Jabra)

Poszukałem więc, jakie Jabra robi headsety bezprzewodowe. Powiem: drogie są. Flagowy model Jabra Evolve2 85 jest baardzo fajny i ma mnóstwo bajerów, ale kosztuje około 550 EUR. Ostatecznie wybrałem sobie model drugi od góry, Jabra Evolve2 65, u producenta w mojej konfiguracji za 300 EUR (znalazłem za 185). Ale musiałem na niego poczekać, bo w pandemii chwilowo zabrakło.

Jabra Evolve2 65 (Źródło - Jabra)

No i działa to świetnie. Bajery są takie:

  • Headset może być połączony bluetoothem z nawet ośmioma urządzeniami na raz. Mam firmowego notebooka z którego robię meetingi i własne komputery włączone równolegle, słucham muzyki ze swojego komputera linuksowego, jak ktoś dzwoni z firmy przez Skype/Teamsy to muzyka sama się zatrzymuje i headset przełącza się na meeting. Po zakończeniu meetingu wraca muzyka. Ten ficzer może być szczególnie ważny dla freelancerów robiących równolegle projekty dla różnych klientów, gdy od każdego mają osobnego notebooka z VPN. Wtedy jednym headsetem można obskoczyć wszystkie, bez żadnego przełączania wtyczek.
  • Headset ma fajną podstawkę do ładowania, nie trzeba ciągle wtykać wtyczki
  • Akumulator ma wystarczyć na 35 godzin nieprzerwanego działania - chyba intencją był 35 godzinny tydzień pracy i ładowanie przez weekend.
  • W środku są trzy mikrofony, aż trzy żeby tłumić niepożądane dźwięki z zewnątrz (ten najlepszy model ma takich mikrofonów podobno 20!)
  • Podniesienie ramienia mikrofonu w górę powoduje wyciszenie, opuszczenie odblokowuje znowu. To jest dobre.
  • Headset ma czerwone ledy, świecące w trakcie meetingu. Znaczy sygnał dla otoczenia "nie przeszkadzać, jestem zajęty".
  • Ten mój model jest on-ear, ale nie uciska uszu zbyt mocno, jak wiele tanich headsetów. W over-ear, jak model 85, w lecie jest za gorąco.

Jest parę problemów, ale bez winy producenta headsetu:

  • Jeżeli na jednym komputerze chodzi jednocześnie Skype i MS Teams, to czasem się coś im się miesza, na przykład:
    • Podnoszenie/opuszczanie mikrofonu robi mute w headsecie, ale aktywna rozmowa w komputerze nie odzwierciedla tego stanu. Znaczy trzeba ręcznie kliknąć unmute, a rozmówcy cały czas widzą stan unmuted, mimo podniesionego ramienia mikrofonu i faktycznego wyciszenia.
    • Czasem przy meetingu Teamsowym, pracujący równolegle Skype zaczyna co kilkadziesiąt sekund robić głośne DINGGGG! Albo przycisza głośność. Strasznie wkurzające, pomaga wyłączenie Skype.
  • W Linuksie (przynajmniej Ubuntu) ciągle nie dorobili się 16-kilohercowej obsługi profilu HSP/HFP w Bluetooth. Znaczy przy rozmowie przez Linuksa jakość jest tylko 8-kilohercowa (słuchanie muzyki idzie przez profil A2DP i jest OK). No katastrofa. Badałem temat, wymagane do dodania tej obsługi były zmiany w czterech modułach, w trzech zrobiono je już dawno temu, w czwartym nadal ich brak i nie wiadomo kiedy będą. W sieci jest sporo skarg korporacyjnych developerów, że managerstwo i administracja chodzą sobie w trakcie meetingów po kawę z bluetoothowymi headsetami, a oni muszą siedzieć przywiązani kabelkami do ich linuksowych developerskich pecetów.

Drukarka

Miałem kiedyś atramentówkę Epsona ze skanerem, niedrogą, ale była nawet niezła, tyle że tusze drogie. I krótko po gwarancji zaczęła robić problemy, wyglądało jak planned obsolescence - wywaliłem ja i kupiłem podobnego Canona. Canon miał dodatkowy, większy czarny tusz do drukowania dokumentów - czyli w eksploatacji wychodził trochę taniej (z naciskiem na trochę), ale jako drukarka był gorszy. No i ciągłe dokupowanie tuszu po kilkanaście euro od koloru nadal było bardzo wkurzające. Ostatnio musiałem wydrukować rozliczenie godzin, i nagle się okazało że  tabelki w kolorze nie-całkiem-czarnym w dokumencie nie są robione z czarnego, tylko przez mieszanie trzech podstawowych. I ponieważ któryś tusz się skończył, wydrukowało się na bladozielonkawo. Miałem zapasowy tusz w szafce ale wyszło, że kupił mi się niewłaściwy, kasetka pasowała mechanicznie, ale drukarka jej nie rozpoznawała. Oczywiście rozpakowanego tuszu nie da się już oddać, więc jest w plecy.

Wkurzyłem się mocno i zacząłem rozglądać się za nową drukarką, może teraz laserówką? No ale kolorowa laserówka w domu to trochę overkill. Akurat był w Stiftung Warentest test różnych drukarek dla home office, analizując wyniki zauważyłem, że koszt strony wydruku w niektórych drukarkach atramentowych był szokująco niski - jakieś ułamki centa! Sporo niżej niż w laserówkach! No to się kompletnie nie zgadzało z moimi doświadczeniami, podejrzewałem wręcz błąd w tabelce, więc zacząłem drążyć temat.

Okazało się, że od stosunkowo niedawna pojawiły się na rynku atramentówki z tuszem nalewanym z butelki. Butelka na parę tysięcy stron kosztuje jakieś 10-13 EUR, a w zestawie z drukarką przychodzą już tusze na wiele tysięcy stron. Takie modele mają HP, Epson i Canon.

Postawiłem sobie w wymaganiach, żeby drukarka miała ethernet (bo w miejscu gdzie stoi kabelek mam, a to nie jest zbyt blisko routera WiFi), i żeby miała skaner. Podajnik do skanera niekonieczny, ale duplex do druku dwustronnego pożądany. No i żeby nie kosztowała przesadnie, w końcu nie drukuję tysięcy stron. I tu wybór się już mocno zawęził.

HP wyeliminowałem bardzo szybko, bo ich drukarki wymagają rejestracji u producenta, oni nawet sprawdzają ID butelki z której dolewasz tuszu. Serio, butelka ma podobno RFID, drukarka to czyta, i trzeba przy tej operacji mieć dostęp do internetu. No bez jaj, czegoś takiego wspierał nie będę.

Epson i Canon nie różnią się bardzo, głównie tym że Canon (Megatank) ma osobne głowice do koloru i do czarnego, a Epson (Ecotank) załatwia to jedną. Podobno Epsony drukują trochę lepiej, ale nie jestem wydrukofilem. Epson już na starcie dostał dużego minusa za obsolescence tej starej drukarki. Po porównaniu modeli wyszło mi, że optymalny dla mnie jest Canon PIXMA G6050. Ma ethernet, kolor, nie ma faksów i innych głupot, ma skaner i duplex, i nie jest przesadnie drogi (dał się znaleźć za 300 EUR). W tej cenie są trzy butelki tuszu czarnego po 170 ml, nominalnie każda na jakieś 6000 stron, i po jednej butelce  kolorowych, po 70 ml, na niby do 7700 stron. Ja wiem, your mileage may vary, ale to i tak zupełnie inny rząd wielkości niż przy kasetkach.

Canon PIXMA G6050

Canon PIXMA G6050 (Źródło: Canon)

Drukarka przyszła. Instalacja nie była całkiem trywialna (Ethernet jest defaultowo zablokowany, musiałem podłączyć ją na początek kabelkiem USB z wtyczką B, nie dołączonym do drukarki, dobrze że miałem taki, bo jednak jest dość rzadko spotykany). Potem się okazało, że dałoby się prościej, tylko instrukcja instalacji była marna. Przy wlewaniu tuszu trzeba trochę pokombinować żeby w butelce nie został jakiś centymetr sześcienny - trzeba na koniec trochę podsunąć butelkę w górę i dać mu spłynąć (chociaż przy tej cenie ten centymetr czy dwa nie robią różnicy, inaczej niż przy kasetkach). Ale wydruki są super, jestem pod wrażeniem (chociaż jeszcze nie próbowałem ze zdjęciami). Są też drivery do Linuksa, działają. Wyświetlacz na drukarce jest trochę przedpotopowy - dwie linie tekstu, mono, bez żadnego podświetlenia - ale po jaką cholerę właściwie miałby w tym miejscu być potrzebny kolorowy graficzny?

Drukarka ogólnie mi się podoba, jest co prawda mocno plastikowa, ale w tej kategorii cenowej OK. Parę plusów które zauważyłem dotąd:

  • Można drukować A4 bez marginesów.
  • Drukarka ma wbudowane robienie papieru w linie i w kratkę (w paru rodzajach), papieru nutowego, checklisty, formularzy kalendarzowych, ...- fajny pomysł, zwłaszcza że może być całkiem bez białych marginesów. Przy tych cenach tuszu to może się nawet opłacać w porównaniu z kupowaniem gotowych bloków. Jeden z rodzajów kratki może robić za papier milimetrowy (niestety kratka jest niebieska i dzielona co 5 mm). Szkoda tylko, że nikt nie wpadł na pomysł dołożenia papieru calowego.

Jedno co jest dyskusyjne to panel z przyciskami i wyświetlaczem z przodu. Panel w położeniu spoczynkowym jest pionowo i żeby zobaczyć co jest na wyświetlaczu trzeba kucnąć koło drukarki. W związku z tym można go odchylić, nawet całkiem do poziomu. No ale co za twit wymyślił, że jeżeli panel jest w pozycji pionowej, to nie można drukować? Tak, próba drukowania bez odchylenia panelu kończy się meldunkiem błędu na drukarce. Albo panel musi się kurzyć, albo za każdym razem trzeba go odchylić. Nie widać żeby w pozycji pionowej coś było zasłonięte i drukowanie miało być technicznie niemożliwe, a nawet jak by tak było, to co szkodziło zaprojektować go tak, żeby nie przeszkadzał?

Obudowy komputerów

Od czasu kiedy zrobiłem sobie serwer, zrobiłem też parę innych komputerów.  Ponieważ byłem bardzo zadowolony z obudowy serwera, nadal używam obudów tej firmy. Tyle że ta firma to nie jest Cooltek - to tylko niemiecki sprzedawca (i to wcale nie wyłączny), producentem jest firma Jonsbo z Chin.

Moimi faworytami są:

Jonsbo V4

Jonsbo V4

Jonsbo V4 (Źródło: Jonsbo)

Zalety:

  • Wchodzi do środka normalna płyta główna MicroATX i normalny zasilacz
  • Do tego mieszczą się się nawet trzy dyski twarde (2*3,5'' i 1*2,5'')
  • Wygląda super
  • Mieści się w regale o głębokości ok 40cm.

Oczywiście bardzo wypasiona karta graficzna w taką obudowę się nie zmieści - więc rzecz do gamingu się nie nadaje, ale na komputer do pracy jest super. Jest też wersja w naturalnym kolorze aluminium. Nie ma miejsca na DVD, ale jeżeli jest naprawdę potrzebny to można dołożyć zewnętrzny. Polecam użycie zasilaczy "modularnych", znaczy żeby wtykać im tylko potrzebne kabelki, bo przy pełnym pakiecie wszystkich kabli może być problem z miejscem. Cena - ok. 60 EUR.

Jonsbo C2

Jonsbo C2

Jonsbo C2 (Źródło: Jonsbo)

Zalety:

  • Wchodzi do środka normalna płyta główna MicroATX (chociaż tu już trzeba trochę uważać na jej wymiary) i normalny zasilacz
  • Do tego mieści się dysk twardy 3,5'' albo 2,5'' (chociaż czasem trzeba trochę kombinować, zależy jak wtyczki się układają)
  • Wygląda super
  • Mieści się nawet w regale Billy, na biurku też nie zajmuje dużo miejsca.

Oczywiście to też nie jest obudowa do gamingu, ale w większości zastosowań całkowicie wystarcza. Są jeszcze wersja srebrna, biała, czerwona i różowa (sic!). Tu zasilacz modularny jest absolutnie niezbędny. Cena - ok. 40 EUR.

Syn ma inne priorytety i jego faworytem jest:

Jonsbo UMX4 (Window version)

Jonsbo UMX4 (Window version)

Jonsbo UMX4 (Window version) (Źródło: Jonsbo)

To jest obudowa gamingowa, tu się zmieści wszystko. Zasilacz jest umieszczony nietypowo, bo z przodu obudowy i wylotem do góry. Ja bym nie kupił wersji z szybą, no ale ja nie gaminguję, przynajmniej chwilowo. Ale przyznaję, że wygląda super. Jest też wersja srebrna oraz oba kolory z blachą zamiast szyby. Cena- jakieś 120 EUR.

Zasilacze do komputerów

Nadaj używam zasilaczy firmy BeQuiet!, ale odpuściłem już używki serii Dark Power Pro - są trochę przyduże do tych małych obudów i to jest w sumie overkill - one są do wypasionych konfiguracji gamingowych.

Teraz przerzuciłem się na serię o oczko niższą - Straight Power, aktualnie generacja 11, ale już nówki. W tej chwili już wszystkie zasilacze tej firmy są modularne. Do moich niegamingowych komputerów kupuję najsłabszy model z tej serii - Gold 450W, za niecałe 100 EUR, i całkowicie wystarcza. Szczególnie dobre mają w nich wentylatory (można je też kupić osobno, nazywa się ta seria Silent Wings 3), one według danych technicznych mają oczekiwany czas życia 300.000 godzin - no tyle to żaden komputer raczej nie wytrzyma, każdy powinny przeżyć. W praktyce tych zasilaczy nie słychać prawie wcale, nawet w komputerze z SSD (oczywiście niegamingowym, przy dużym obciążeniu może być inaczej).

Zasilacz BeQuiet! Straight Power

Zasilacz BeQuiet! Straight Power (Źródło: BeQuiet)

Radiatory do procesorów

To jest dość bolesny temat, bo procesor pudełkowy ma zazwyczaj dołączony jakiś badziewny radiator z wentylatorem, który turkoce już od pierwszego włączenia. Ale ponieważ coś już jest, to szkoda wyrzucać i wydawać kasę na inne.

Tymczasem nauczyłem się, że tu jednak nie warto oszczędzać - bo nawet wentylator na radiatorze w moim serwerze, markowy jak najbardziej, mi się tymczasem rozsypał, i przez parę dni zanim przyszedł nowy nie miałem serwera. Do serwera po prostu kupiłem tego SilentWings 3 (za kilkanaście euro), i przyczepiłem go na trytytki. Aha - polecam kupować wentylatory z PWM, płyty znacznie lepiej sterują prędkością obrotową takich, i jest ciszej.

Wentylator BeQuiet! Silent Wings 3

Wentylator BeQuiet! Silent Wings 3 (Źródło: BeQuiet!)

Do innych komputerów w obudowach V4 kupuję teraz od razu cały radiator od BeQuiet!, model Shadow Rock LP (za trzydzieści kilka EUR), też z tymi dobrymi wentylatorami.

Radiator BeQuiet! Shadow Rock LP

Radiator BeQuiet! Shadow Rock LP (Źródło: BeQuiet!)

Niestety nie mieści się on do obudowy C2, i w tych komputerach muszę używać nie tak dobrych rzeczy - radiatorów Arctic Alpine 12 LP. One też mają PWM, mają hydrodynamiczne łożyska ślizgowe, i kosztują tylko 12 EUR. Ogólnie są spoko, jedynym problemem jest mocowanie do płyty - one mają rozwiązanie podobne do tych stockowych radiatorów, z plastikowymi rozporami. Raz to jakoś działa, ale za każdym zdjęciem i ponownym założeniem jest gorzej. Te droższe mają mocowanie całkiem metalowe i na śrubki, to zupełnie inna klasa.

Radiator Arctic Alpine 12 LP

Radiator Arctic Alpine 12 LP (Źródło: Alpine)

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

Dotyczy:

Kategorie:Programowanie

5 komentarzy

Czas nieutracony (8) – Skrzynka z narzędziami

Trochę polecanek (lub niepolecanek) związanych z narzędziami do programowania, których używam w moim projekcie.

Total Commander

Total Commander to coś dla wychowanych na Norton Commanderze - file manager z dwoma panelami i masą przydatnych funkcji. Za najprzydatniejszą uważam szybki podgląd pliku przez F3, a zwłaszcza to, że następne F3 szuka w pliku ustawionego wcześniej stringa (również regular expression) a potem proste Esc zamyka okienko i wraca do listy w panelu. Szukania interesującego mnie miejsca w mnóstwie plików nie da się zrobić szybciej. Bardzo mi brakuje programu z taką funkcją na Linuksie - tam używam Krusadera, on też otwiera podgląd przez F3 (tyle że wyraźnie wolniej, bo za każdym razem startuje aplikację zewnętrzną) i wychodzi z niego przez Esc, ale nie przejmuje stringa do szukania - to jest akurat oczywiste, bo on startuje niezależną aplikację zewnętrzną i nie ma interfejsu do przekazania tego stringa.

TotalCommander

TotalCommander

Total Commander to shareware (tak! klasyczne shareware jeszcze istnieje!), działa również jako free (tyle że na starcie trzeba dodatkowo kliknąć buttona). Zajęcie się moim projektem skłoniło mnie do zapłacenia wreszcie za ten program (to był jedyny, którego od dłuższego czasu używałem bez kupienia go). Cena: 45 EUR.

Beyond Compare

W praktyce pracy programistycznej bardzo często trzeba porównywać pliki tekstowe albo całe katalogi. Na przykład co się w pliku zmieniło między checkinem X a Y, albo czym różni się nowe delivery jakiejś biblioteki od poprzedniego. Wiele narzędzi ma coś do porównywania wbudowane, ale zdecydowana większość tego jest po prostu słaba. Beyond Compare to zupełnie inna jakość, nieporównywalna z tamtymi. Można porównywać katalogi i pliki używając dwóch paneli, mergować na trzech panelach, ustawiać własne reguły porównywania, filtrować pliki, robić porównania batchem z CLI, ... Program poznaje różne rodzaje plików i odróżnia wtedy zmiany istotne od nieistotnych (na przykład komentarze w kodzie). Świetna rzecz.

BeyondCompare

BeyondCompare

Licencja kosztuje 30 USD (w wersji standard) albo 60 USD (wersja pro), to jest per-user - znaczy można mieć na większej ilości swoich komputerów, byle używać osobiście jednej na raz. Działa też na Linuksie. Download działa przez 30 dni jako trial, bez płacenia, można wypróbować czy warto.

Atlassian Confluence, Jira i Bitbucket

Zanim wziąłem się za mój projekt, miałem już na swoim serwerze różne darmowe programy robiące z grubsza to, co robią te od Atlassiana: Do zapisywania różnych informacji miałem DokuWiki, do ticketów próbowałem Traca i Bugzilli, jako serwer gita próbowałem gitei i jeszcze czegoś (nazwy już zapomniałem). Ale zauważyłem, że Atlassian daje licencje na większość swoich produktów w wersji na do 10 użytkowników self-hosted po 10 USD, myślę że intencją było danie triala nie całkiem za darmo. Więc kupiłem, przecież to prawie jak za darmo. Trochę pamięci na serwerze to wymaga (poniżej 16GB nawet nie próbujcie), co kilkanaście - kilkadziesiąt sekund sporo rusza dyskiem, nawet jak nic nie robić, ale działa bezproblemowo. Zestaw ten przebija oczywiście każdy darmowy, niestety nawet jeżeli będziecie chcieli go kupić, to już jest za późno - Atlassian poszedł w chmurę i nowych licencji self-hosted już nie sprzedaje. Za te 10 USD ma (a raczej miało) się licencję bezterminową, z supportem przez rok.

A jaki jest sens posiadania czegoś takiego w domu?

  • Bitbucket - oczywiście, można używać darmowego githuba, ale wrzucilibyście tam źródła swojego projektu, który daje wam przewagę nad wszystkimi konkurentami? Gitea owszem, działała, ale była bardzo uboga w funkcjonalność.
  • Jira - system do ticketów ma głęboki sens - przy pracy nad projektem zawsze będzie jakiś problem, albo coś, co ma się zamiar zrobić później. Albo przy błędzie mamy jakieś spostrzeżenia czy wyniki testów. I teraz żeby to nie zginęło, gdzieś to trzeba zapisać - i system ticketowania jest do tego idealny. No i jeszcze można na podstawie ticketów robić release notes... A te darmowe były bardzo ograniczone - Jira to jest jednak inna klasa.
  • Confluence - podobnie jak przy ticketach - różne przemyślenia, plany, obserwacje czy wnioski trzeba mieć gdzie w systematyczny sposób zapisywać. Confluence jest do tego OK, zwłaszcza po sprzęgnięciu z pozostałymi dwoma programami. DokuWiki też działało, ale Confluence jest bez porównania lepsze.

GitExtensions

Jako klienta GUI do gita używam GitExtensions - wypróbowałem wszystko, co dostępne i ten jest moim zdaniem najlepszy. A przy tym darmowy. Niestety nie udało mi się jak dotąd uruchomić go na Linuksie, mimo że ma tam podobno działać (pod mono). Ale oczywiście nie każdemu musi pasować - kolega spróbował i coś sobie zepsuł, bo defaulty były inne niż się spodziewał.

GitExtensions

GitExtensions

Eclipse

Eclipse każdy zna, nie jest to już state-of-the-art, ale nadal daje się używać. Mnóstwo wariantów i rozszerzeń, można z tym robić prawie wszystko.

Visual Studio Community Edition

Visual Studio uważam za znacznie gorsze od Eclipse, ale no cóż, jak trzeba robić z czymś od MS, to nie tak łatwo znaleźć coś lepszego, darmowego. I - tak - Visual Studio ma wersję darmową, nazywa się to Community Edition, aktualna wersja to 2019, jest przeznaczone dla osób prywatnych i małych firm (do 5 developerów). Szczególnie nie lubię integracji Visual Studio z Gitem - to nie jest dobrze zrobione, dlatego właśnie używam kombinacji GitExtensions / Beyond Compare. Nawiasem mówiąc integracja Gita z Eclipse wcale nie jest lepsza.

I jeszcze ponarzekam na debugger do C# - program puszczony pod debuggerem, nawet bez żadnych breakpunktów, jest o wiele wolniejszy niż puszczony normalnie. Już nawet byłem podłamany jak wolno działa porównywaczka do plików .arxml, którą zrobił dla mnie kolega, ale potem się okazało że puszczona nie z debuggera działa jednak z niezłą prędkością.

Enterprise Architekt

Jeżeli miałbym polecić coś do modelowania, to miałbym poważny problem. Pracowałem z wieloma różnymi takimi programami, i nie ma nic idealnego. Ostatnimi czasy coraz popularniejsze robią się bardzo okrojone narzędzia tego typu, w których tylko rysuje się diagramy jako rysunki, albo można tylko tworzyć obiekty bezpośrednio odpowiadające obiektom UMLowym. Przyczyną tego jest niewątpliwie generalne rozczarowanie MDD - modelowanie jest OK, ale reszta procesu okazała się za trudna. Sama specyfikacja UML2 też idealna nie jest, mam dość często problemy z wyrażeniem pewnych aspektów projektu w UMLu.

Enterprise Architect - jak pisałem wcześniej - jest już mocno przestarzały, ale ciągle ma niezłą relację cena/features, jeżeli chcecie zrobić coś więcej niż tylko standardowe diagramy w UML. Tu też jest 30-dniowy trial.

 

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

Dotyczy:

Kategorie:Programowanie

Komentarze: (1)

Warto zobaczyć: Braun Sammlung Kronberg

Dziś całkiem świeże zdjęcia i nowa wycieczka.

Już parę lat temu zauważyłem, że w okolicy mam jeszcze jedno muzeum mniej-więcej techniczne którego jeszcze nie widziałem - Braun Sammlung w Kronbergu. Kronberg to taka nie za duża (ok. 17.000) miejscowość w Taunusie, z dużym udziałem bogaczy wśród ludności - bo to blisko Frankfurtu, ale tam samoloty nie latają i jest cisza. Braun był dla mnie jasny - to ta firma od maszynek do golenia, elektrycznych szczoteczek do zębów i innych wyrobów gospodarstwa domowego, ale również na przykład sprzętu grającego, najbardziej znana z niezłego designu swoich produktów. Ale dlaczego akurat Kronberg - tego nie mogłem skojarzyć. Przyczyna jednak jest, i to bardzo istotna - ale najpierw trochę historii.

Firma Braun powstała w roku 1921 we Frankfurcie, założył ją pochodzący z Prus Wschodnich inżynier Max Braun. Jego pierwszym produktem był przyrząd do łączenia skórzanych pasów transmisyjnych. Tego rodzaju pasy były w tych czasach używane powszechnie do napędu maszyn - w fabryce, gdzieś wysoko był poprowadzony wałek napędzany jakimś rodzajem silnika (mogło być wszystko - maszyna parowa, silnik spalinowy, koło wodne, ...). Z tego wałka moc była przekazywana do wszelkich maszyn właśnie skórzanymi pasami. Krytycznym miejscem było łączenie pasa - a trzeba to było zrobić na miejscu, żeby długość była właściwa.  Przeniesienie napędu pasami skórzanymi stosowano również w rolnictwie, na przykład gdy traktor lub lokomobila napędzały młocarnię.

Braun urządzenie do łączenia pasów transmisyjnych

Braun urządzenie do łączenia pasów transmisyjnych

Jak widać na zdjęciu, urządzenie Brauna wbijało w końcówkę pasa spiralę z drutu, jak to dokładnie robiło trudno powiedzieć. Spirale były chyba spłaszczane i łączone sztyftem. Przyrząd Brauna sprzedawał się bardzo dobrze, bo jego połączenie było trwalsze niż w innych rozwiązaniach.

Od 1923 roku Braun zajął się również odbiornikami radiowymi, najpierw detektorowymi, potem lampowymi. Szło mu na tyle dobrze, że w 1926 przeniósł się z produkcją do pomieszczeń typowo fabrycznych (jego poprzedni adres to była istniejąca do dziś kamienica, podejrzewam że miał warsztat w oficynie). Potem robił głównie w technice radiowej, jak wynika z różnych rzeczy które czytam w ramach researchu produkcja odbiorników lampowych wymagała wtedy jakichś zezwoleń (Bauerlaubnis), o które nie było łatwo. Braun przejął w tym celu zakład niejakiego Carla Sevecke, który takie zezwolenia miał. W czasie wojny Braun produkował nadajniki radiowe dla wojska, a w 1944 jego obie fabryki (druga to ta po Carlu Sevecke) zostały zniszczone w nalocie.

Zaraz po wojnie Braun wznowił produkcję latarek na dynamo (produkował je już od roku 1938). Miałem kiedyś dokładnie taką latarkę w ręku, miał ją mój wujek, podobno wyprodukowano ich około 3 milionów sztuk. Tu anegdota: Wcześniej miałem książkę o majsterkowaniu, pod tytułem bodajże "Młody konstruktor" (gdzieś mi zaginęła), i pamiętam do dziś mój WTF? przy poradzie żeby cośtam wziąć ze "starej latarki, której wytarte koła zębate nie nadawały się już do użytku" (cytat z pamięci, naprawdę zrył mi psychikę, więc raczej wierny). Latarkę z kołami zębatymi zobaczyłem dopiero wiele lat później.

Braun latarka na dynamo

Braun latarka na dynamo

Od 1947 Braun wrócił do odbiorników radiowych, a w 1950 wymyślił i opatentował swój system elektrycznej golarki, takiej z folią z dziurkami i oscylującymi ostrzami. W sumie to nie wiem na czym dokładnie polegał jego wynalazek, bo wszystkie te elementy były znane i opatentowane już wcześniej. (Fun fact: w polskiej wiki nie ma artykułu o goleniu, jest tylko o Goleniu owiec). 

Krótko później, w roku 1951, Max Braun zmarł nagle na zawał serca. Firmę przejęli jego synowie Artur i Erwin. Erwin miał koncepcję, że firma to nie powinien być tylko biznes, ale holistyczny projekt społeczno-kulturowy. Wprowadził na przykład zdrowe jedzenie w zakładowej kantynie, ale przede wszystkim zatrudnił sporo prawdziwych designerów, w tym dwóch wywodzących się z Bauhausu (muszę zrobić parę notek o Bauhausie, trochę swoich zdjęć już mam). No i ci designerzy zaczęli robić naprawdę dobrą robotę. Przeprojektowali wszystkie dotychczasowe produkty firmy nadając im jednolity, prosty i elegancki styl. 

Tu przykład tego, co zrobili ci designerzy. Najpierw maszyna kuchenna, jaką zaprojektowano u Brauna w roku 1950 (Braun Multimix). Widać, że robił ją ktoś od maszyn dla przemysłu - brzydkie, trudne do utrzymania w czystości, pasowałoby do warsztatu gdzieś pomiędzy tokarką a frezarką.

Braun Multimix (1950)

Braun Multimix (1950)

Designerzy zrobili coś takiego - rzecz, jaką do dziś kojarzymy z maszyną kuchenną.

Braun KM3 (1957)

Braun KM3 (1957)

Podobnie zmienili design sprzętu RTV. Przed nimi, w Niemczech funkcjonowały nazwy grup towarowych: Duże AGD (pralki, lodówki itp.) to było Weißware (dosłownie: towary białe), a RTV - Braunware (towary brązowe), od drewnianych obudów. Designerzy Brauna poszli w biały, szary i czarny, funkcjonalność oraz proste Bauhausowe formy. 

Braun SK1

Braun SK1 (1955)

Nowo zdesignowany sprzęt RTV pokazano w roku 1955 na targach w Düsseldorfie. To była rewolucja, konkurent Brauna, Max Grundig stwierdził publicznie, że oni przez takie głupoty przeputają taką dobrą firmę po ojcu. Okazało się jednak, że praktycznie cała konkurencja nie wyłączając Grundiga musiała przestawić się na podobne idee w designie jeszcze przed końcem dziesięciolecia.

W 1961 w Kronbergu zaczęto budowę centrali firmy, stąd opisywane muzeum w tym miejscu. Mieści się ono w budynku w którym na dole jest REWE, a na innych piętrach głównie gabinety lekarskie, centrala firmy jest po sąsiedzku.

Największe sukcesy firma Braun miała na polu golarek, w związku z tym w 1967 została kupiona przez Gillette. Znowu Gillette w 2005 zostało wykupione przez Procter & Gamble. O tym, co i kiedy Braun zaczął lub przestał robić można jeszcze długo, może teraz coś o muzeum.

Braun Sammlung

Braun Sammlung

To jest muzeum fabryczne, więc mają tam porządny zbiór większości rzeczy, które firma robiła. A nawet były tam rzeczy, których na rynku jeszcze nie ma. No i to jest naprawdę dobry design, oglądanie go jest miłe i kształcące.

Inna obserwacja to to, że w krajach bloku sporo produktów było mniej lub bardziej zrzynane z designu Brauna. Może nie co do ostatniej śrubki, ale co najmniej koncepcja.

Jeszcze zobaczyłem coś takiego: Braun Lectron:

Braun Lectron

Braun Lectron

Braun Lectron

Braun Lectron

To jest zestaw edukacyjny do układów elektronicznych, złożony z kostek w rastrze 27x27 mm. Każda kostka ma w podstawie magnes, którym przyczepia się ją do metalowej podstawy. Po bokach są pola kontaktowe a na górze symbol elementu. System ten wymyślił w połowie lat sześćdziesiątych  Georg Franz Greger. W 1967 Braun kupił prawa do tego systemu na Niemcy. Historia systemu była długa i burzliwa, obecnie prawa do niego mają Warsztaty Rehabilitacyjne we Frankfurcie, w sąsiedniej dzielnicy Oberrad. Te warsztaty to placówka rehabilitacyjna dla osób chorych psychicznie, cel szczytny, ale w tej chwili nie da się ich produktu kupić (przez pandemię?). Ogólnie uważam to za zajebiozę, dlaczego nie ma tego w każdej szkole? Tu aktualna strona systemu.

Muzeum nie jest specjalnie uczęszczane, byliśmy tam jedynymi zwiedzającymi, nie sądzę żeby kiedykolwiek był tam tłok. Ale odwiedzić naprawdę warto.

Adres:

Braun Sammlung
   Westerbach Zentrum
   Westerbachstraße 23C
   61476 Kronberg im Taunus
   (To jest tuż obok stacji S-Bahnu Kronberg Süd)

Czynne: 11-17, w poniedziałki nieczynne

Wstęp:
Dorośli: 3 EUR
Dzieci 7-17 lat - 1,50 EUR

Sorry za brak mapy, ale sporo się namieszało - Google teraz chce pieniędzy za korzystanie z mapek, stare jeszcze działają, ale nowych już się nie da bez płacenia . Plugin którego używam (MapPress) obsługuje inne, darmowe źródło danych (Leaflet), ale na razie też mi się nie udało zrobić nowej mapki (pewnie jest w tym jakiś haczyk).

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

Dotyczy: , ,

Kategorie:Warto zobaczyć

2 komentarze

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

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

11 komentarzy

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

Komentarze: (1)