26 września 2016

Kucie

Zawsze powtarzałem, że profesjonalny twórca oprogramowania nie przestaje się uczyć nigdy.

Pragmatyczny programista mówi:
  • Naucz się jednego języka na rok
  • Przeczytaj branżową książkę raz na kwartał
  • Czytaj także niebranżowe książki
  • Korzystaj z kursów
  • Uczestnicz w spotkaniach lokalnych społeczności
  • Eksperymentuj z różnymi środowiskami
  • Bądź na bieżąco
  • Interesuj się (blogi, wykop, HackerNews, itp.)
Generalnie to fajne pomysły, ale jak to koreluje się z tym, co napisałem ostatnio we wpisie: Bicie piany gdzie twierdzę, że można niewiele zyskać z nauki nowego języka czy frameworku, ponieważ nasza branża zbliża się do pewnego rodzaju asymptoty technologii i frameworków. To znaczy, czy powinniśmy się uczyć nowego języka każdego roku, skoro niewiele można na tym zyskać?

Tak, oczywiście. Powinieneś uczyć się jednego nowego języka każdego roku. Kiedy to robisz, okazuje się, że pewne aspekty języków programowania stają się powtarzalne.
Kiedy uczysz się Lua okazuje się, że to po prostu JavaScript (i odwrotnie). Kiedy uczysz się Ruby, okazuje się, że to tak naprawdę Python, tylko w innych ciuszkach. Kiedy uczysz się Swifta odkrywasz, że to odgrzewana Java, która przeszła zapachem Pascala. Uczysz się języka GO i dochodzisz do wniosku, że to mieszanina C, Javy i Erlanga.

Zaczynasz widzieć pewne wzorce, które stoją za tymi językami i uświadamiasz sobie, że jest ich niewiele. Powoli dochodzisz do wniosku, że istnieją lepsze rzeczy do robienia w życiu niż odkrywanie niekończonych się kombinacji tych wzorców.

A więc, tak. Naucz się jednego nowego języka każdego roku, aby dojść do wniosku, że całkiem dobrze wyeksplorowaliśmy domenę języków programowania.

To samo odnosi się do frameworków. Naucz się jednego nowego frameworku rocznie, a zaczniesz uświadamiać sobie, że żaden z nich nie jest tak naprawdę nowy. Zaczniesz uświadamiać sobie, że, tak jak w przypadku języków, pod spodem jest lista powtarzalnych patternów, i jest to liczba ograniczona, i jak bezsensowne jest miksowanie tych patternów we wszystkich możliwych kombinacjach.

Czy ten punkt widzenia napawa Cię pesymizmem? Nie powinien. Fakt, że przeszliśmy wzdłuż i wszerz jakiś kawałek naszej profesji nie oznacza, że inne części są poznane. O kurka! Okazuje się, że lista, rzeczy do nauczenia się i poprawienia biegłości jest dosyć duża. Co więcej, podczas naszej niekończącej się krucjaty poznawania nowych języków i frameworków zaniedbaliśmy te rzeczy.

A więc, dla przykładu, porozmawiajmy o współbieżności. Jest to dziedzina, w której naprawdę leżymy i kwiczymy. Czy nie nadszedł już najwyższy czas, aby to zmienić? Czy nie byłoby dobrym pomysłem poznanie domeny współbieżności w stopniu, w jakim poznaliśmy domenę języków. Czy nie jest to szczególnie prawdziwe w czasach, gdy nasze aplikacje są coraz bardziej uzależnione od wieloprocesorowych środowisk? Czy gwałtowny wzrost liczby aplikacji hostowanych w chmurze oznacza, że możemy poszczycić się coraz lepszym zrozumieniem współbieżności?

No dobra, pozwól mi przetestować trochę Twoją wiedzę:
Jeśli nie możesz odpowiedzieć kompetentnie na większość z tych pytań to masz przed sobą kilka wspaniałych lat eksploracji i radzę Ci z nich skorzystać.

A jak tam protokoły komunikacyjne? Czy odkryliśmy wystarczająco to królestwo? Czy znasz tę domenę?
Jak daleko jesteś wyedukowany w klasykach naszej branży? Czy przeczytałeś i zrozumiałeś (wspominam tylko kilka):
Czy rozumiesz różnicę pomiędzy dyskretną symulacją zdarzeń a symulacją ciągłą? Kiedy byś użył każdej z nich?

Jak u Ciebie z teorią kolejek?

Czy rozumiesz jak zorganizować zestaw bramek i kolejek, aby zmaksymalizować przepływ w różnych środowiskach?

Czy jesteś zaznajomiony z algorytmami grafów?

Jak byś podszedł do znalezienia najkrótszej drogi pomiędzy dwoma miastami? A jak do znalezienia najszybszej?

Czy potrafisz napisać algorytm quicksort na żądanie, bez szukania w książkach / Googlach?

Czym są prawa De Morgana i do czego mogą Ci się przydać?

Jaka jest różnica pomiędzy automatami Mealy'ego a Moore'a?

Jak tam z Twoją geometrią obliczeniową? Jak obliczyłbyś pole dowolnego wielokąta?

Czy kiedykolwiek napisałeś algorytm genetyczny? Czy pracowałeś z siecią neuronową? Co wiesz o Big Data? Jak byś napisał bibliotekę do liczb zmiennoprzecionkowych? Czy kiedykolwiek napisałeś sterownik wejścia - wyjścia? Czy napisałeś system plików? Czy napisałeś wielozadaniowe jądro? Czy napisałeś kompilator?

Są jeszcze języki. Czy nauczyłeś się naprawdę ważnych - tych które naprawdę były innowacyjne, które były stopniami w drabinie, dzięki którym jesteśmy tu, gdzie jesteśmy? Czy nauczyłeś się Fortrana? Czy nauczyłeś się Cobola? Czy znasz Snobol i Forth i Lisp i Prolog i C?

Czy kiedykolwiek pisałeś w języku maszynowym, ręcznie łącząc swój kod w kod binarny?
Czy czytałeś oryginalny artykuł Alana Turinga : On computable numbers ...?


*~~~*


No więc, tak. Naucz się jednego języka na rok. Być może, że ten język będzie nowy -- dla Ciebie; ewentualnie będzie stary i znaczący dla naszej branży. Być może podczas nauki tego języka, nauczysz się czegoś z listy, którą tutaj przedstawiłem.

Pole uprawne naszej branży jest ogromne. Ledwo zadrapaliśmy powierzchnię. Jest wiele ważkich rzeczy do nauki o obliczeniach komputerowych i o oprogramowaniu. Byłoby szkoda, gdybyśmy nigdy nie odkryli tych głębi, ponieważ byliśmy rozproszeni błyskotkami. 

Wujek Bob

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :

22 września 2016

Automatyczne testowanie

Narzędzie o nazwie Selenium może pomóc w testowaniu aplikacji internetowych lub może automatycznie wykonywać żmudne zadania, które robię codziennie.

Jak stworzyć własny Gem w Ruby

Co to jest Gem w języku programowania Ruby?
To struktura, która przechowuje kod w Ruby do późniejszego, wielokrotnego wykorzystania. Coś w podobie jak plik *.jar w świecie Javy albo plik *.dll w świecie .NET.
Załóżmy, że nasz projekt będzie nazywał się hello_world. Komenda, która tworzy strukturę Gema wygląda tak:

bundle gem hello_world

Podstawy Programowania Funkcyjnego Epizod 3

Czy wszystkie Zasady Się Zmieniają? Kiedy tylko zaczynamy używać nowego paradygmatu , porównujemy z nim na...