Biznes

Google posiada mnóstwo danych o naszych zainteresowaniach, a nie potrafi przebić się ze swoim serwisem społecznościowym. VMWare nie może prześcignąć AWS, mimo że specjalizuje się w wirtualizacji. Oracle nie udało się zdetronizować Salesforce w kontekście platform CRM, mimo że postrzega produkt Salesforce jedynie jako nakładkę na bazę danych. Wreszcie Apple jest znacznie lepsze w robieniu dobrego sprzętu niż aplikacji. Skąd to się bierze? Anshu Sharma na Techcrunch uważa, że odpowiada za to tzw. Stack Fallacy Why Big Companies Keep Failing: The Stack Fallacy. A punktem wyjścia jest komiks XKCD:

Stack Fallacy jest przejawem ludzkiej natury – tym, że człowiek przecenia własną wiedzę i własne działania. Bo przecież to, czym zajmują się inni, jest tym samym, czym ja się zajmuję, tylko trochę w innym kontekście, prawda? Więc sam też świetnie bym sobie z tym poradził.

Skoro Oracle potrafi stworzyć bazę danych, która się sprzedaje, dlaczego miałoby dla niego być problemem zrobienie nakładki na taką bazę w postaci CRM?

Podstawowym problemem jest wiedza na temat, co konkretnie zbudować, znajomość potencjalnych potrzeb użytkowników. Dlatego też pójście w dół jest łatwiejsze, bo jest się naturalnym konsumentem niższych warstw i ma się znajomość własnych potrzeb. Dlatego też pewnie sporo firm technologicznych wypuszcza bardzo dobre narzędzia służące budowaniu aplikacji. Netflix i jego narzędzia DevOps, Google i MapReduce, Facebook i React, Twitter i narzędzia do analizy big data, LinkedIn i Kafka. Microsoft i Apple robiące sprzęt komputerowy. Wszystkie te przykłady dotyczą produktów, które zostały początkowo stworzone na własne potrzeby, a potem znalazły szersze zastosowanie.

A teraz krótka wzmianka o startupach, inspirowany wpisami Paula Grahama artykuł The 13 #Startup Survival Rules🚀 ↗, zilustrowany tym obrazkiem:

I startupów ciąg dalszy.

Cushion jest aplikacją dla freelancerów, pozwalających wizualizować harmonogram projektów, zarządzać własnym obciążeniem, opóźnieniami w projektach, rejestrować przychody itp. Tym, co jest szczególnie ciekawe z punktu widzenia tej sekcji jest to, że Cushion pokazuje na swojej stronie wszystkie swoje koszty. Jeśli jesteście ciekawi, ile płacą za hosting, ile za zarządzanie logami i za prowizje od płatności, możecie zajrzeć na tę stronę.

Steve Ridout spędził ostatnie trzy lata rozwijając własny startup, Readlang, dzięki któremu można uczyć się języków obcych. Do momentu publikacji swojej historii (3 Years as a One Man Startup) zarabiał znacznie mniej, niż byłby w stanie zarobić na etacie. Podejrzewam jednak, że po publikacji i po tym, z jaką atencją spotkał się na Hacker News, jego przychody w najbliższym czasie wzrosną.

W połowie stycznia na GitHubie ukazał się list otwarty twórców projektów Open Source do GitHuba, pod którym w ciągu dwóch tygodni podpisało się prawie 1500 developerów. Główne zarzuty dotyczyły ubogiego issue tracking w GitHubie, co powodowało, że twórcy projektów Open Source często musieli się dopytywać o szczegóły błędów, ale także tego, że sam GitHub nie jest projektem Open Source i że programiści nie mogą sobie zmienić, żeby było tak, jak chcą. Kilka dni później pojawiła się odpowiedź GitLaba, utrzymana w tonie: Hej! Dużo z tego już mamy i sami jesteśmy Open Source. Chodźcie do nas. Co będzie dalej? We wpisie lutowym będzie kontynuacja tego wątku, bo piszę to z opóźnieniem i już wiem, że historia ma ciąg dalszy.

Teraz o rezygnacji z pracy. O tym, dlaczego ludzie odchodzą, przeczytacie we wpisie Shields Down (happy people don’t leave jobs they love). Przełomowym momentem, zdaniem autora, jest, kiedy ludzie przestają zbywać maile, zapraszające do luźnej rozmowy na temat potencjalnych możliwości. Rozmowa oczywiście jest niezobowiązująca i nic nie znaczy, ale człowiek od razu zaczyna sobie układać pytania, pozycjonujące go w bieżącej i potencjalnej sytuacji zawodowej. Okazuje się, że zespół jest nie do końca taki, a możliwości rozwoju, czy awansu nikłe, a lider zespołu niegodny zaufania. Wtedy człowiek opuszcza tarczę (we wpisie jest ciągle mowa o shields down) i otwiera się na zmianę pracy.

Rozwój osobisty

W szachowej rozgrywce występuje się przeciwko innemu, przeciwnikowi. Każde posunięcie jest starannie zaplanowane i powinno prowadzić do ostatecznego triumfu. Tor Bair w artykule o znamiennym artykule Your Life Is Tetris. Stop Playing It Like Chess twierdzi, że człowiek za bardzo podchodzi do życia jak do partii szachów, a w rzeczywistości życie jest grą w Tetris. Losowe klocki pędzą coraz szybciej i trzeba je jakoś poukładać.

Z kolei wpis Tima Urbana Your Life in Weeks pokazuje, jak nasze życie jest policzalne w czasie. Artykuł składa się z szeregu wizualizacji i porównań, które dają sporo do myślenia.

Na koniec tej sekcji The Done Manifesto Lays Out 13 Ground Rules for Getting to Done, który pomoże ci działać efektywnie. A w zasadzie, to w ogóle pomoże ci działać, zamiast zwlekać.

Praktyka programowania

O tym, dlaczego programowanie jest czymś trudnym (Why Programming is Difficult) powinni przeczytać programiści i ci, którzy programistami nie są. Joe Armstrong, programista z dwudziestoletnim stażem pokazuje, że choć wydaje się, że stworzenie programu komputerowego jest czymś łatwym, to istnieje wiele czynników, które sprawę znaczącą utrudniają. Zwłaszcza kiedy mamy do czynienia z programem, który nie jest uruchamiany jednorazowo, tylko ma w przyszłości być utrzymywany i rozwijany. A oprócz tego są jeszcze czynniki środowiskowe, które znacząco utrudniają sprawę.

Stąd też programy mają określoną strukturę logiczną i praktycznie każdy z programistów prędzej czy później (lepiej prędzej) zastanowi się nad problemem, w jaki sposób poukładać logikę aplikacji. No bo tak, mamy obiekty domenowe, repozytoria, kontrollery i serwisy. Co gdzie powinno się dziać? Logika biznesowa powinna być w obiektach domenowych, serwisach, kontrollerach? W kontrollerach na pewno nie, ale tak czy inaczej ten wątek na StackExchange, a zwłaszcza drugi post, świetnie pokazuje, jak to wygląda w zależności od przyjętej architektury (warstwowa, MVP, DDD, SOA i inne).

Ciąg dalszy cake pattern: w tym wpisie lepiej niż u Bonéra (por. mój wpis z grudnia) wytłumaczone jest coś, co w ogóle pozwala na zastosowanie cake patterns, czyli tzw. explicitly typed self references. Generalnie chodzi o to, że w Scali w traits i klasach abstrakcyjnych nie muszę podawać, że mój trait dziedziczy po czymś, ale że jak stworzę obiekt, który dziedziczy po tym trait, to ten obiekt będzie musiał dziedziczyć też po innej klasie, albo innym trait. Skomplikowanie tłumaczę? :-) Najlepiej zajrzyj na tamten wpis.

Ciągnąc dalej wątek programowania funkcyjnego, podaję jeszcze dwie fajne stronki, na które się natknąłem, szukając wzorców projektowych w Scali: Design Patterns in Scala z blogu Pavela Fatina i Design Patterns z niestabilnej wiki na stronie Scali. Pierwszy pokazuje w większości przeniesienie klasycznych wzorców na Scalę, natomiast w drugim można się natknąć na dużo ciekawsze rzeczy: wzorce funkcyjne i wzorce typowe dla Scali.

A na koniec wskazówki, jak utrzymać porządek w plikach CSS (Introducing the CSS coding style guide). Coś, z czym mam zawsze straszne problemy…

DevOps

Teraz będą dwa wpisy dotyczące stosunkowo ogólnie programów komputerowych. Nie wiedziałem za bardzo, gdzie je wrzucić, bo trochę pasowałyby do biznesu, trochę do praktyki programowania, a trochę tutaj. Ponieważ w tej sekcji i tak nie mam nic ciekawszego, niech będzie w DevOps.

No, I Don’t Want To Configure Your App! – sam tytuł już mówi dużo. Pomocą niech służy XKCD:

W zasadzie główną myślą wpisu jest to, że Aplikacja to coś, co robi określoną rzecz w określony sposób, jest związana z user experience i powinna działać out of the box. Konieczność dodatkowej konfiguracji często wynika z tego, że ludzie nie są dobrzy w podejmowaniu decyzji i nie chcą ich podejmować. Dlatego twórcy przenoszą konieczność podjęcia tych decyzji na użytkowników.

Cały wpis opiera się na czterech regułach:

Rule #1: If I need to configure your application, you’re doing it wrong.
Rule #2: If you really need to, hold your user’s hands through using your app.
Rule #3: If anything goes wrong, you must help your users fix those problems in the best way possible.
Rule #4: Don’t require users to read manuals before using your thing.

Drugi wpis dotyczy ewolucji programów komputerowych (Evolution of Software Applications), która często podąża zgodnie z określonym schematem.

Stage 0: Humans, Paper, and Spreadsheets
Stage 1: Simple Script
Stage 2: Pile Of Files
Stage 3: The Framework
Stage 4: Beyond The Framework
Stage 5: Modularization
Stage 6: Network System

Najpierw ktoś ma jakiś problem, ktory rozwiązuje na kartce papieru, albu w arkuszu kalkulacyjnym. Potem powstaje prosty skrypt, a z czasem kilka skryptów. Potem framework (choć może biblioteka byłaby lepszym określeniem), jakaś nadbudówka, system komponentów, a wreszcie system aplikacji działających w sieci.

Architektura i narzędzia

Ostatnio na Hacker News pojawił się link do biblioteki do Pythona, która robi jedną prostą rzecz. Korzystając ze standardowego import w Pythonie, możesz zaimportować plik JSON. W momencie, kiedy to zrobisz, będziesz miał w kodzie dostęp do obiektu, takiego jak struktura zaimportowanego JSONa. Rozwiązanie tak proste i genialne, że na GitHubie pojawił się issue Gives me nightmares (Ever since I saw this I have been unable to sleep. Please fix. Odpowiedź: Works as intended. i oznaczone tagiem wontfix).

Ciekawostki

Początek upadku BitCoina? W artykule The resolution of the Bitcoin experiment jeden z głównych developerów twierdzi, że Bitcoin traci swoją demokratyczną naturę, poprzez wewnętrzne konflikty i nieczyste zagrywki ze strony chińskiej. Wpis jest dość kategoryczny i mówi o porażce Bitcoina w czasie przeszłym (np. Why Bitcoin has failed?).

Pamiętam, że kiedy po raz pierwszy byłem w Londynie, moja obecna narzeczona zwracała mi uwagę na to, żebym stał po prawej stronie schodów ruchomych i z lewej zostawił lewą stronę wolną. I faktycznie w Londynie jest taki zwyczaj – z prawej strony na schodach stoi rządek ludzi, a z lewej jest wolne miejsce, gdzie wchodzą ci, którym się spieszy. Okazuje się, że przez ostatnie święta tamtejsze przedsiębiorstwo komunikacyjne rekomendowało rezygnację z tego podejścia. Na jednej ze stacji, badania wykazały, że to, że ludzie stali parami na schodach, na całej szerokości, zwiększyło przepustowość z 81 osób na minutę do 112. Możecie o tym poczytać na Guardianie.

Na koniec o dochodzie podstawowym, czyli o stałym finansowym świadczeniu państwa na rzecz obywatela, niezależnie od żadnych kryteriów. Głównymi argumentami na rzecz takiego podejścia jest zapewnienie bezpieczeństwa finansowego obywatelom, przy korzyściach finansowych dla państwa, w postaci rezygnacji z pozostałych świadczeń socjalnych i tym samym kosztów utrzymywania aparatu biurokratycznego.

W Finlandi od listopada 2016 każdy Fin ma dostawać 550 euro miesięcznie, a niektóre dotychczasowe świadczenia socjalne mają być utrzymane. Model docelowy do 800 euro miesięcznie i brak innych świadczeń. W Szwajcarii ma być w tym roku referendum w sprawie wprowadzenia dochodu podstawowego (2500 franków szwajcarskich miesięcznie). A teraz YCombinator chce zlecić badania nad tym, czy coś takiego można wprowadzić w Stanach Zjednoczonych. Jak pisze Sam Altman na swoim blogu.

We’d like to fund a study on basic income – i.e., giving people enough money to live on with no strings attached. I’ve been intrigued by the idea for a while, and although there’s been a lot of discussion, there’s fairly little data about how it would work.

Podoba mi się ta idea i mam nadzieję, że wyjdzie z niej coś fajnego.