Blog Kokosa

.NET i okolice, wydajność, architektura i wszystko inne

NAVIGATION - SEARCH

Pro .NET Memory Management oficjalnie wydany!

Oficjalnie mogę już ogłosić, że moja książka została opublikowana! Jest dostępna w sprzedaży w różnej formie, na różnych sklepach. M.in. na Amazon czy stronie wydawcy Apress. Więcej szczegółów jest też na mojej dedykowanej stronie. Być zatem nie może, że nie napiszę o tym ważnym wydarzeniu na mojej blogu! Żeby nie czynić tego tekstu nudną ścianą tekstu, proponuję krótkie Q&A. Pytania wymyśliłem sam:)

Dlaczego ta książka jest taka duża?!

To pierwsze pytanie, które może się Wam nasunąć. Na Twitterze wiele osób "śmieszkuje" z jej rozmiaru. Fakt, te ponad 1000 stron i ponad kilogram wagi robi mogą robić pewne wrażenie, nawet na mnie! Nie było moim celem napisanie takiej dużej książki, nie wyznaczałem sobie żadnych celów na tym polu. Ale też żadnych granic. Po prostu chciałem napisać to co wydawało mi się istotne i przydatne w kontekście pamięci w .NET. A że temat jest naprawdę obszerny, gdy się w niego wgłębić, to oto i efekt. Innymi słowy, nawet patrząc na ten kilogram tekstu, nie widzę większych fragmentów, których bym chciał się pozbyć. Może poza paroma drobnymi fragmentami, które bym napisał zwięźlej. Ale to nie zrobiłoby wielkiej różnicy. 

Nakłada się na to jeszcze aspekt samego wydawcy. Początkowo spodziewałem się około 500 stron, ostatecznie skończyłem na 800. Ale w trakcie tych ponad dwóch lat pisania Apress zmienił szablon swoich książek. Na prośby czytelników zwiększył czcionki, trochę marginesy - podobno źle się ludziom czytało drobny maczek. Ja go osobiście lubię ale pola do negocjacji nie było wiele. Książka z dnia na dzień z 800 stron przekształciła się w... 1200 stron. Na szczęście drobne sugestie z mojej strony zredukowały tę liczbę do obecnych 1072!

Osobiście ostatecznie się z tego cieszę. Książka ma przynajmniej jakiś swój, rozpoznawalny charakter :)

Co jest w tej książce, a czego tam nie ma?

Można się spotkać z głosami, że skoro zarządzanie pamięci w .NET jest automatyczne, to o czym tam pisać te tysiąc stron? I tak i nie. Automatyczne zarządzanie pamięcią i Garbage Collector są wygodną dla programisty abstrakcją. Ale jak każda abstrakcja, wcześniej czy później zaczyna ona przeciekać. Programując coś więcej niż projekty na studiach, prędzej czy później, bardziej lub mniej, w końcu zderzamy się z takimi przypadkami. Okazuje się, że warto lepiej zrozumieć jak coś działa i jak tego używać - nawet jeśli jest "automatyczne". 

Poza tym, "zarządzanie pamięcią" to nie tylko GC. W książce opisuję pojęcia finalizacji, po co jest IDisposable, po co są struktury. Co się ostatnio w C# zadziało na tym polu. Po co jest i jak działa Span<T>.

Co więcej, jedną z głównych moich ambicji wobec tej książki było nie tylko opisanie jak coś działa, ale również dlaczego zostało tak zaprojektowane. Ta książka ma dać Wam poczucie, że rozumiecie nie tylko .NET GC ale każdy inny napotkany potem GC będzie również dla Was łatwiejszy do zrozumienia. 

W książce nie zrealizowałem natomiast jednej z moich pierwotnych ambicji - obszernego porównania .NET GC z innymi GC. I dobrze. To zbyt obszerny temat i do tego niezbyt praktyczny dla programisty .NET. Jest to fajny temat na osobną książkę hmm.... Pierwotnie też, będąc m.in. pod wrażeniem książki The Garbage Collection Handbook i jej akademickiego "sznytu", sam chciałem zawrzeć dużo więcej teorii u siebie. Pierwotnie wręcz książka była podzielona na część "teoretyczną" (co i jak z GC) i "praktyczną" (implementacja w .NET). Ale nijak mi się to nie spinało. Pierwsza część byłaby nudna i niepraktyczna, a jednak wymagana do zrozumienia części drugiej. Ostatecznie więc gdzieś się one przenikają w każdym rozdziale (przy znacznym uszczupleniu części teoretycznej). I też dobrze!

Czemu od czerwcowego wpisu o napisaniu książki, dopiero teraz trafia ona do odbiorców?

Jak widać prace teoretycznie skończyłem już w czerwcu [http://blog.kokosa.net/post/jak-idzie-pisanie-czyli-co-to-znaczy-100] więc skąd takie opóźnienie?! Otóż samo napisanie tekstu to jedno, ale potem przerzucenie go przez tryby recenzji, poprawek i zatwierdzania - to drugie. Teoretycznie czas ten nie wymagał z mojej strony wiele pracy, z wyjątkiem kilku okresów bardzo intensywnego "zatwierdzania". Jednak jeśli dodać do tego tworzenie stron, marketing i inne sprawy formalne - nadal tak naprawdę "pracowałem nad książką". 

Jak wyglądał proces pisania, ile to zajęło? Jak wybrałem wydawcę? Czemu nie self-publishing? Ile zarobiłem?!

Są to wszystko świetne pytania. Na tyle, że planuję większy post-retrospektywę na ten temat. Z niego dowiecie się wszelkich szczegółów jak to u mnie wyglądało. 

--

A może Wy macie jakieś pytania? Na wszystkie chętnie odpowiem. Szczególnie na te związane z procesem wytwórczym, na które odpowiem we wspomnianym dedykowanym poście. Czekam też na pierwsze recenzje na Amazon albo Goodreads (najlepiej pozytywne)!

Niedzielnik Kokosa czyli Azure Logic Apps i Azure Functions

Właściwie odkąd założyłem bloga, chodził za mną temat zautomatyzowanych, cotygodniowych postów dotyczących najciekawszych treści, na które natknąłem się danego tygodnia w Internecie. Nadałem temu nazwę “Niedzielnik Kokosa” bo postanowiłem publikować je w niedzielę rano – doskonały moment na spokojne przejrzenie ciekawych treści. Ponieważ na co dzień mam zwyczaj odkładania ciekawych linków do Instapaper – źródło danych mam gotowe. Pozostawała tylko kwestia automatyzacji. Dość długo czaiłem się na serwisy pokroju IFTTT albo Zapier. Jednak z każdą kolejną próbą odbijałem się od nich, ponieważ potrzebna mi automatyzacja (choć prosta) nie wpisywała mi się w to co te serwisy oferują.

To czego potrzebuję to następującą sekwencję zdarzeń (wykonywaną cyklicznie, np. rano co niedzielę):

  1. Pobierz z mojego konta Instapaper linki zapamiętane przeze mnie w ciągu ostatnich 7 dni – maksymalnie 10
  2. Opublikuj na blogu post zgodnie z pewnym szablonem, wypisującym te linki
  3. Opublikuj na Twitterze i stronie Facebooka informację o nowym poście
  4. Idealnie – poinformuj mnie mailem, że się udało

Funkcjonalność taką udało mi się w bardzo przyjemny i szybki sposób zaimplementować ostatnio za pomocą kombinacji dwóch świetnych usług Azure: Więcej...

Tajemnice CLR - jak działa GetType()

Wstęp: Jeśli jeszcze nie bywacie na devspl.slack.com to zdecydowanie polecam. Z obecnie istniejących tam 175 kanałów na pewno wybierzecie coś dla siebie. Ja zaglądam regularnie na kilka, w tym na kanał #dotnet. A tam czasem pojawiają się naprawdę ciekawe pytania! Co najmniej dwa zainspirowały mnie na tyle, że postanowiłem zainicjować nową serię pt. Tajemnice CLR. Odpowiedzi na ciekawe pytania i rozterki, na jakie się natknę. Jeśli macie pomysły - pytajcie! Czy to tu, czy na wspomnianym Slacku. Wchodzić z odpowiedziami będziemy głęboko, nie będzie tu żadnego ciu ciu babciu.

Dziś pierwsze pytanie, które zadała Angelika Piątkowska:

Jak tak naprawdę działa GetType()?

Rozszerzając to pytanie: Skąd obiekt wie jakiego jest typu? Czy to wie kompilator czy runtime? Jak się do tego ma CLR? Czy z faktu, że C# jest statycznie i silnie typowany wynika, że wywołania metody GetType() tak naprawdę nie istnieją i kompilator może je zastąpić odpowiednim wynikiem już w trakcie kompilacji? Więcej...

.NET Core - kompilacja, uruchomienie, debuggowanie

Dziś chciałbym Was przeprowadzić przez proces skompilowania, uruchomienia i debuggowania .NET Core - czyli wersji open source środowiska .NET. Bez zbędnych wstępów przejdźmy do odpowiedzi na proste pytanie...

Po co?

Żeby bawić się, żeby bawić się, żeby bawić się na całego. Mamy źródła .NETa! Po co nam je kompilować? Żeby grzebać, zmieniać, analizować, psuć - aż w końcu wynajdziemy dla siebie miejsce na Pull Request i zapiszemy się w Hall Of Fame, a nasz kod powędruje na miliony komputerów na całym świecie!

A nawet jeśli nie mamy tak ambitnych planów, czy nie fajnie popatrzeć "do środka", jak działa .NET? Oczywiście CoreCLR to nie jest kod komercyjnego .NETa jeden-do-jednego. Ale zdecydowana większość trzewiów jest taka sama, więc jest się czym bawić. Na stronie .NET foundation mówią wprost:

.NET Core has two major components. It includes a small runtime that is built from the same codebase as the .NET Framework CLR. The .NET Core runtime includes the same GC and JIT (RyuJIT), but doesn’t include features like Application Domains or Code Access Security. (...)

.NET Core also includes the base class libraries. These libraries are largely the same code as the .NET Framework class libraries, but have been factored (removal of dependencies) to enable us to ship a smaller set of libraries.

Jeśli zatem coś nas pociąga w spojrzeniu w kod frameworka, którego używamy od lat, mamy ku temu okazję. Więcej...