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

Czas nieutracony (11) – Wtyczki

Teraz pożalę się na Enterprise Architecta. W sumie mógłby to być odcinek cyklu o twitach.

Najpierw lekka dygresja. Robienie mojego plugina zacząłem od założenia stubów wszystkich funkcji API do pluginów, żeby zobaczyć co tam się dzieje. Ściągnąłem też dostępną dokumentację od Sparksa i zacząłem czytać forum u nich. Szybko zauważyłem, że Sparx nie za bardzo odpowiada na pytania, za to rządzi tam jeden gościu, niezależny guru od EA z Holandii, nazwiskiem Geert Bellekens. Ten gościu żyje z robienia konsultacji z EA i pisaniu pluginów na zamówienie. No i on opublikował darmowy framework do robienia takich pluginów w C# i kilka dość użytecznych pluginów ogólnego przeznaczenia. Ściągnąłem sobie to i zajrzałem do źródeł - to było całkiem nieźle zrobione, ale zorientowane na reusing przy robieniu wielu pluginów, przy jednym, jak u mnie, to by był overkill. Zostawiłem to więc, zajrzałem potem do tego może ze dwa razy.

Kwiatków w tym EA jest masa, parę przykładów:

  • Przy tworzeniu elementów i package pluginy dostają eventy PreNew i PostNew. Niestety przy tworzeniu package, w PreNew nie dostajemy informacji jak package będzie się nazywać, i w związku z tym nie możemy zapobiec utworzeniu obiektu o niepożądanej nazwie.  Przy elemencie to działa, więc nie ma że się nie da.
  • Przy usuwaniu obiektu jest tylko event PreDelete, nie ma PostDelete. Problem jest taki, że PreDelete idzie po kolei do wszystkich aktywnych pluginów, możemy dostać go i zgodzić się na skasowanie obiektu, ale inny plugin po nas  może mieć coś przeciwko i na koniec obiekt nie zostanie skasowany. Jeżeli podjęliśmy jakieś akcje w PreDelete - bo gdzie indziej? - to możemy stracić synchronizację.
  • Przy kasowaniu diagramu w PreDeleteDiagram nie dostajemy nawet ID kasowanego diagramu. Po co komu taki event, jeżeli nie wiadomo czego dotyczy?
  • Obiekt COM dla diagramu nie zawiera pola TreePos (pozycja obiektu pod parentem). W bazie danych takie pole jest, przy innych typach obiektów też, tylko w tym jednym miejscu im się po prostu zapomniało. No i przez to nie mogę zmieniać kolejności diagramów.
  • Jest event wołany po modyfikacji obiektu, no i on jest wołany po jednej modyfikacji od jednego do czterech razy. Jak zrobić porządną i szybką obsługę?
  • Po zmianie zestawu kolorów w EA, wszystkie okna dostają notyfikację. Wszystko pięknie w przypadku jego własnych okien, ale plugin nie wie, jakie kolory zostały ustawione, bo tą informację może wziąć tylko z registry, a EA zapisuje ją tam dopiero przy wyjściu z programu. No super.
  • Warto by było, żeby elementy mogły mieć więcej niż jeden stereotyp. W EA jest to, i owszem, możliwe, ale obsługa tego jest doczepiona na gumę do żucia, nawet nie pomalowaną wapnem żeby spoiny nie było widać. Więcej stereotypów można ustawić praktycznie tylko w jednym, specjalnym okienku, cholernie niewygodnym. W bazie danych jest do tego dodatkowa tabela, robiąca jeszcze pięć innych rzeczy. Lista linków w tabeli jest w polu tekstowym, polinkowane to jest przez GUID też zapisane jako string, co gorsza to stringi w hex mają pomieszane duże i małe litery, więc nie da się ich w programie obsługiwać jako klasy Guid (znaczy obsłużyć się da, ale nie można ich zapisać spowrotem bez rozwalenia linka), tylko trzeba  robić operacje na stringach. Nie mogę zrobić swojego porządnego okna do ustawiania tych stereotypów, bo nie ma API żeby poznajdować aktywne profile UML. Co za twit to powymyślał?

Bardziej złożone rzeczy:

  • Podstawowe obiekty w bazie danych to Package i Element. W bazie danych Element może mieć TaggedValues i stereotyp, Package nie. Wyraźnie w miarę rozwoju EA wymyślili jak to poprawić - do każdego Package tworzony jest ukryty Element, gdzie przyczepiane są te brakujące ficzery. Tyle że zatrzymali się w pół drogi- Package najwyższego poziomu nie ma tego Elementu, i w związku z tym nie może mieć ani stereotypu, ani TaggedValues. Dorobiłem swoje, w końcu sam operuję na tej bazie danych omijając EA, ale to nie zmienia faktu że pomysł takiego ograniczenia jest durny.
  • Żeby pokazać obiekt na diagramie jako port, taki przywiązany do brzegu komponentu, ten obiekt musi być - zgodnie z logiką - typu Port. Według AUTOSARa, pod portem jest jeszcze całe drzewo różnych obiektów. Problem jest taki, że EA bardzo ogranicza możliwe typy obiektów pod portem, próba podwieszenia tam normalnego elementu powoduje wyjątek. Udało mi się zrobić taki numer, że zmieniam typ Port na coś innego, podwieszam mu element, i przywracam typ Port. Działa, i owszem, ale tylko jeżeli ten port nie jest wyświetlany na aktualnie aktywnym diagramie. Musiałem dorobić jeszcze zamknięcie aktualnego diagramu w takiej sytuacji i otwarcie go ponownie. Pytałem o to wszystko support Sparxa, ale w ogóle nie zrozumieli problemu.

Mogę tak długo, ogólnie to musiałem zdublować dużą część funkcjonalności EA, i to jeszcze wkładając mnóstwo wysiłku żeby mój plugin i EA były cały czas synchronizowane. W sumie to trzeba by jeszcze tylko dorobić rysowanie diagramów, i wszystko było by moje. Tyle że to "tylko" to oczywiście wielka kupa roboty, ale w przyszłości trzeba będzie to zrobić.

Może jeszcze jedna historyjka z pogranicza EA i windowsów:

Typowym sposobem umieszczania obiektów na diagramach jest drag-and-drop z jakiegoś okienka z drzewem obiektów. Tak też robi się to w EA. Tyle że ja zrobiłem swoje okienko z drzewem, a upuszczać trzeba na okienko EA. Popróbowałem trochę dragdropować na bardzo różne sposoby, ale nie wyszło. Więc prowizorycznie zrobiłem menu kontekstowe z pozycją "Wrzuć do aktualnego diagramu" i to jakoś działało. Oczywiście obiekty były umieszczane wszystkie w tym samym miejscu, i trzeba je było potem przesuwać ręcznie. Zajrzałem jak zrobił to guru Bellekens, i on zrobił dokładnie tak samo - menu kontekstowe, bez dragdropa.

Ale potem zaczęło mnie męczyć: Owszem, nie daje się tego zrobić czystym windowsowym mechanizmem. Ale przecież dodaję ten obiekt do diagramu przez API, mogę też podać w którym miejscu on się ma pojawić - i tam się pojawia. Więc może nie trzeba tego robić "naprawdę" przez drag-and-drop, tylko wystarczy poudawać? Znaczy zmienić kursor myszy przy drag, potem rozpoznać czy jestem nad oknem diagramu, i po puszczeniu klawisza myszy dodać obiekt - przecież mogę mieć pozycję kursora myszy w stosunku do początku okna, a aktualne powiększenie diagramu w procentach jest w API.

No i rzeczywiście to zadziałało. Jedynym problemem było, że diagram mógł być przescrollowany i wtedy upuszczony obiekt nie trafił by na właściwe miejsce na diagramie. Ale kolega podpowiedział mi, że w Windowsach da się przeczytać pozycję scrollbarów obcego okna, i rzeczywiście się dało. No i mój udawany drag-and-drop działa super.

Do czego zmierzam: Jak niewiele trzeba, żeby w jakiejś niszy być guru. O panu Bellekensie jeszcze będzie.

I jeszcze: Zajrzałem właśnie na strony Sparxa, i tam jest o nowej wersji 16, na razie beta. Podobno będzie też jako 64-bitowa, jako podstawową bazę danych ma mieć SQLite. No to by był jakiś postęp, nawet jeżeli z udostępnionej dokumentacji wychodzi, że większość problemów które opisałem wyżej nie została usunięta. Inne pytanie, czy oni zrobią integrację tego SQLite dobrze - czy da się pisać do tej bazy równolegle tak, jak ja to robię. Na razie planuję zrobienie upgrade mojego EA na wersję Corporate - ona obsługuje też inne bazy danych, a korpo używa właśnie tej wersji. Podłączyłbym lokalnego MySQLa i bolesne ograniczenie wielkości pliku bazy danych by odpadło, pozostało by tylko to na 2GB w pamięci. A może by nawet szło szybciej. Tyle że te twity każą zakładać bazę danych i wgrywać schemat ręcznie, to ma się zmienić dopiero w tej wersji 16. Serio muszę zrobić swoje rysowanie diagramów i uwolnić się od tych twitowych narzędzi jak najszybciej.

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

Dotyczy:

Kategorie:Programowanie

2 komentarze

Czas nieutracony (10) – Okna i sharpy

Zabrałem się więc do roboty. Muszę się przyznać, że poprzednią rzecz z GUI dla Windowsów i z COM robiłem gdzieś w okolicach 2001, to jeszcze było C++ i MFC (albo coś krótko po MFC, jakieś AFX czy coś takiego, zdążyłem tymczasem zapomnieć). Potem robiłem na Windowsy już tylko w Javie i bez GUI, a jak w Javie to przecież nie z COM. Szczerze mówiąc, to nie lubię robić GUI, to jest cała masa żmudnej, nudnej roboty która mnie nie bawi. No ale co zrobić - samo się nie napisze.

Po tylu latach musiałem się oczywiście na nowo zapoznać z dostępnymi technologiami. Pamiętałem, że kiedyś istniała Java od Microsofta, zwana bodajże Visual J++, ale po sprawdzeniu wyszło, że już to już dawno nieaktualne - teraz microsoftowy zamiennik Javy to C#. I w sumie to jedyny sensowny wybór z języków .NET.  Więc trzeba było się z nim zapoznać. A, po drodze był jeszcze J#, ale też już umarł.

No i co do C# moje uczucia są mieszane. Owszem, ma to parę nowych, sensownych konstrukcji, na przykład partial class albo tuple. Z drugiej strony nie podoba mi się na przykład konwencja żeby zmienne mogły się nazywać tak samo jak typy, nawet bez różnicy w case. I w ogóle ta koncepcja żeby wszystko było obiektem COM z propertiesami też mi się średnio podoba. No ale podoba się, czy nie podoba, wielkiego wyboru nie ma. W sumie język jak język, C-pochodny pod względem syntaksu, Java-pochodny pod względem użycia maszyn wirtualnych i reflection, da się z tym żyć.

Dalej nastąpił wybór technologii do okienkowania. Owszem, zauważyłem WPF, jednak wolałem się w to nie wpuszczać. Zostało przy normalnych Windows Forms. W Visual Studio okienka designuje się graficznie, a IDE robi z tego kod w C#. Spróbowałem, ale większość moich okien musi być tworzona dynamicznie, zależnie od klasy obiektu który mam pokazać, więc w ten sposób się nie dało - większość okien muszę tworzyć z kodu.

I tu wkrótce wlazłem na problem: Zawsze było, że w takim C czy C++ to pamięcią trzeba zarządzać ręcznie i pilnować żeby zwalniać to co zaallokowane, a już niepotrzebne. Nawet w jednym projekcie zostałem najęty, bo sobie z tym nie poradzili i musieli restartować system co noc, inaczej im się zwieszał z braku pamięci (a sprzedawali tym systemem bilety na Expo 2000, tak po 100.000 na dobę). Wtedy posprzątałem, ale potem zawsze było że nowoczesne języki programowania, jak Java albo C#, to mają garbage collector i nie mają takiego problemu.

Tyle że guzik prawda. Po pewnym czasie mój program też się zaczął wieszać z braku pamięci. Po zbadaniu sprawy okazało się, że to ręczne zarządzanie w C++ to było łatwe, a w nowoczesnym C# trzeba się nakombinować. Problem polega na tym, że:

  • Garbage collector i owszem, jest, tyle że on z definicji zwalnia obiekty do których nie ma żadnych referencji.
  • Tymczasem wszystkie obiekty dialogowe również z definicji są referowane przez jakieś tam kawałki systemu.
  • Ja wkoło muszę tworzyć obiekty dialogowe na nowo (według struktury obiektu AUTOSARa, który akurat wyświetlam)
  • Znaczy - muszę je jawnie zwalniać. Całkiem tak samo jak w tych starych, marnych językach.
  • A nawet nie tak samo - klasy których obiekty zwalniamy muszą implementować interface IDisposable, i jest do tego dość złożony pattern, trochę inny dla klas bazowych, a inny dla dziedziczących.
  • Niektóre klasy są managed (przez garbage collector), inne unmanaged, trzeba zawsze patrzeć które są jakie, i jak i kiedy je zwalniać.

I w sumie to jest o wiele bardziej skomplikowane niż kiedyś. Postęp, tak ich mać.

A, jeszcze zanim wyczerpała się pamięć (a muszę działać na 32 bity, więc max to 2GB), to wcześniej zaczęły mi się wyczerpywać handle windowsowe. Wyszło że każdy obiekt dialogowy bierze parę do kilku takich handli, limit na proces jest 10.000, a w systemie jest ich tylko 32K. I jeszcze jest jakiś podział na system handles i user handles, i to wszystko działa w niezbyt jasny sposób. Ostatecznie pomogło dopiero porządne zwalnianie niepotrzebnych obiektów, ale potencjalnie to nadal jest problem.

O problemach z Windowsami mogę jeszcze długo. Na przykład:

  • Tworzę dynamicznie menu kontekstowe, Add new AUTOSAR object, może być duże (przez ToolStripMenuItem). Robione to jest w dwóch różnych kontekstach, przy testach mi wyszło, że w jednym z nich idzie to błysk, a w drugim trwa kilkanaście sekund. No WTF? Pierwotnie były do tego dwie różne funkcje (tak jakoś wyszło), były tam drobne różnice, ale zintegrowałem je w jedną. Nie pomogło. Ta sama funkcja - a zależnie od kontekstu różnica w czasie wykonania jest pięćdziesięciokrotna. Serio - mierzyłem. Znalazłem różnicę między kontekstami - jeżeli miało być to menu pierwszego poziomu, szło bardzo wolno, a na niższych poziomach szybko. Przemieściłem na niższy poziom i sprawa załatwiona, ale w kodzie .NET albo windowsów musi być w tych okolicach jakiś poważny problem.
  • Chciałem dopasować kolor moich okienek do schematu ustawionego w EA. No i te po pierwsze to ten cały framework nie ma supportu do takich rzeczy, znaczy żeby powiedzieć że wszystko ma mieć kolory według zdefiniowanego (przez siebie, nie systemowo) schematu, wszystko trzeba ustawiać ręcznie w kodzie dla każdego elementu z osobna, a po drugie jest straszny problem z ustawieniem swojego koloru dla captiona okna. No nie da się i już, chyba żeby wszystko rysować samemu. (Chętnych do podrzucenia linka do rozwiązania problemu proszę najpierw o sprawdzenie, czy to rozwiązanie jeszcze działa w aktualnych windowsach, bo takich już nie działających to znalazłem na pęczki).
  • W combo boxach chciałem mieć oprócz tekstu zawsze ikonkę. Teoretycznie żaden problem - ustawić owner draw, narysować i już. Przy większości kombinacji nawet działa, ale akurat przy takiej którą potrzebuję robi się coś dziwnego - przy przejściu do edycji w edit boxie combo boxa przestaje być wołany mój OnPaint, a okienko rysuje się takie, jak było około Windowsów 3.1. Serio, używany font jest taki jak wtedy – żeby wszystko działało jak chcę musiałbym całkowicie zimplementować całego combo boxa na piechotę (albo znaleźć jakiś gotowy).

No ale to nic szczególnego, każdy kto pisze coś na Windowsy ma takich historyjek na pęczki. Dalej będzie o bardziej specyficznych problemach.

 

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

Dotyczy:

Kategorie:Programowanie

2 komentarze

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