Maciej Aniserowicz's Blog, page 28

December 11, 2018

163 459,01 zł, czyli listopad 2018. Podsumowanie i raport finansowy.

Na swoim profilu na Patronite obiecałem publikować co miesiąc “raport finansowy”. Dodatkowo zamieszczam podsumowanie tego, co działo się w imperium devstyle w ostatnim miesiącu. Pokazuję… wszystko. Bez tajemnic. Enjoy!


Listopad to “przytup” na koniec tego ciężkiego roku. Przytup, bo wydarzyło się bardzo dużo. Ciężkiego, bo… bo wiadomo, pisałem o tym praktycznie co miesiąc w tych podsumowaniach :).


Na początek wystartowała sprzedaż mojego Kursu Gita. 5-dniowe okienko po pół roku walki ze światem i sobą samym. Mega zainteresowanie, ogromna satysfakcja, świetny zysk i… wielkie wyczerpanie. A dlaczego “tylko 5 dni”? To pytanie dostawałem bardzo często. I odpowiedziałem, bez ściemy:



Wynik finansowy widać na poniższym wykresie (jest nawet lepiej niż w świetnej przedsprzedaży!). Ale nie to cieszy najbardziej.


Najbardziej cieszą… zwroty kursu! Zachęcałem do kupna informując o możliwości odzyskania pieniędzy w 14 dni od zakupu. Czytałem, że “industry standard” to 5-13% zwrotów. A u mnie? Nocusz…

Sprzedałem ponad 2200 egzemplarzy. Wróciły… uwaga… trzy! Co daje współczynnik zwrotów na poziomie półtora promila!

Jedna osoba nie wiedziała, że to “tylko online”. Druga posiadała już całą wiedzę zawartą w kursie, ale czeka na kolejne, a ten poleca innym. Trzecia nie ma czasu na obejrzenie. Zero pretensji, wszystko fair. Dałem z siebie wszystko i… i to widać.


Psst! Teraz, świątecznie i Mikołajowo, znowu na chwilę otworzyłem dostęp do kursu. Bez wielkiej promocji, pompy i marketingu. Informację wysyłam tylko na maila podanego na stronie kursu. Zainteresowanych zapraszam tam, bo kolejne otwarcie dopiero za kilka miesięcy. Teraz już nie kupujesz kota w worku, bo wszyscy zadowoleni :).


Właśnie to mnie raduje NAJbardziej. Że Uczestnicy są naprawdę bardzo zadowoleni.



Potem było devstyle speakers. Ojej, co tam się działo! Po prostu magia.

Relacja na devstyle jeszcze się pisze, ale można już znaleźć sporo ich w internecie. Stay tuned!



I na koniec kolejna wielka inicjatywa, czyli Drugi Sezon DevTalk Trio!

Bardzo się cieszę, że po raz kolejny udało się zabukować na calutki dzień Sławka i Andrzeja. Dzięki, Panowie!

Dziękuję też za wsparcie firmie Lingaro, bez których to by się nie odbyło.



Uff… No i to tyle.


Teraz, w grudniu, zajmuję się głównie ładowaniem bateryjek. Wiecie: Twin Peaks, StarCraft i Problem Trzech Ciał. Idealnie!


No i przechodzimy dalej :). Czas na kasę.


Raport finansowy: przychody

Założenia:



pieniądze wpływające na konto w bieżącym miesiącu; usługa mogła być zrealizowana w innym terminie
kwoty to faktury netto (chyba, że zaznaczono inaczej)

Pozycje:



konsultacje: 3 200 zł
Patronite: 819,63 zł
książka “Zawód: Programista”: 4 310,40 zł
 •  0 comments  •  flag
Share on Twitter
Published on December 11, 2018 21:55

December 9, 2018

DevTalk #84 – O Javie z Jakubem Kubryńskim

kuba_kubrynskiHello! Przed Wami 84. już odcinek podcasta DevTalk! Zaczynamy piąty sezon :). Gotowi??


Dzisiaj temat, którego ewidentnie brakuje w DevTalkowym Spisie Treści. Java! Popularna, kochana, nienawidzona, potężna, skomplikowana, jedyna w swoim rodzaju. Na 1. miejscu w rankingu Tiobe. Zrodzona przez Suna, adoptowana (czy “wrogo przejęta”? ;) ) przez Oracle’a, otoczona mitami i legendami…


A dlaczego jej nie jeszcze tu nie było? Bo czekała na Tego Wyjątkowego Gościa!.


Moim i Waszym Gościem jest dzisiaj Jakub Kubryński! Jakub podczas swojej kilkunastoletniej kariery pracował jako programista, architekt, lider zespołu oraz manager. Zdobywał doświadczenie po obu stronach procesu wytwórczego, będąc zarówno klientem, jak i dostawcą. Teraz realizuje się jako współzałożyciel platformy oceny kompetencji programistów – Devskiller.com, a także prelegent, konsultant i trener. Aktywny uczestnik wielu projektów open-source. Członek komitetu programowego konferencji Devoxx Poland. Na Twitterze: @jkubrynski.


Niczym u Hitchcocka, zaczynamy piąty sezon trzęsieniem ziemi, tylko po to, żeby napięcie mogło powoli wzrastać. Dla mnie rozmowa z Jakubem była mega inspirująca i ciekawa. Java to język z długą i burzliwą historią, kochany przez wielu, tak samo nienawidzony.


Zapraszamy!


Czekam na Twoje gwiazdki i opinie na iTunes! To bardzo motywuje :). Dzięki!


I… PLAY!!







http://traffic.libsyn.com/devtalk/DevTalk_E84-Jakub_Kubrynski_o_Javie.mp3
Montaż odcinka: Krzysztof Śmigiel.

Ważne adresy:


zapisz się na newsletter


zasubskrybuj w iTunes, Spotify lub przez RSS


ściągnij odcinek w mp3


zostań Patronem! :)

Linki:



Blog Jakuba

https://www.facebook.com/JakubKubrynskiBlog/
https://kubrynski.blog/


Twitter
Bottega IT minds
Devskiller
Spring framework
Spring cloud
Hibernate ORM
Biblioteki do testów

Spock
jUnit


Narzędzia do buildów

Maven
Gradle


IDE

Netbeans
Eclipse
IntelliJ IDEA


Konferencja Boiling Frogs (Wrocław)


Muzyka wykorzystana w intro:

“Misuse” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 3.0

http://creativecommons.org/licenses/by/3.0/

The post DevTalk #84 – O Javie z Jakubem Kubryńskim appeared first on devstyle.pl.

 •  0 comments  •  flag
Share on Twitter
Published on December 09, 2018 20:55

December 3, 2018

Serializacja w pięciu smakach

Serializacja jest jak kurczak (albo tofu, albo wołowina). Zależnie od tego, jakich przypraw narzędzi do niej użyjemy, możemy otrzymać danie zjadliwe, smaczne albo istne dzieło sztuki.


Czego możemy zatem użyć, aby uczynić z serializacji magnum opus sztuki transformacji struktur do zapisu binarnego/tekstowego? Jak możemy uzyskać trzy gwiazdki Michelin w kategorii serializacji danych? O tym w poniższym tekście.


Gorzko-gorzki XML





I tak nie użyję.
Czy to lata 90.?



Każdy, kto pamięta mikroserwisy w wersji 1.0, czyli Service Oriented Architecture i standardy WS*, a więc tzw. Gwiazdę Śmierci, zna dokładnie format XML i wszystkie jego zalety (albo ich brak). Format ten stał się na tyle popularny, że zagościł także w dużej liczbie narzędzi developerskich (pliki projektów, pliki konfiguracji) czy też różnego rodzaju standardów (np. Open Office).


XML sam w sobie jest po prostu standardem zapisu danych.



Tak, jest redundantny (tag zamykający musi mieć tę samą nazwę co tag otwierający).
Tak, jest opasły ze względu na swoje redundancję, typowanie oraz przestrzenie nazw (namespace’y).
Tak, jest zapisywany w postaci odczytywalnej przez człowieka (ang. human readable).

Tę ostatnią cechę osobiście uważam za całkowicie zbędną i nie postrzegam jej jako zalety. Dane, także te serializowane, są przesyłane i przetwarzane przez maszyny. Odczyt przez człowieka odbywa się tylko w specjalnych przypadkach i może być wspomagany przez zewnętrzne narzędzie.


Czy powyższe cechy to wszystkie wykroczenia, jakie popełnił XML przeciwko zdrowiu psychicznemu tysięcy deweloperów? Z całą pewnością nie. Co zatem jest w moim mniemaniu jego największą wadą?


Największą wadą związaną z XML-em są według mnie zaniechania dotyczące prędkości przetwarzania. Weźmy pod lupę środowisko .NET Framework. Klasy związane z przetwarzaniem XML-a przez kilka dobrych lat były niezmieniane albo zmieniane w stopniu nieznacznym. Dodatkowo, biorąc pod uwagę, że część API jednej z chmur publicznych – Azure’a – używa właśnie tego formatu do przesyłania danych, nietrudno będzie znaleźć miejsca, w których da się przesyłać dane do chmury i z chmury w sposób sprawniejszy.


Jeśli ciekawi Cię, co można zrobić, aby przetwarzać dane w nieco sprawniejszy sposób, zachęcam do spojrzenia na mój projekt OSS o nazwie QueueBatch. Poza dostarczeniem obsługi batchy dla funkcji Azure’owych używających Azure Storage Queues ma też zaimplementowany niezwykle szybki parser XML-owych odpowiedzi Azure’a. Po stronie klienta jest do 20 razy szybszy od SDK dla usług Azure Storage. Oczywiście czasu odpowiedzi samych serwisów nie zmieni, ale i tak może pozytywnie wpłynąć na koszty związane z uruchamianiem funkcji.


Zerknij na mój projekt QueueBatch i zobacz jak sprawniej przetwarzać dane!


Mam cichą nadzieję, że XML i jego obsługa, ze względu na widoczny w .NET Core ruch zorientowania na wydajność, otrzyma odpowiednie wsparcie i znów jako developerzy będziemy mogli po prostu zaktualizować wersję Frameworka, na której uruchamiamy nasze aplikacje, i cieszyć się lepszą wydajnością za darmo.


Jeśli miałbym opisać smak naszej serializacji po przyprawieniu jej XML-em, powiedziałbym: gorzko-gorzki.


Kwaśny JSON


{ "isSour" : true }


JSON, czyli XML dwudziestego pierwszego wieku. Wraz z drugą falą mody na usługi nazwaną dumnie mikroserwisami zmienił się format przesyłania danych. JSON, będący znacznie lżejszą alternatywą, nadawał się do tego bardzo dobrze. Poza komunikacją pomiędzy usługami pojawiły się też bazy danych wspierające go w zintegrowany sposób.


Przykładem mogą być:



MongoDB – dokumentowa baza przechowująca obiekty/dokumenty w postaci JSON-a,
RavenDB – kolejna baza dokumentowa operująca na podobnej podstawie co MongoDB (dokumenty = JSON),
PostgreSQL – relacyjna baza danych posiadająca niezwykle wydajne wsparcie JSON-a poprzez wbudowany typ JSONB,
Cosmos DB – nowa baza oferowana przez Azure, dostarczająca niesamowity silnik indeksujący (zachęcam do przeczytania dokumentu: Schema Agnostic Indexing).

Poza bazami warto napomknąć o rynku bibliotek obsługujących ten format serializacji. Praktycznie dla każdej platformy/języka znajdziemy kilka, jeśli nie kilkanaście alternatyw obsługujących ten sam format. Różnice pomiędzy nimi występują na poziomie zarówno obsługiwanego wejścia/wyjścia, jak i dostarczanych funkcji (np. API do obsługi dowolnych obiektów JSON bez podania silnego typu, à la JavaScript).


JSON – XML XXI wieku


Przykładami bibliotek stworzonych dla .NET Framework mogą być:



JSON.NET – nieśmiertelny serializator używany praktycznie w każdym projekcie. Poza dostarczeniem silnie typowanego API posiada też odpowiednik dynamicznego podejścia do JSON-a dostępny poprzez klasy JX, np. JToken, JObject itp.,
Jil – niezwykle wydajny serializator stworzony przez jednego z pracowników StackOverflow,
Utf8Json – jeszcze wydajniejszy serializator, zapisujący dane w postaci napisu enkodowanego do byte’ów UTF-8 za jednym razem, bez potrzeby wtórnej transformacji danych.

Jeżeli chodzi o wydajność, ze względu na używanie formatu czytelnego dla człowieka ponosimy pewien koszt. Zdecydowanie mniejszy niż w przypadku XML-a, ale cały czas niezaniedbywalny.


Ostatnią nieodłączną kwestią związaną z serializacją jest aspekt wersjonowania kontraktów czy kompatybilności wstecznej. Niestety, często odpowiedzią na wspomnienie tych kwestii będzie cisza, „u mnie działa” lub „to wersja beta”. Taki mamy (mikroserwisowy) klimat.


Podsumowując, mimo że JSON potrafi uszczypnąć w język, na pewno warto mieć go w palecie smaków.


Słodko-kwaśny – Message Pack


{"compact" : true, "schema" : 0} // JSON

82 A7 compact C3 A7 schema 00 // odpowiadający mu Message Pack


Twórcy Message Pack opisują go w następujący sposób: It’s like JSON, but fast and small. Faktycznie Message Pack może opisać i zapisać dowolne typy obiektów à la JSON. Dodatkowo jest to format binarny, który pozwala na gęstszy zapis danych. Ze względu na to, że nie posiada schematu, nazwy pól czy właściwości dalej są zapisywane do danych wyjściowych, podobnie jak w JSON-ie. Oznacza to też, że odbiorca nie potrzebuje schematu, aby odczytać dane (zrozumienie, co oznacza dane pole, to osobny aspekt).


Wsparcie – podobnie jak w przypadku JSON-a – znajdziemy na każdej platformie. Oznacza to, że – podobnie jak JSON – jest to dobre narzędzie do komunikacji pomiędzy platformami.


Z uwagi na wydajność odnajdujemy w nim zdecydowanie słodką nutę. Ze względu na brak schematu i zawieranie wszystkich informacji w każdym zapisanym obiekcie pozostawia kwaśny posmak.


Wytrawny – Google Protocol Buffers


message Person {
string name = 1;
int32 age = 2;
string email_address = 3;
}

Zdefiniowany przez twórców najpopularniejszej wyszukiwarki format Google Protocol Buffers to nieco inna (potencjalnie wyższa) liga od wcześniej prezentowanych smaków.


Pierwszą cechą, która odróżnia ten format od poprzedników, jest to, że bez znajomości schematu nie jesteśmy w stanie odczytać całkowicie zserializowanych danych. Owszem, da się odczytać pojedyncze pole, jeżeli nie znajduje się w zagnieżdżonym obiekcie, lecz do poprawnej pracy z tym protokołem potrzebujemy schematu.


Dodatkowo ze względu na zewnętrzny schemat i brak potrzeby każdorazowego zapisywania nazw pól poszczególne pola wiadomości zapisywane są razem z tagami. Tagi to całkowitoliczbowe znaczniki będące referencjami do wspomnianego wcześniej zewnętrznego schematu. To właśnie dzięki schematowi można przetłumaczyć np. tag „1” na nazwę pola „Name”, a tag „3” na nazwę pola „EmailAddress”. Protokoły Google’a doczekały się trzeciej wersji, która usunęła niezbyt często używane funkcje serializatora i dodała nowe, takie jak np. dyskryminowana unia pod postacią słowa „oneOf”.


Przez to, że Google Protocol Buffers przechowują schemat – w tym nazwy pól – poza serializowanymi obiektami, oraz to, że używają do zapisu formy binarnej, są bardziej wydajne niż wcześniej wspomniane protokoły. Po prostu mają do wykonania zdecydowanie mniej pracy, zapisując mniej danych.


Biorąc pod uwagę powyższe cechy, włączając w to potrzebę zarządzania schematami (przechowywanie i publikowanie w zewnętrznym medium) oraz bardzo dobrą wydajność, z całą pewnością można mówić o wytrawnym smaku google’owskich protokołów.


Umami – Twój własny format

Jeśli programujesz, to jest wielce prawdopodobne, że masz na swoim koncie własny format serializacji. Chociaż jeden. Za każdym razem, kiedy decydujemy się na zapisanie czegoś w jakiejś formie, jest to ostatecznie serializacja.


Na swojej drodze widziałem wiele:



pipe-serialization – używanie „|” do oddzielenia pól,
offset serialization – „od 15 znaku w imieniu umieszczamy imię ojca”,
pisanie własnego serializatora, który ściga się z innymi – oops, akurat tego jestem winien sam, patrz: Enzyme.

O ile smak Twojej własnej serializacji jest ciekawy (wszak to umami), o tyle wychodzenie poza znane standardy może spowodować późniejsze problemy. Dlatego zawsze podczas decydowania się, jak zapisać dane, w pierwszym kroku zachęcam do przejrzenia tego, co jest już dostępne i zestandaryzowane.


Dopiero potem rozważanie różnego rodzaju eksperymentów. Pamiętajmy, że decyzja o wyborze serializacji zostaje z projektem na bardzo długi czas, a jego zmiana może oznaczać złamanie kompatybilności wstecznej.


Podsumowanie

Mam nadzieję, że powyższa paleta smaków zachęciła Cię do zapoznania się z nimi i zgłębienia różnych formatów serializacji. Wiedza o tym, co można i powinno się wybrać w danym projekcie oraz jak użyć wybranego formatu, może być kluczowa dla wydajnego przetwarzania danych.


Temat jest bardzo interesujący i obszerny. Gorąco zapraszam Cię do zagłębienia się weń jeszcze bardziej! Pod adresem serializuj.pl znajdziesz mój bezpłatny e-book, prowadzący jeszcze głębiej w krainę serializacji.


Kliknij, by przejść na stronę e-booka!


Życzę Ci, aby Twoja praca z różnymi serializatorami dostarczała całej palety smaków, a przygotowane w ten sposób projekty zasługiwały na trzy gwiazdki Michelin.


Do przeczytania kolejnym razem!


The post Serializacja w pięciu smakach appeared first on devstyle.pl.

 •  0 comments  •  flag
Share on Twitter
Published on December 03, 2018 11:59

November 30, 2018

2018 [devstyle vlog #231]


The post 2018 [devstyle vlog #231] appeared first on devstyle.pl.

 •  0 comments  •  flag
Share on Twitter
Published on November 30, 2018 12:42

Nagranie z DevTalk Trio LIVE, sezon 2!

Wczoraj był bardzo (BARDZO) intensywny dzień! A było nas trzech… Sławek Sobótka, Andrzej Krzywda, no i ja.


Najpierw od rana do nocy nagrywaliśmy 13 (słownie: trzynaście!) odcinków podkasta, a potem…


A potem jeszcze 2 godzinny LIVE :). Zapraszamy do obejrzenia nagrania:



Nie obyłoby się bez wsparcia! Na szczęście wsparcie takie znalazłem. Firma Lingaro zdecydowała się wesprzeć nas i zostać Partnerem całej inicjatywy. Bardzo dziękujemy!



A więcej o całej inicjatywie opowiadałem w jednym z odcinków VLOGa:



The post Nagranie z DevTalk Trio LIVE, sezon 2! appeared first on devstyle.pl.

 •  0 comments  •  flag
Share on Twitter
Published on November 30, 2018 03:24

November 28, 2018

November 27, 2018

DevTalk Trio, sezon 2! Zapraszamy!

Ależ się ostatnio dzieje, normalnie SZOK!! Dzisiaj zapraszam Was na coś absolutnie wyjątkowego! :)


Pamiętasz mój podcast DevTalk? A pamiętasz DevTalk Trio?

(swoją drogą, “normalny” DevTalk zaraz wraca na antenę, dzisiaj nagrałem pierwszy odcinek 5. sezonu.)


A TRIO? To wymagało DUŻO przygotowań, ustaleń, logistyki, zasobów i planów. Ale finalnie… SIUP!



Już w najbliższy czwartek, 29 listopada, będę miał zaszczyt gościć dwie kultowe postaci polskiego IT: Sławka Sobótkę i Andrzeja Krzywdę!


Tego dnia będziemy nagrywać X odcinków podcasta, a potem – wieczorkiem, 29.11 o 21:00 – wpadamy na LAJWA. Będzie nas można popytać o najróżniejsze rzeczy związane z programowaniem, technologią, karierą czy ogólnie Branżą IT. Odklikaj się najlepiej już teraz (“set reminder“):



Zrobimy wszystko, by wyszło epicko. Poprzednim razem – półtora roku temu – tak właśnie było ;).


Dołącz też do wydarzenia na Fejsie!


Nie może Cię zabraknąć!

(no dobra, bez Ciebie też zaczniemy, ruszamy punktualnie o 21:00 w czwartek więc nie przegap!)


Tak jak pisałem (i dziś we VLOGu też o tym opowiadam), cała inicjatywa to spore wyzwanie. Nie ma prowizorki, nie ma amatorki, robimy “na wysoki połysk”. Nie obyłoby się bez wsparcia!


Na szczęście wsparcie takie znalazłem. Firma Lingaro zdecydowała się wesprzeć nas i zostać Partnerem całej inicjatywy. Bardzo dziękujemy!



Do zobaczenia w czwartek i usłyszenia w 2019, będzie SZTOS! ;)

Procent, podjarany


P.S. Tutaj strona inicjatywy, tutaj stream live, a tutaj ankieta – możesz nam zadać pytanie zawczasu!


The post DevTalk Trio, sezon 2! Zapraszamy! appeared first on devstyle.pl.

 •  0 comments  •  flag
Share on Twitter
Published on November 27, 2018 04:33

November 26, 2018

DOTYK [devstyle vlog #228]


The post DOTYK [devstyle vlog #228] appeared first on devstyle.pl.

 •  0 comments  •  flag
Share on Twitter
Published on November 26, 2018 11:14

November 24, 2018

Maciej Aniserowicz's Blog

Maciej Aniserowicz
Maciej Aniserowicz isn't a Goodreads Author (yet), but they do have a blog, so here are some recent posts imported from their feed.
Follow Maciej Aniserowicz's blog with rss.