Umiejętności rowerowe

Do sklepu jest niecałe cztery kilometry. Szybkim krokiem pół godzinki, spacerem prawie godzina. Oczywiście razy dwa, bo trzeba jeszcze wrócić. Torby z zakupami są ciężkie, więc wraca się wolniej. Tak czy siak, codziennie schodzi godzinka-półtora na samo dotarcie do sklepu i powrót. A trzeba chodzić codziennie, bo rodzina duża. I głodna.

Chyba żeby się nauczyć na rowerze, wtedy można obrócić w pięć minut. Ale nauka zajmuje kupę czasu. Co najmniej ze dwa, trzy dni. To znaczy tak mówią, pewnie jedni się szybciej uczą, inni wolniej. No i jeszcze trzeba skądś skombinować rower.

Codziennie rano myślę sobie, żeby się zabrać za naukę jazdy. Ale rodzina głodna, nikt nie będzie czekał dwa dni aż się nauczę roweru. No i tak już trzeci rok chodzę dzień w dzień jak ten głupi.


"Umiejętności rowerowe" to coś, co mogłoby nam zaoszczędzić kupę czasu na dłuższą metę, ale czego nauczenie się dużo nas kosztuje (jednorazowo, ale jednak). Przy czym "kosztuje" niekoniecznie w finansowym sensie; może chodzić o czas lub o trudność nauki lub kilka rzeczy na raz.

W branży IT takich umiejętności jest całe mnóstwo i nie znam jednego człowieka, który posiadłby je wszystkie.

W moim przypadku wygląda to tak:

Umiejętności rowerowe (branżowe), które już opanowałem:

  • Klawisze skrótów w Excelu. Jest tego zatrzęsienie, znam może ze 2% wszystkich skrótów, ale nawet z tymi dwoma procentami czuję się czasem jak chakier z piekła rodę przy co poniektórych. Wada: nie działąją pod linuksami.
  • VBA. Głównie do zaawansowanych zabaw Excelem, ale nie tylko.
  • Język DOT do opisu grafów: wystarczy kilka chwil, żeby wygenerować całkiem kosmicznych rozmiarów graf zależności elementów danego systemu, o ile tylko mam dostęp do owych zależności w jakiś programowalny sposób (sql, json czy cokolwiek innego).
  • Obraz aktualnie używanego OS-a "na boku": kosztuje to około godzinki, żeby sobie taki obraz utworzyć (trochę więcej jeżeli ktoś nie umi), ale potem jak już komputer pójdzie w maliny (odpukać), odtworzenie z obrazu zajmuje chwilę i nie trzeba od zera wszystkiego instalować.
  • Powershell. Potęga programowania skryptowego w terminalu windowsowym (a ostatnio też i linuksowym). Zrobiwszy w życiu ze dwa większe projekty w Powershellu stwierdzam, że chociaż nie jest ani szybki ani elegancki, to jednak pozwala na bardzo sprawne budowanie całkiem poważnych konstrukcji z tysięcy podstawowych rodzajów klocków.

Umiejętności rowerowe, które aktualnie próbuję opanować, ale idzie mi jak po grudzie:

  • Bash
  • Markdown
  • Git
  • Wyrażenia regularne
  • Python (a zwłaszcza Pandas)

Umiejętności rowerowe, które chciałbym opanować, ale nie mam czasu/chęci/wiedzy/{tu wstaw własną wymówkę}:

  • vi (znam paru gości używających vi "natywnie" i strasznie im zazdroszczę)
  • emacs (jak wyżej)
  • i3wm (jak wyżej, mam kolegę w pracy, który śmiga w i3wm jakby się z tym urodził i strasznie mu zazdroszczę)
  • perl (mam w byłej pracy kolegę, który... wiadomo)

7 komentarzy

  1. a juz myslalem ze coś rowerowego bedzie ;-))

    skoro tu jestem to … jak można cokolwiek w Powershellu programować? 😀 sorry, jakoś nie umiem w te klocki, skoro bash jest dużo bardziej ludzki niż PS.

    Ale w temacie

    • Git -> to podstawa i jest trywialna 🙂 szybko załapiesz
    • Markdown -> bez tego nie wyobrażam pisania dowolnych notatek, zarówno na bloga jak i dokumentacji w GIT 🙂
    • wyrażenia regularne – ehhh ;)) do dzis nie lubie ale jak musze, to korzystam z nich. 😉
    • vi – brzmi jak sekta 😀 nano rlz!
    1. jak można cokolwiek w Powershellu programować? 😀 sorry, jakoś nie umiem w te klocki, skoro bash jest dużo bardziej ludzki niż PS.

      Powershell to de facto nakładka na .Net.

      Bash ma swoje zady i zalety, Powershell też. Siłą rzeczy w Bashu “robi” więcej ludzi, bo jest o ćwierć wieku starszy, ale PS ma kilka asów w rękawie. Na przykład potrafi z automatu podpowiadać nazwy i weryfikować typy parametrów funkcji i skryptów.

      Bash jest świetny pod Linuksami a Powershell – pod Windows. Oba działają tu i tam. Oba mają grono fanów i wsparcie społeczności.

      Sam “zrobiłem” w życiu dwa duże projekty w Powershell, to znaczy duże jak na moje skromne możliwości (ostatni miał około dwustu linii kodu w głównym pliku i coś z pięćset w dodatkowych bibliotekach). Stąd też wiem, że to całkiem solidne narzędzie. Oczywiście w swojej klasie tj. wśród języków skryptowych.

      Git -> to podstawa i jest trywialna

      Podstawa – tak. Trywialna – nie. Git jest moim zdaniem przekombinowany. A najgorsze jest to, że szukając rozwiązania konkretnego problemu w necie zawsze prędzej czy później natrafiam na “kreatywne” podpowiedzi, których zastosowanie zmienia mój problem z łatwego w jakiś koszmarek, którego odkręcenie wymaga wezwania lepszego nadszyszkownika i wysłuchiwania jaki to ja nie jestem “genialny” 🙂 Dlatego ostatnio staram się ograniczać naprawdę do najniezbędniejszego minimum: status, pull, push, commit, checkout, merge. Póki co, odpukać, jakoś idzie.

      wyrażenia regularne (…) – do dzis nie lubie ale jak musze, to korzystam (…)

      A ja lubię, bo są logiczne (choć mają porąbaną składnię i jest kilka dialektów). Jak napisał wikiyu, te krótsze idzie opanować, dłuższe to już magia. I niestety bez wyszukiwarki nie mam z nimi najmniejszych szans 🙂

      Co do nano, to oczywiście używam, jak większość. Ale na przykład w biegającym pojemniku Dockera na ogół nie ma nic poza vi i wtedy trzeba albo kląć i płakać, albo skopiować sobie plik na zewnątrz, edytować w nano i skopiować z powrotem do Dockera, a to już trochę p*przenie kotka za pomocą młotka…

      W Markdown bawiłem się już w miarę biegle, ale potem ekipa z Obsidiana zrobiła jakieś niekompatybilne wstecz “ulepszenie” składni i zapomnieli o tym poinformować użytkowników przed upgradem, w związku z czym moje pracowicie wydziergane drzewko wiedzy poszło w piach i się zniechęciłem. Dalej używam .MD z Git, jak trzeba zaktualizować readme, ale nic poza tym.

  2. PS – podziwiam, nigdy się nie zmusiłem do nauki… Owszem parę skryptów wydłubałem w nim, ale żeby się nauczyć “to co to, to nie”. Po prostu narysować prosty algorytm do ogarnięcia, opisać kodem i zrobić by działało… trochę kląć, a potem zapomnieć o problemach i używać nagminnie.
    Teraz jak wszędzie upycham na boku WSL to po prostu basha używam nawet na windowsowych zasobach.

    .MD – bardzo wygodne do wszelkich notatek wprost pisanych z powłoki. Bez mnóstwa zapychaczy edytora tekstów.

    git – no dobra, po prostu dla większości musthave – super że próbujesz

    regex… używam nieregularnie, nie umiem na wyrywki, a i tak w 90% przypadków wyrażenia dłuższe niż 20-30 znaków są bez sensu bo zupełnie nie nadają się do przejrzenia co miały robić, później niż tydzień od stworzenia. Tu bardzo polecam na yt słowa Pana Piotra Przybyła https://youtu.be/DELWr2Cw30g?t=1463 ale jest więcej w sumie tekstów i wystąpień w temacie. Krótki regex to coś co można ogarnąć umysłem gdy się to czyta (czyjś kod), długi… to papka wyglądająca jakby kot przeszedł po klawiaturze.
    Imho warto wiedzieć że istnieje, warto wiedzieć gdzie znaleźć support (cheatsheet, strony supportujące), ale nie warto znać na wyrywki.

    btw Bobiko – wszędzie gdize pojawia się rower się odkładasz? 😉

  3. Czyli dzielimy miłość do sekciarstwa vi/emacs. 😉
    Git jest prosty gdy mowa o podstawach, dalej gdy używa się dobrego narzędzia (przeklinam np. plugin do Eclipse) i wymaga codziennego doświadczenia gdy robi się rzeczy zaawansowane. Nie wiem w jakim punkcie jesteś. 😉
    A wyrażenia regularne – jak trzeba to otwieram help i piszę, nie wiem czy jest sens się tego wszystkiego uczyć na blaszkę. Podoba mi się wizja regexp replace w wielu narzędziach.

  4. Pandas to z tego co kojarzę państwo w państwie. Ale może moje wrażenie wynika z tego, że wykorzystywane raczej przez analityków danych, niż typowych programistów Pythona. Fix me if I’m wrong. Chciałbym mieć potrzebę się tego uczyć.

    Wyrażenia regularne, a dokładnie PCRE poznałem w czasach, gdy korzystałem z NNTP, czyli wcześnie. Potem korzystałem z Perla, który mocno je integruje. Chyba w żadnym innym języku nie używa się ich równie łatwo i naturalnie. W każdym razie znam przyzwoicie. A im dłużej znam, tym bardziej przychylam się do “jeśli masz problem i próbujesz rozwiązać go regexpem, to teraz masz dwa problemy”. I wcale nie o czytelność chodzi. OK, administracyjnie czy zgrubnie, na szybko, może pomóc, ale raczej nie jest to rozwiązanie poprane czy eleganckie. Jako przykład mogę tu zostawić dwa sztandarowe:

    1. regexp sprawdzający, czy adres email jest poprawny
    2. regexp sprawdzający, czy adres IPv4 jest poprawny (litościwie: w notacji CIDR)

    Polecam zrobić samemu i poszukać rozwiązań w sieci. 😉
    Niemniej, potwierdzam, że regexpy warto znać. Przydatna stronka https://regex101.com/

    Skoro przy Perlu jesteśmy… Używałem przez lata, IMO gwałtownie stracił na znaczeniu. W tej chwili trochę martwy język – nie kojarzę żadnych nowych projektów w nim powstających. Z racji powszechności użycia pewnie nie zniknie całkiem i będzie zapotrzebowanie, ale IMVHO nie warto już inwestować czasu.

    Git – kulawo i nieśmiało korzystałem. Potem trafiłem na wewnątrzfirmowe szkolenie z gita. Liczyłem na narzędziówkę, bo tam miałem braki, tymczasem szkolenie było o filozofii działania gita. Okazało się, że to jedno z lepszych szkoleń ever. Jak się poukłada w głowie co tam się naprawdę dzieje, to wszystko okazuje się dużo prostsze. Komendy też. I wcale nie trzeba w praktyce na codzień znać nie wiadomo jakiej ilości. A wiele rzeczy można osiągnąć na różne sposoby. Bonus: narzędziówka czyli polecenia są totalnie nieintuicyjne. To tak z perspektywy osoby, która korzysta, ale raczej w prostych projektach. Może przy kernelu Linuksa to wygląda inaczej.

    Markdown – podstawy znam, ale całe życie na cheat sheecie. Niby fajny, niby prosty, ale np. wstawianie URLi z opisem to tragedia.

    Bash – wstyd się przyznać. Niby znam, ale wiem, że tylko podstawy. Korzystam rzadko i znowu z podpórką. Może wynikać z tego, że zawsze cokolwiek dłuższego niż parę linii pisałem od razu w Perlu. O ile tylko platforma pozwalała, bo i jakieś embeddy bez Perla się zdarzyły. W ogóle bash jest dość niewdzięczny – łatwo popełnić błędy używając nieprawidłowych/niebezpiecznych (ale działających dla happy path) konstrukcji. Jeśli ktoś koniecznie chce programować w bash to polecam wyszukanie dla frazy defensive bash programming.

Leave a Comment

Twój adres e-mail nie zostanie opublikowany.