krótki wpis

Nauka uczenia się i rozwijania się część 3 – podcasty

~ Jarosław Stadnicki ~ 3 Comments

Oskar i Kokos zebrali w swoich postach całkiem sporo materiału na temat skąd i jak można czerpać wiedzę i o tym jak się uczyć. Ich wpisy można znaleźć:

Oskar: Nauka uczenia (się)
Kokos: Jak się rozwijać?

Ja dodam od siebie jeszcze jedną rzecz, która nie została wcześniej wymieniona, a moim zdaniem daje sporo. To podcasty. Słuchając ich nie tyle uczę się danej technologii, czy jednego słusznego rozwiązania, a raczej dowiaduje się o innych, alternatywnych do codziennej pracy, rozwiązaniach które może kiedyś da się wykorzystać. Moja lista podcastów:

  • .Net rocks – pierwszy podcast którego słuchałem, skupia się wokół .net
  • A moment of science: Audio – krótkie historyjki ze świata technologi i ogólnej wiedzy
  • Being the worst – mam na liście, ale jeszcze nie dotarło do odtwarzania
  • Coding Blocks – techniczny podcast, skupiający się na .net
  • Full Stack Radio – różnie bywa, czasami wywiady z autorami produktów/bibliotek, czasami opowieści o architekturze i programowaniu. Warto posłuchać tych opowieści, mnie zainspirowały do kolejnego wpisu
  • Hanselminutes – sam Hanselmann, kiedyś technicznie, teraz równouprawnienia, szczerze mówiąc od jakiegoś czasu najczęściej przeskakuje, przykro mi Scott
  • Herding Code – technologicznie, różne osoby, różne technologie
  • JavaScript Jabber – javascript
  • Mała Wielka Firma – podcast o budowaniu własnego przedsiębiorstwa, bardzo fajnie i ciekawie opowiadają
  • Radiolab – opowieści, świetnie przygotowane słuchowiska, czasem moralizujące, czasem opowiadające historię leków, czasem po prostu zabawne, przesłuchałem od początku wszystkie
  • TED Radio Hour – TED w radiu
  • ThoughtWorks – opowieści z firmy, liczę że będą kiedyś ciekawe rzeczy

I ile wcześniej słuchałem każdego epizodu z każdego źródła od deski do deski, to teraz mają ich duży wybór pomijam te, które nie są tak bardzo porywające. Zdarza się także, że jedna osoba występuje w różnych wywiadach dla różnych podcastów, a mówi o tym samym, wtedy również szkoda czasu.

Jeśli chodzi o aplikację do podcastów to szczerze polecam Podcast Addict dla androida. Używam od 2 lat I nie zamierzam zmieniać na nic innego.

Zapis i odczyt data-attribute w DOM

~ Jarosław Stadnicki ~ 3 Comments

Czasami trzeba zapisać coś w strukturze DOM, a potem odczytać te dane ponownie. I ponownie zapisać i odczytać i jeszcze raz. Z pomocą przychodzi wtedy nieśmiertelne jQuery. Znajdujemy wtedy interesujący nas element $(element) a następnie przy pomocy metody .data(“…”) odczytujemy wartość, lub .data(“…”,”…..”) zapisujemy wartość. jQuery lubi te dane sobie zapisać w swoim cache. Może się więc okazać, że każdy kolejny odczyt wskazywać będzie zawsze tą wartość, którą odczytaliśmy za pierwszym razem. Co wtedy? Są dwa sposoby; kiedyś udało nam się rozwiązać ten problem korzystając z innej metody, ale też jQuery; mianowicie .attr(“data-….”) i symetrycznie .attr(“data-…”, “…”) do odpisu i zaczytu (literówki!). Czasem i to nie wystarcza i wtedy należy sięgnąć po wanilie i skorzystać z getAttribute(“data-…”) oraz setAttribute(“data-…”,”…”) – te ostatnie zawsze działają. Jeden jedyny minusiczek, to taki: że jest to wyłom w spójności kodu, tzn. jeśli wszędzie używamy jQuery, a gdzieś wanilii, to dla części może to kłuć w oczy.

 

//EDIT (05.03.2016)
Przygotowałem przykład dostępny w jsfiddle jak i w giscie. Wygląda na to, w zmęczeniu przegapiłem pewne zależności lub coś działało jeszcze inaczej. Mianowicie problem z odczytem pojawia się wtedy gdy zapiszemy do data przy pomocy setAttribute a odczytamy za pomocą $.data, lub zapiszemy $.attr i odczytamy $.data. W tych przypadkach dane nie zostaną odświeżone. Sami sprawdźcie. Podziękowania dla @jarekkoziol za bycie ciekawskim.

GIST:

JSFiddle:
https://jsfiddle.net/jstadnicki/ydtry0c9/

Zamień bóla na enuma

~ Jarosław Stadnicki ~ 9 Comments

Dlaczego zamienić? Moim zdaniem czytelniej i jasno sformułowana myśl i łatwiej zrozumieć. Nie chodzi o prosty przypadek, gdzie zamiana polegałaby na zamianie true/false na MyEnum.True/MyEnum.False – nie nie, to byłoby szaleństwem. Ale może od razu do kodu, bo czas nagli dzisiaj.

Pierwszy przypadek, wszystko działa jak należy:

Jakaś tam klasa filtrów, przyjmuje (@3) identyfikator, nazwę i bit, które oznacza że filtr będzie grupą lub nie (w zasadzie nie wiadomo, czym jest nie-grupa)

Teraz wykorzystanie:

Zasadniczo prosty kod, jest jakaś lista filtrów (@5). Następnie dodajemy filtry; pierwsze id, jakaś nazwa i true, potem id, nazwa i false. Osoba nowa w projekcie, lub nowa w tej części kodu na pierwszy rzut oka nie będzie wiedzieć co to oznacza. Następne dwie linijki są trochę bardziej rozgadane, bo jawnie mówią jak interpretować ostatniego bool’a.
Dalej szukamy tylko tych, gdzie IsGroup jest ustawione na true (@12). Jeszcze dalej wołamy metodę, która robi to samo, ale na podstawie parametru wejściowego (@18). Najczęściej gdy się tworzy takie metody nie zwraca się dużej uwagi na nazwę parametru, bo albo to R# wygenerował, a on robi dobrze, albo jest to jedna linijka i nie muszę się nad tym za bardzo skupiać. Rzeczywiście sama metoda jest prosta, trudno się pomylić do czego służy parametr i gdzie go wykorzystać.
Spójrzcie teraz na klienta tej metody, ma przesłać dwa parametry, listę filtrów (to proste), a potem flagę która oznacza group – group co?! Trzeba zajrzeć do ciała metody, żeby sprawdzić co oznacza ten parametr i jak mam go wykorzystać. Można też poprawić nazwę parametru lub (czuję obrzyd jak to piszę) napisać dokumentacja.

A co gdyby napisać kod w taki sposób:

Na scenę wchodzi tajemniczy FilterType:

Jak widać, tajemniczy bohater to enum, które jawnie definiuje jakiego rodzaju może być filtr:

  • 0 – nie został określony, nikt nie wie, nikt nie słyszał. Jeśli w ten sposób został zainicjalizowany, to najprawdopodobniej nie zostanie nigdy wykorzystany
  • 1- Typ grupowy
  • 2- Typ pojedynczy (aha, teraz to trochę jaśniejsze)

Prosty klient klasy Filtr, może wyglądać jakoś tak:

Na początku ponownie tworzymy listę, tym razem nie trzeba zgadywać co oznacza true/false. Nie trzeba także uciekać się do używania nazwanych parametrów aby rozjaśnić intencje.
Następnie gdy wybieramy z kolekcji filtry (@12), znowu w jasny sposób mówimy o typie, który nas interesuje. I wreszcie na koniec metoda filtrująca (@18) także w jawny sposób definiuje parametry których wymaga do działania.

Co jeszcze dobrego płynie z przyjęcia enuma? Jeśli pojawi się nowy rodzaj, nie trzeba będzie wprowadzać kolejnego bool’a który będzie mówić, czy filtr jest czy nie jest danego rodzaju. Domyślnie filtr jest nie znanego typu, więc wszystkie podczas poszukiwać za grupowym/pojedynczym takie znaleziska się nie pojawią. Nawet gdy nazwa parametru będzie do bani, sam tym parametru sprzeda intencje programisty i użytkownik metody (@18) będzie wiedzieć jakiego rodzaju wartość ma przesłać, aby otrzymać interesująco go wynik.

I jeszcze na koniec: oczywiście że ciężko tworzyć enum’y do każdego wykorzystania bool’a. Równie ciężko jest pisać kod który działa i jest czytelny, bezbłędny czy zoptymalizowany – a jednak każdy się stara.

Miłego wieczoru!

Nie bój się powiedzieć: nie wiem

~ Jarosław Stadnicki ~ Leave a comment

Pomyślcie sobie gdy idziecie do lekarza i strasznie was coś boli. Macie wizytę, doktor bada i opukuje i finał finałów: chcielibyście dostać informacje że lekarz nie wie i zaleca wizytę u specjalisty, czy lepiej żebyście dostali witaminę C, podczas gdy np. wasze oko wygląda jak u osób zarażonych wirusem H1Z1? Ja wybieram opcje 1. Oszczędzam swój czas, swoją nadzieję że to co dostałem mnie wyleczy i oszczędzam reputację lekarza u którego byłem, bo na pewno wrażeniami z leczenia podzielę się z innymi.
Ostatnio powiedziałem: “nie wiem, nie mogę tego zrobić, to jest poza moim poziomem wiedzy” – i wiecie co, świat się nie skończył. Zadanie dotyczyło wyznaczania jakichś standardów technicznych w miejscu gdzie pracuje. Oczywiście mogłem dorzucić swoje trzy grosze, ale pomyślałem że lepiej nie wtykać nosa tam gdzie nie mam nic mądrego do powiedzenia. Gdybym się wymądrzał, mówił rzeczy które mogą nie mieć sensu, kręcił, etc. wtedy robota którą miałem dostarczyć byłaby nie fajna. Standardy, które wyznaczyłem byłyby nie fajne. wrażenia innych  po przeczytaniu standardów byłyby nie fajne.
Jasne, każdy z nas chciałbym zrobić coś ciekawego i ważnego – ja też. Czasami jednak przychodzi moment, że coś mnie (nas wszystkich) przerasta. Możemy wtedy zrobić dwie rzeczy: wziąć na siebie odpowiedzialność i spierdolić sprawę śpiewająco; budżet, czas, reputacja, nerwy, zdrowie, co tam jeszcze można. Lub! Lub zagrać w otwarte karty: nie dam rady, potrzebuje kogoś innego do pomocy, albo w ogóle się na tym nie znam, musicie znaleźć kogoś innego.
Sami zgadnijcie która postawa jest bardzie pro.
Następnym razem postaram się bardziej technicznie napisać.

Bardzo prost logi w asp mvc

~ Jarosław Stadnicki ~ Leave a comment

Nigdy nie ciągnęło mnie do logowania. Zawsze miałem problem z określeniem poziomu na jaki zasługiwała dana informacja, a może ostrzeżenie. Czy to błąd, czy to już krytyczny błąd. Jak mam to dobrze zalogować. Czemu te okrutne logi tak strasznie mieszają mi się w aplikacje, wtedy jeszcze nie znałem podejścia AO.
Pisanie własnego logera też nigdy nie sprawiało mi przyjemności, zawsze czułem że robię coś nie tak. Jak już poznałem nloga czy log4net i próbowałem go zaprząc do aplikacji, to konfiguracja jednego i drugiego też zawsze szła po gruzie. Summa summarum życie szło powoli, a z logów nie korzystałem i nadal nie najczęściej nie korzystam (czasem żałuje). W projektach dziedziczonych logowanie już jest i wszystko jest już ustawione i postanowione i tak ma być – a że wszyscy referują do logera, to też jest “spoko”. Ale nie o tym miałem pisać. Często się zdarza, że mi tego brakuje i wtedy albo na chwilę dodaje logowanie, a potem usuwam, a potem jak znowu potrzebuje to usuwam, albo zostawiam bo może kiedyś mi się przyda i strasznie mnie to wkurza. Dlatego gdy odkryłem tracing musiałem się tym podzielić. Otóż taram taram – ( dla części z was oczywista oczywistość), w asp.net mvc jest wbudowane proste tracowanie, które spełnia moje podstawowe wymagania i włącza się to niebotycznie prosto.

Wystarczy tyle, żeby móc przejść na stronę myWebApp/trace.axd i móc oglądać szczegóły request’ów, które otrzymuje aplikacja. Jest tam więcej przełączników, które można poznać na internecie, np. na msdn.
Oto co dostajemy za darmoszke:

Faking hel – i to praktycznie za darmo?! Oczywiście możemy dorzucać trochę swojego logowania jeśli trzeba robi się to przez taką linikę kodu:
HttpContext.Trace.Write(“Category”, “Text to log”);
Dodatkowe wpisy znajdą się w sekcji TraceInformation. Dla mnie bóstwo. Włączyć, dodać kilka linijek w kodzie na szybko, sprawdzić i wywalić.
Podobną funkcjonalność można uzyskać przy pomocy Glimpse – też wypas. Jeszcze inna opcja to F12 developers tools w każdej przeglądarce, ale tam nie dostaniemy informacji o stanie serwera. No i tyle, krótko i na temat.