Moja nierelacja z WROC#

Nie bywam na konferencjach tak często jakbym chciał. Dlaczego? Myślę, że moim problemem jest nonkonformizm, przesadny indywidualizm. Będąc na konferencji trzeba się socjalizować. Uprawiać networking (nie cierpię tego słowa). Jak już się tam jest to warto by było skorzystać z okazji i zagadać do prelegentów. Porozmawiać z niewidzianymi od dawna kolegami ze studiów. Powiedzieć parę razy "zgadamy się" i kilka "będziemy w kontakcie". Czy to problem? Nie. Czy jestem osobą zamkniętą? Nie. Wręcz przeciwnie.

Nauka uczenia (się)

Człowiek uczy się całe życie. Słyszymy, powtarzamy ten truizm. Czasem jest to pochwała, najczęściej pocieszenie.

Wiedza, mądrość, inteligencja, czy to synonimy?

Na studiach uczymy się czy studiujemy? Po studiach jesteśmy mądrzejsi czy mamy większą wiedzę?

Czasami słyszę pytania skąd wiem to co wiem i w jaki sposób dowiaduję się co mam wiedzieć. Sam też często zadaję na rozmowach kwalifikacyjnych pytania: 

"Skąd Pani/Pan czerpie wiedzę?"

"Co Pani/Pan robi gdy natrafi na problem, z którym do tej pory się nie spotkała/ł"

"Czy ma Pani/Pan jakieś może nie autorytety programistyczne ale po prostu ludzi na których odpowiedzi Pani/Pan często trafia?"

Podsumowaniem odpowiedzi niech będzie miks:

"No wie Pan, zwykle to jak wszyscy: StackOverflow, Google. A osoby? Eee... Raczej nie kojarzę teraz, najczęściej to po prostu szukam odpowiedzi i tyle"

A Ty mój drogi czytelniku, czego szukasz na tym blogu? Rozwiązania problemu? Inspiracji? Tak sobie klikasz? Skrolujesz?

Sierpień 2007 roku był miesiącem, który nie zapisał się wielce na kartach historii, zaczął się jak każdy od 12 lat Przystankiem Woodstock. Przez Mikołajki przeszedł największy szkwał w historii. 46te urodziny obchodził pewien senator z Illinois. Wyszła pierwsza wersja jQuery. Gdzieś pomiędzy tymi wydarzeniami rozpoczął swoją zawodową karierę niżej podpisany blogger.

Cierpienia niemłodego bloggera - czyli próbuję napisać tekst o wczytywaniu komponentów w Knockout.JS na podstawie konwencji nazewniczej. Wymyślając przy okazji najdłuższy wpis w historii tego bloga. Doh! -_-

Życie bloggera to nie jest bułka z szynką. To nie prosta sprawa. Co prawda pomysły same wpadają do głowy. Idzie człowiek ulicą, drepcze tak sobie drepcze i nagle bęc, nagle bum! Albo koduje sobie taki, wymyśla rozwiązanie i myśli sobie: O! To świetny temat na blog! Warto się nim podzielić! Tylko potem to jakoś tak ciężko przelać na papier. Siada sobie Pan Redaktor. Zabiera się za spisanie swych wiekopomnych odkryć. Herbata stygnie, zapada zmrok a pod klawiaturą ciągle nic, obowiązek obowiązkiem jest, wpis musi posiadać tekst.

No i siadam. Klasyczne pytania. Jak zacząć? Jak Ciebie nie zanudzić, mój drogi czytelniku? Ej człowieku, pisz tam lepiej. Nie mazgaj się i tak piszesz dla siebie. Ale, ale... jak? To przecież nie ma być kolejny suchy, irytujący wpis jakich pełno w blogosferze. Chyba mnie grypa bierze...

Tyle rzeczy do przekazania... Tyle rzeczy do powiedzenia...

Może wspomnieć, że jest mi smutno, że Knockout.JS przegrał już jakiś czas temu walkę z Angularem? Albo, że wg mnie nie powinno się przenosić wprost backendowych wzorców do zupełnie innego środowiska JavaScriptu? 

Wspomnieć o tym, że nie mam zaufania do React? Że kojarzy mi się z programowaniem WinFormsowym? Hmmm...

A może po prostu wejść na pełnej k... i powiedzieć od razu, że mam świetną klasę, którą nazwałem ComponentByNamingConventionLoader? I że bierzcie i jedzcie z tego wszyscy? Dodać, że jeśli używacie Knockout.JS to na pewno Wam się przyda? Eeee... to jakoś nie wygląda... (Siorb) Ej! Herbata już całkiem zimna...

A może wrócić do podstaw? Może rozprawkę? Wprowadzenie, teza, argument pierwszy, drugi, trzeci, czwarty, potwierdzenie tezy, podsumowanie. Ma to sens. Ma to sens. Wszystko byle już wreszcie zacząć. Ołówek, notatnik i jadziem kapela.

What really grind my gears #1 - IIIIIIIIIIIIIIIIF!

Jestem spokojnym człowiekiem, niespotykanie spokojnym. Ale... Jestem Oskar, z Polski. Miejsca urodzenia nie przeskoczę. Natura, historia, zwyczaje, pierogi, kierpce, Szopen wieczorową porą. 

I irytacja. 

Rosnąca irytacja. 

Pulsująca irytacja. 

Przechodząca w krótkie, staropolskie słowo rozpoczynające się i kończące się na W.

No co ja na to poradzę? Po prostu wiele rzeczy mnie denerwuje. Co np.? To, że gdy chcę jeździć na rowerze to jest za gorąco albo pada deszcz. To, że po piciu  wódki na drugi dzień boli głowa. To, że studentów tyle w pociągach i to, że po każdej niedzieli przychodzi poniedziałek. Co ja będę Wam mówił, nie jest łatwo być Polakiem. Wicie rozumicie, wina Tuska.

Ciężko być Polakiem, ale być Polakiem i programistą to już tylko ciężej być kibicem i sprzedawcą butów (oh wait...). Te porażki w piłkarzyki w pracy, te przymusowe przerwy od przeglądania memów, gdy nam każą popracować. Ta dojmująca, nieznośna lekkość bytu. 

I IFy. 

IIIIIIFY. 

KŁIIII KŁIII KŁIIIIIIIIIIIFY. 

Englishman in New York, czyli jak .NETowiec może uwić sobie gniazdko w świecie MSSQL

Wieczór, herbata, ciepłe papcie, nie za twardy, nie za miękki narożnik, na którym wyciągasz swoje zmęczone nogi. Gdzieś w tle leniwie snuje się muzyczka plum plum plum... Cieplutko, mięciutko, strefa komfortu. Mmmmm... Klawo!

Gdy tak sobie leżysz w apogeum czilałtu muzyka przestaje nagle grać, idąc sprawdzić o co chodzi zahaczasz nogą i wyrywasz kabel sieciowy, potem przepala Ci się bezpiecznik od światła, a z kranu zaczyna ciec woda. Tyle było twojego komfortu...

Jedziesz na tydzień na narty do Czech. Niby wszyscy mili, niby podobny język, ale jednak jakoś tak dziwnie. Uśmiechy wydają się coraz bardziej ukradkowe. Po złożeniu zamówienia w restauracji do ostatniej chwili drżysz czy faktycznie zamówiłeś to co chciałeś.

Albo dajmy na to delegacja do Wałbrzycha lub Sosnowca...

Praca programisty daleka  jest od błogostanu. Nowy dzień, nowe problemy. Pudełko czekoladek prosto od Foresta. Szczególną sytuacją jest zmiana projektu. Konsternacja sięga zenitu. Nowe osoby, nowe środowisko i te parszywe nowe technologie.

"...you can hear it in my accent when I talk, I'm an Englishman in New York"

  

Jakiś czas temu doświadczyłem takiej zmiany. Drastyyycznej zmiany. Z intensywnej pracy przy mocno JavaScriptowym systemie przeszedłem na drugą stronę. Ciemniejszą stronę. Tam gdzie nie ma frontendu - systemu Business Inteligence w MSSQL.

"First I was afraid, I was petrified"
 

Nie tylko Ty się tak czułaś moja droga Glorio.

Suma wszystkich strachów

Czego się obawiałem?

1. Management Studio jest przyzwoitym środowiskiem do zarządzania bazą danych. Z funkcjonalnościami i rozbudowaniem Visual Studio nie ma jednak żadnego porównania. Ot taki mniej rozgarnięty koleżka. Ten co nosi za duże, używane rzeczy po starszym bracie.

2. Skryptów inkrementalnych. Każdy z nas wie jak bolesne jest utrzymywanie tego barachła. Oczywiście można sobie radzić, stosować konwencje nazewnicze, używać migracji w Entity Framework, ale czy to czyni sprawę przyjemną? Don't think so... Znośniejszą. W najlepszym razie. Dodajmy jeszcze do tego konieczność utrzymywania aktualnej struktury bazy, by można było zawsze odtworzyć ją od zera, kontrolę wersji i pracę na wielu branchach. Mniam. Mniam. Paluszki lizać.

3. Wdrażania na różne środowiska. Developerskie, Testowe, Preprod, Produkcjne, NaKolejneZyczenieKlienta. I każde z tych środowisk się trochę różni, na każdym trzeba trochę inne skrypty odpalić. Kup sobie chłopcze zapas melisy jeśli chcesz być wdrożeniowcem, wujo Ci to mówi. Jeden Cherry pick, drugi cherry pick, zapomnisz przerzucić jeden skrypt inkrementalny i KA BOOM! Nie ma Cię - ehę. Albo produkcji. Twoja premia też gdzieś się zapodziała.

4. Struktura i modularność projektu. Jak ładnie utrzymywać strukturę projektu w świecie MSSQL. Podział kodu, modularność, biblioteki, współdzielenie kodu przez różne projekty? Czy to w ogóle możliwe? Projekty w Management Studio, w porównaniu do tych znanych z VS to właśnie te spodnie starszego brata, które podcięto, żeby robiły za bojówki. Do tego kod się nie kompiluje, jak być pewnym, że po zmianie nazwy kolumny nie zapomnieliśmy poprawić kodu, w którejś procedurze? Jak być pewnym, że nasz projekt jest dalej stabilny?

5. No i na koniec duszki Kacperki w porównaniu z poprzednimi punktami. Czyli takie fanaberie jak intellisence, refactoring, sprawdzanie gdzie używana jest procedura, tabela, przystępniejsze debugowanie kodu. Małe rzeczy, które czynią nas szczęśliwszymi. 

SSDT To the Rescue!

SQLowa ciekawostka #1 - Uważaj na Exists kolego

Tym razem, po serii nostalgiczno-branżowo-przemyśleniowych wpisów, będzie krótko i technicznie. Chciałbym się przed wami popisać  swoją niewiedzą. Nie ma się w zasadzie czym chwalić, ale uważam, że głupotą nie jest brak wiedzy, co raczej wstyd przed jego okazaniem... No ale nie o to, nie o to, Oskarze, do sedna, do sedna...

Wczoraj podczas godzin spędzonych na szukaniu błędu natrafiłem w pewnej procedurze na takowy kod:

if exists (
 select Kolumna
 from Tabela t
 where t.Id = @Id
)
begin
 (...)zrób coś
end

Kod jak kod pomyślałem. Ale zastanowił mnie komentarz: "Zrób coś"  tylko gdy Kolumna ma ustawioną wartość. Rzuciło mi się to w oczy bo z zasady jestem wyczulony na kod, który wymaga komentarzy. Okazało się, że mimo tego, że dla mojego rekordu Kolumna nie miała wartości to IF zawsze zwracał TRUE i "robił coś". Dlaczego?

 

Ano dlatego, że dla EXISTS zwrócone przez subquery wartości nie mają żadnego znaczenia . Ważna dla niego jest tylko liczba zwróconych rekordów. Niezależnie od tego czy zwrócimy wszystkie czy jedną kolumnę, czy zwrócimy NULL, czy wartość dla Exists będzie to zawsze TRUE. Bo zwróciliśmy wiersz.

 

Pusty wiersz to nie to samo co brak wierszy.

 

Brak decyzji też często bywa decyzją...

Dla zwizualizowania odpalcie sobie dwa zapytania:

SELECT 1 WHERE EXISTS(SELECT NULL)

i: 

SELECT 1 WHERE EXISTS(SELECT NULL WHERE 1=2)

Mała rzecz a cieszy. Niby podstawy podstaw, a człowiek może dać się złapać. A przecież na MSDN jest jak wół napisane.
Codziennie człowiek uczy się czegoś nowego. I to chyba jest fajne w naszym zawodzie, czyż nie?

Borys najlepiej dryblował

Borys najlepiej dryblował, Cybor kręcił najlepsze rogale, było kilku kajtków, robiących 200 kapek. Moja piąta B, zawsze bo ciężkim meczu dokopywała piątej A. Od jakiegoś czasu graliśmy już tylko "na nowe". Ja nie robiłem setek zwodów, robienie kapek kończyłem na 20-30. Nie bawiło mnie to. Nie potrzebne mi były nadmiarowe ozdobniki, uważałem że koniec końców najważniejsze są podstawy. Kopnięcie piłki tam gdzie się chce. Co za różnica czy walnie się w okienko, brazylianę czy piłka ledwo się wtoczy? Ważne, żeby znalazła się w bramce. Koniec końców to się liczy. Sztuka dla sztuki? Nie dla mnie. 

W Fifę nigdy nie wybierałem Brazylii, nawet w 98ym nie grałem Francją. To byłoby za proste. W końcu lepiej iść pod prąd. Co to za trudność grać na nastrojonej gitarze? Lepiej przegrywać z lepszymi niż wygrywać ze słabszymi. Lepiej być szeregowym graczem w Manchasterze Utd. niż kapitanem w Miedzi Legnica. 

Zawsze czytam instrukcje. W końcu trzeba się przygotować. Trzeba skręcić jak należy. 

Nie kupuję rzeczy pierwszych z brzegu, sprawdzam Ceneo, czytam fora, na Allegro ustawiam snajpera.

Wczoraj po dwóch latach naprawiłem zepsutą żaluzję.

- Jaka jest Pana największa wada?
- Jestem perfekcjonistą.

Czasem mówię o sobie mistrz niedokończonych pomysłów. Jak większość z nas marzę o swoim własnym pomyśle, swoim własnym produkcie, startupie. Regularnie przystępuję do kolejnych błyskotliwych (w zamierzeniu) pomysłów i regularnie je nie dokańczam. Każda próba kończy się tak samo, "to samo miejsce inna dziewczyna". 

Oczywiście każdy mój projekt musi mieć solidne fundamenty. Najpierw architektura, framework. Wszystko musi być na tip top, najnowsze rozwiązania, dobre praktyki, wzorce projektowe. W końcu mam teraz wolną rękę, nie muszę się przejmować marudzącym klientem. Ogólnie to chyba u nas w branży często bywa jak w PKP, wszystko by zajebiście szło gdyby nie klienci. Często naśmiewamy się z tego, że co on tam wie, że głupek, że nie będzie uczył ojca dzieci robić. Co tam kolorki, przycisk przesunięty o 3 pixele w lewo, albo nie ten odcień? Ważne żeby było SOLID. Najważniejsze to mieć dobrą architekturę i świetnie funkcjonujące trzewia. Nasze projekty są jak góra lodowa, olbrzymie pod spodem, tylko widocznych efektów jakoś tak niedużo. 

W zeszłym tygodniu trafiła mi w ręce książka, w zasadzie ebook "Just Fucking Ship" napisana przez Amy Hoy. Świetnie trafiła w mój nastrój zadumy nad tym co robię źle. Dlaczego Borys jest tym pamiętanym przez wszystkich piłkarzem z podwórka, nie ja? Dlaczego mój tato mówi, że mam słomiany zapał? Dlaczego Xamarin i SignalR świecą sukcesy, a mój niedokończony framework z podobnymi założeniami leży gdzieś na końcu mojego dysku nie rozwijany od kilku lat? Przecież wydawałoby się, że robię wszystko jak należy. Rozsądek. Solidne podstawy. Wiedza. Doświadczenie. Mr Prim and Proper. 

Może to właśnie dlatego, że popełniam te same błędy co wszyscy (no prawie wszyscy), czyli:
- nie skupiam się na złapaniu króliczka tylko go gonieniu. Projekt zaczynam od frameworka, stronę od layoutu, a w ogóle to od wymyślenia nazwy domeny. Przez co tracę okres największego entuzjazmu na pierdoły, które z punktu widzenia produktu są najmniej ważne.
- nie notuję, nie spisuję planów - "no bo po co? Nie potrzebuję tego - ćwiczę pamięć"
- nie skupiam się na celu, nie wyznaczam sobie deadline'ów.
- nie postępuję w myśl zasady "start small, grow big". 

"How programmers spend time on a project. This one's funny because it's true" via @ErlangSolutions pic.twitter.com/qYJpPsQLFS
— About Programming (@abt_programming) January 31, 2015

Książka Amy nie jest wielce odkrywcza, nie da złotej recepty - nawet do tego nie aspiruje. To co na pewno da to powiew świeżości w głowie, otwarcie kilku zamkniętych zapadek i garść cennych, konkretnych, życiowych porad. Najważniejsza z nich to: wyznacz sobie cel, termin i po prostu to kurwa zrób. Najpierw cel i czas potem zakres i metody realizacji. Oczywiście, każdy z nas powie "e no, tak to się nie zawsze da zrobić". Tylko spójrzcie inaczej: czy chcąc zaprosić znajomych na obiad planujemy, że "może to za 2 tygodnie jednak, bo nie zdążę zrobić trzydaniowego obiadu, tortu i domowej nalewki". Przecież tak nie robimy. Dopasowujemy listę dań lub kupujemy coś gotowego. Czy nie da się tej polityki przenieść na grunt naszych też projektów? 

Amy zauważa, że za bardzo skupiamy się na projekcie jako całości. Nie wyznaczamy sobie małych celów, których zrealizowanie pozwoliłoby nam być osiągnąć satysfakcję i motywację do kolejnych działań. Tak bardzo skupiamy się na ogólnej wizji, że w końcu zarzucamy nasz pomysł nie robiąc niczego. Boimy się, że nie jest on wystarczająco fajny, wystarczająco innowacyjny. Czemu nie damy innym szansy tego ocenić? Zostajemy w progach startowych zamiast po prostu biec i zobaczyć gdzie dobiegniemy. Zapominamy, że aby wejść na piętro należy pokonać schody krok po kroku. Stojąc na parterze, zastanawiając czy damy radę wejść niczego nie osiągniemy. Możemy nawet wjechać windą, bylebyśmy to kurwa zrobili. 

Po tej lekturze nie wywrócę swojego życia do góry nogami, nie stanę się nagle innym człowiekiem. Po prostu tym razem spróbuję swoje plany wreszcie kurwa dowieźć. 

Tydzień temu, w wieku prawie 30 lat odebrałem swój pierwszy piłkarski medal. Jest jeszcze nadzieja.