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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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