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

Twit Programmers of the Year (6)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dotyczy: ,

Kategorie:Programowanie

Sledz donosy: RSS 2.0

Wasz znak: trackback

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


14 komentarzy do “Twit Programmers of the Year (6)”

  1. red1grzeg red1grzeg pisze:

    związek z wielkością rynku docelowego – w użyciu są urządzenia rożnych wersji, im wcześniej zaczynać, tym większa ilość potencjalnych klientów.

    Jak robiłem w okolicach developmentu na mobile (Android/iOS), to wychodziło że niespecjalnie opłaca się wspierać wersji starszych niż powiedzmy przedostatnia. Płacący użytkownicy zwykle używali aktualnych systemów.

    Ale uczciwie zaznaczam, że to było 5-8 lat temu. Mogło się pozmieniać.

  2. xp17 pisze:

    Nie wiem, jak to wygląda w przypadku iOS, ale jakoś tak odruchowo unikam produktów google i chyba dobrze robię. ;) z iPhona i MacBooka jestem bardzo zadowolony.

  3. maciek pisze:

    Płacący użytkownicy są istotni jeśli chcesz pieniędzy, bezpłatne programy mają inny rozkład. Ostatnie trzy wersje mają (wedle jakichś statystyk, ale pewnie statystyki liczą z Play Store, więc powinny być w miarę OK) niecałe 50%.

    A co do api do zbierania wszystkiego – normalny świadomy spraw prywatności użytkownik bierze kombinację LineageOS bez play services (z microg zamiast) + afwall+ i to mniej więcej daje się opanować. Większość aplikacji naprawdę nie potrzebuje dostępu do Internetu.

  4. charliebravo pisze:

    @MFC
    O muj borze przecież to było straszliwe paskudztwo. Biblioteka OOP, w której jednym z zaleceń było „najlepiej wszystkie pola publiczne, żeby klasy pochodne mogły swobodnie mieszać jak im się podoba”? No kaman. Dobrze zaprojektowana (oczywiście, do tego trzeba kogoś dobrego) aplikacja z tradycyjnym event loop (albo z jakimiś customowymi class wrappers) była całe poziomy lepsza od MFC.

    @wczesne reklamy Apple
    Sugerowały, że IBM to wielki brat. W tych czasach Microsoft się nie liczył, ot maleńka firemka produkująca interpreter Basica i jakieś inne dodatki.

    @Google vs Microsoft
    Co do meritum zgoda. Ja też z nostalgią wspominam hejt na Microsoft z licealnych czasów. Oni po prostu chcieli pieniędzy, ale można było sobie używać Linuxa, czy czego tam człowiek chciał. Google skutecznie kradnie prywatność, i jeszcze udaje, że „isn’t evil”. A jest dokładnie takim samym korpem jak cała reszta, z nieładnymi historiami patentów itp.

    • red1grzeg red1grzeg pisze:

      Sentymentalnie mi się zrobiło… :

      W latach 80-tych to rzeczywiście Microsoft to byli kolesie od MS-DOSa itp., ale ten moment maksymalnego hejtu (i postępowań sądowych) na MS to była połowa/końcówka lat 90-tych.

      Linux to była wtedy trochę teoretyczna masakra. Byłem wtedy młodym, ale kumatym użytkownikiem z bardzo dużą ilością wolnego czasu i pamiętam swoje próby uruchomienia Linuksa po raz pierwszy. I ciężko to szło. Klasyczny RedHat nie działał na mojej płycie głównej (konkretnie chodziło zdaje się o sterowniki kontrolera), ani żadna normalna dystrybucja w zasięgu ręki. Okazało się że trzeba zorganizować taką specjalną dystrybucję firmowaną przez Asus-a (Abit Gentus Linux to się chyba nazywało). Załatwiłem, zainstalowałem (po drodze partycjonowanie przy użyciu linuksowego (czyli innego) fdiska i inne wyzwania. Działa. Super, ale tylko w trybie tekstowym. X-y się wywalają przy starcie. Grzebie dalej, nie działa bo nie ma myszki. Myszka na USB nie-obsługiwana. Poprawiam, wymuszam konfigurację, startuje w końcu GNOME, ale myszki nadal nie ma. Bezsensu. Zniechęcam się do trybu graficznego. Ale chociaż żeby karta dźwiękowa, muzyki posłuchać. Drobiazg, tylko jądro trzeba skompilować. Uff, działa. Polskie litery.. To już miałem dość tego grzebania konfiguracyjnego na pół roku i zająłem programowaniem tekstowych (bo nie miałem pojęcia jak dostać się do grafiki) programów w C. I GCC to wreszcie była taka rzecz lepsiejsza od najlepszego dostępnego mi pod Dosem, czyli Borlanda.

      Dobra, już kończę :D

      Chciałem po prostu przypomnieć że Linux to było coś fajnego jako rozrywka dla hobbysty, względnie dla dość niszowych zastosowań.

      Ale jako komputer dla normalnego człowieka, to się nie liczył.

      Tymczasem Apple był podupadły, WordPerfect wylatywał z rynku na rzecz Worda, 1-2-3 i QPro na rzecz Excela. Windows miał wersje na Alphę, Silicon Graphics robił stacje graficzne pod Windowsa, Visual Basic zaczął dominować w casual programming, Access w biurowych bazach, pojawiło się Visual Studio, Internet Explorer, itd.

      W Internecie (albo zamiast Internetu) pojawiło się Microsoft Network, do grania miało był Microsoft Zone.

      Teraz może tego tak nie widać, ale był czas że Microsoft wyskakiwał z lodówki.

      • cmos cmos pisze:

        @Microsoft wyskakiwał z lodówki.

        Mieliśmy wtedy zaprenumerowany MSDN na CDkach, jakby zrealizowali wszystko co było w dokumentach strategicznych publikowanych tam, to wyskakiwaliby z lodówki tak samo jak Google dziś.

      • charliebravo pisze:

        @Linux jako komputer dla normalnego
        Racja, odpowiedziałem z wnętrza mojego bąbelka (wtedy) „programisty samouka”. Niemniej jednak, pamiętam jaka to była rewelacja w – bodaj – 94tym. Nie było nawet Windows 95, wszyscy mieli zestaw DOS+Win3.1+Borland, zwykle na 386 z 4MB RAM. W C koszmarne rypanie się z near/far i podobnymi 16-bitowymi wygibasami, jednocześnie z pełną świadomością że ta maszyna może więcej.

        A potem dostałem Slackware (chyba) 2.0 na kilkudziesięciu dyskietkach, odpaliłem sobie 32-bitowy UNIX z Xami, i pierwszy program w C, jaki skompilowałem zrobił po prostu malloc(2^20) – whoa!

        Ale tak, dla zwykłego użytkownika to się nie nadawało.

    • cmos cmos pisze:

      @MFC
      Co do OOP-owości to masz oczywiście rację, ale różnica w komforcie bez i z MFC była radykalna. Bez trzeba było pisać całe strony boilerplate code, a na porządne OOP i tak było trochę wcześnie. Portowałem kawałek programu Windowsowego w czystym C z 16 na 32 bity w 1999 (pierwsza robota po przemieszczeniu się do Niemiec, nikt inny w firmie tego nie umiał, jak zwykle musiałem ratować projekt przed katastrofą) – twarz bolała od facepalmowania, to już to marne MFC było bez porównania lepsze.

      @wczesne reklamy Apple
      W sumie masz rację, ta reklama to akurat 1984, ale ja zobaczyłem ją pierwszy raz znacznie później a Microsoft wtedy dokładnie kopiował strategię IBM-a, i pewnie dlatego mi się złożyło.

      • charliebravo pisze:

        @”a na porządne OOP I tak było trochę wcześnie”
        No cóż, w tych samych czasach, a nawet ciut wcześniej, kiedy „obiektowa biblioteka do programowania GUI” dla Microsoftu to było MFC, w firmie NeXT (to co założył Jobs jak go wyrzucili z Apple) powstało to, co Apple dziś nazywa Cocoa (https://en.wikipedia.org/wiki/Cocoa_(API)).

        I teraz tak – to wygląda trochę dziwnie, jak się nie ma doświadczenia z ObjC, ale ta technologia zupełnie dobrze broni się DWADZIEŚCIA LAT PÓŹNIEJ. I sądząc po tym, co piszesz o UI w Androidzie, to nie są godni autorom Cocoa myć nóg.

        Swoją drogą, jeśli bawisz się w programowanie rzeczy mobilnych, to poświęć trochę czasu na rzucenie okiem jak Cocoa jest zrobione. To jest naprawdę bardzo porządna inżynierska robota, i jak się już przebije barierę wejścia, to można bardzo sprawnie w tym programować. Twitów też trochę jest, na przykład na linii podziału między starą (do programowania Maców, klasy NS*) i nową (do programowania urządzeń mobilnych, klasy UI*) część kodu UI, ale ja nie znam lepszych bibliotek do GUI, a używałem wielu.

        • cmos cmos pisze:

          @porządne OOP
          Co innego zrobić porządne OOP, a co innego osiągnąć akceptację na rynku. W latach osiemdziesiątych robiłem na przykład proste kawałki w Moduli 2 i to był całkiem całkiem język modularny na bazie Pascala. Ale akceptacja jego była znikoma, było zdecydowanie za wcześnie. Wtedy w modzie były potworki w rodzaju Turbo Pascala.

          A GUI to ja tak naprawdę nie za bardzo lubię, bo to mnóstwo mało twórczego grzebania się, a ja mam trochę problemy żeby na koniec wyglądało rzeczywiście ładnie. Business logic bawi mnie o wiele bardziej.

          • charliebravo pisze:

            @”ja mam trochę problemy żeby na koniec wyglądało rzeczywiście ładnie”
            Kto z programistów nie ma. Poważne podejście jest takie, że to designer robi, i to też nie „bierze z sufitu”, tylko robi prototypy, badania z użytkownikami, i programista dostaje dokładny opis jak to ma działać. Mam przyjemność pracować z dobrym designerem, i ten gość naprawdę zasługuje na swoje pieniądze.

      • charliebravo pisze:

        Przepraszam za double posting, ale zapomniałem:
        @Microsoft kopiował strategię IBM
        No…nie powiedziałbym. Microsoft urósł na tym, że IBM chciał kupić „system operacyjny” do swojego tajnego „project Chess”, czyli przyszłego IBM PC. Microsoft swojego systemu nie miał, ale Gates (image tego gościa jako geniusza technologii jest IMHO sztucznie nadmuchany, ale w kategorii rekiny biznesu był mocny) kupił DOSa od kogoś innego i zaadoptował go na nową maszynę IBM. Jedni widzą w tym szczęśliwy przypadek, inni uważają że zawdzięczał to matce (https://en.wikipedia.org/wiki/Mary_Maxwell_Gates). Reszta to już historia, ale tak czy inaczej, Microsoft był raczej pijawką na IBM, niż „kopiującym strategię”.

        • cmos cmos pisze:

          @Microsoft kopiował strategię IBM
          Strategia IBMa cały czas polegała na monopolizowaniu rynku przy pomocy własnych (a przynajmniej posiadanych) rozwiązań. Udostępnić kawałek żeby wszyscy przyjęli to jako standard, a potem trochę pozmieniać i zmiany utajnić, żeby poważni klienci i tak musieli przyjść do nich. I jeszcze ubić tyle konkurencji, ile się tylko da. Najbardziej znanym przejawem tej strategii były pecety, ale na innych kawałkach rynku (również w sofcie biznesowym) robili to samo. Microsoft też jechał dokładnie tą samą strategią bardzo długo i w bardzo wielu segmentach.

  5. red1grzeg red1grzeg pisze:

    Dla mnie strategia IBM-a to była raczej taka litera T, połączenie szerokiego wsparcia dla rozmaitych rzeczy, z silną integracją pionową i produkcją zarówno sprzętu, jak i oprogramowania, z używaniem dobrych produktów jako pchaczy słabszych rozwiązań w imię integracji.

    Czyli miałeś kupić serwer oparty na procesorze Power, na którym instalowałeś AIX-a, na którym uruchamiałeś WAS-a, i na tym stacku dopiero pisałeś (używając narzędzi IBM-a) swoje oprogramowanie biznesowe. Które trzymało dane w DB2 na innym serwerze IBM-a. Ale jak potrzebowałeś serwera na Wintelu, to też mogłeś kupić od IBM-a. Tym wszystkim zarządzałeś za pomocą TAMITa, który pobierał dane z TAD4d, itd. I jak miałeś bazę Oracla na HP-UX, to też był dostępny chociażby kawałek jakiegoś Storage Managera do robienia backupów. A na laptopach analityków instalowałeś SPSS-a, czy innego Cognosa, które drukowały raporty na drukarkach IBMa, chyba że wysyłali mailem przy użyciu Notesów. Niektóre elementy tego stacka były bardzo dobre inne bardzo słabe, ale całość była dość unikalna, bardzo obszerna, nieraz niezbędna, zwykle koszmarna w konfiguracji i integracji (konieczne płacenie za support i serwisy) i jednocześnie bardzo mocno lockująca w vendorze.

    To jest skuteczna strategia, ale trzeba być bardzo silnym, żeby ją realizować. Wydaje się że IBM już nie jest taki silny.

    Microsoft w latach 80/90-tych jednak działał trochę inaczej (tylko soft, najchętniej masowe produkty i ograniczone wsparcie).

    Ale teraz właśnie (i to powód dla którego się rozpisuję, bo chciałem się podzielić obserwacją); i Microsoft i Google i Amazon; wygląda że realizują podobną strategię: rozszerzają działalność zarówno na hardware jak i soft, oraz chmura (czyli współczesny odpowiednik sprzedaży serwerów); ogromna integracja pionowa i bardzo szeroka działalność horyzontalna.

Skomentuj i Ty

Komentowanie tylko dla zarejestrowanych i zalogowanych użytkowników. Podziękowania proszę kierować do spamerów