Maciej Aniserowicz's Blog, page 13

October 16, 2019

KIERUNEK [vlog #312]

The post KIERUNEK [vlog #312] appeared first on devstyle.pl.

View more on Maciej Aniserowicz's website »

Like • 0 comments • flag

Published on October 16, 2019 13:59

October 15, 2019

RYTM [vlog #311]

The post RYTM [vlog #311] appeared first on devstyle.pl.

View more on Maciej Aniserowicz's website »

Like • 0 comments • flag

Published on October 15, 2019 14:12

October 14, 2019

TABU po raz kolejny [vlog #310]

The post TABU po raz kolejny [vlog #310] appeared first on devstyle.pl.

View more on Maciej Aniserowicz's website »

Like • 0 comments • flag

Published on October 14, 2019 14:11

October 13, 2019

5 kroków do napisania pierwszej aplikacji we Flutterze

Czy zdarzyło Ci się kiedyś wpaść na pomysł świetnej apki mobilnej, ale brakowało Ci wiedzy, jak ją zrobić? Piszesz aplikacje na Androida albo iOS, ale chciałbyś tworzyć je na OBIE platformy naraz? A może zaczynasz się uczyć programowania i masz już w głowie ciekawe projekty?

Na każdą z tych sytuacji odpowiedzią może być Flutter.

Flutter to nowy framework od Google’a przeznaczony do budowania natywnych aplikacji mobilnych na Androida i iOS ze wspólnego kodu. Używa on innego podejścia niż większość tego typu rozwiązań, gdyż zamiast pracy w WebView lub mapowania elementów na natywne odpowiedniki Flutter sam bierze odpowiedzialność za tworzenie całego UI, wykorzystując natywny Canvas. Mógłbym się tutaj rozwodzić nad zaletami Fluttera, takimi jak hot-reload, niesamowita płynność, łatwość tworzenia layoutów czy pomocne community, ale tego nie zrobię. Zamiast tego pokażę Ci, jak zacząć używać tego narzędzia.

Podzieliłem ten post na pięć kroków, po przejściu których nic nie stanie Ci na drodze do rozpoczęcia przygody z Flutterem:

Zainstaluj Fluttera
Przygotuj środowisko programistyczne
Zapoznaj się z językiem
Zapoznaj się z Widgetami
Twórz piękne apki!

Do dzieła!

Zainstaluj Fluttera

Jak na tutorialowy wpis przystało, wypadałoby, żebym krok po kroku opisał, co musisz zrobić, żeby mieć w pełni zainstalowanego Fluttera. Całe szczęście team odpowiedzialny za ten framework opracował proces instalacji niezwykle czytelnie, więc cokolwiek bym tu napisał, byłoby to niekompletne odwzorowane ich tutoriala.

———> Instalacja krok po kroku

W skrócie:

Wejdź na oficjalną instrukcję instalacji Fluttera.
Wybierz swój system operacyjny (Windows, macOS, Linux).
Pobierz paczkę z Flutterem.
Wypakuj do wybranego przez siebie miejsca.
Dodaj do zmiennej środowiskowej.
Sprawdź poprawność, wykonując komendę flutter doctor w konsoli.

Każdy z tych kroków jest dokładnie opisany we wspomnianej wyżej instrukcji.

View more on Maciej Aniserowicz's website »

Like • 0 comments • flag

Published on October 13, 2019 21:55

October 6, 2019

DevTalk #103 – O Flutterze z Dominikiem Roszkowskim

Cześć! Moja ukochana jesień zadomowiła się na dobre! Niestety częściej wywołuje to chandrę niż zachwyt, ALE… Spokojnie, mam na to remedium. Nic nie rozgrzewa programistycznych serc lepiej niż DevTalk! Zwłaszcza że w sto trzecim odcinku poruszamy szalenie ciekawy temat.

Ladies and Gentlemen, dziś gościmy Dominika Roszkowskiego.

Dominik jest Mobile Developerem, pracuje głównie we Flutterze. Od prawie dwóch lat aktywnie działa w społeczności skupionej wokół tej technologii. W wolnych chwilach organizuje meetup Flutter Warsaw. A teraz petarda. Współprowadzi projekt satelity studenckiego PW-Sat2, który w grudniu 2018 roku trafił na orbitę okołoziemską. Dominik jest pasjonatem programowania, kosmosu i nowinek naukowych.

O co chodzi z Flutterem? Ta technologia jest coraz bardziej popularna. Liczba aplikacji z jej użyciem regularnie rośnie. Flutter zebrał już wokół siebie pokaźnie community skore do pomocy i pokazywania przykładów ze swoich projektów. A dlaczego Ciebie powinno to także zainteresować?

Z dzisiejszej rozmowy z Dominikiem dowiesz się:

Co to jest Flutter?
Historia Fluttera – dlaczego powstał i kto za nim stoi?
Jakie problemy rozwiązuje Flutter?
Dawid i Goliaci: czy Flutter może rywalizować z Xamarinem, React Native i innymi gigantami?
Mroczna strona Fluttera, czyli jakich wad możesz się spodziewać, wybierając tę technologię.

Na sam koniec Dominik wspomina o konferencji, którą współorganizuje. W związku z tym ma dla Ciebie niespodziankę! Pierwsze dziesięć osób, na hasło devtalk103 otrzyma 10% zniżki na wejściówkę na Konferencję Flutter Europe! Miłego słuchania!

PS. Podobał Ci się ten odcinek? Zostaw gwiazdkę i opinię na iTunes! To bardzo motywuje :). Dzięki!

I… PLAY!!

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

Ważne adresy:

zapisz się na newsletter

zasubskrybuj w iTunes, Spotify lub przez RSS

ściągnij odcinek w mp3

Linki:

DevTalk

DevTalk #86 – O Programowaniu Satelity z Alicją Kubera
DevTalk#62 – O Xamarin z Jakubem Jędryszkiem
DevTalk#69 – O Androidzie z Pauliną Szklarską

Dominik

Blog
Twitter @OrestesGaolin
PW-Sat2
Konferencja Flutter Europe

Flutter

Strona Frameworka
Eric Seidel “What is Flutter”
Meetup Flutter Warsaw
Grupa na Facebooku
Slack
Znane aplikacje we Flutterze:

Google Ads

https://apps.apple.com/us/app/google-ads/id1037457231
https://play.google.com/store/apps/details?id=com.google.android.apps.adwords

Reflectly
Abbey Road Studio Topline

https://apps.apple.com/us/app/topline/id1270125833
https://play.google.com/store/apps/details?id=com.abbeyroadandroid&hl=en_US&e=-EnableAppDetailsPageRedesign

Aplikacja zakupowa na Openerze

Dlaczego Flutter jest rewolucyjny
Jak zacząć?

Instalacja
Tutoriale Google Codelabs
Podstawowy tutorial layoutowania

Aplikacje

Xamarin
React Native

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 #103 – O Flutterze z Dominikiem Roszkowskim appeared first on devstyle.pl.

View more on Maciej Aniserowicz's website »

Like • 0 comments • flag

Published on October 06, 2019 20:55

September 30, 2019

Wyciśnij z MSBuilda ostatnie soki

Czym jest MSBuild?

Każdy programista, który używał środowiska .NET, zapewne spotkał się z nazwą MSBuild. Zadaniem tego oprogramowania jest tak poprowadzić proces tworzenia aplikacji, aby ściągnąć potrzebne zależności, zbudować projekty oraz wdrożyć je, gdy o to poprosimy.

Korzystamy z niego podczas kliknięcia Build, Clean lub Rebuild w Visual Studio.

Jednak jak każdy mechanizm ma on ukryte wady, możliwe ścieżki optymalizacji oraz sposoby na rozszerzenie o dodatkowe narzędzia w celu automatyzacji.

Jednocześnie brak znajomości mechanizmów, na które pozwala .NET, może spowodować, że proces wdrażania aplikacji zajmuje lwią część pracy. U klienta proces wdrożenia zmian na środowisko trwa 2 dni robocze, gdyż system wdraża ponad 50 systemów naraz (sic!).

Przejdźmy do mięsa.

Budowanie przyrostowe

Jeden z mechanizmów w MSBuild, który sprawdza, czy projekt został zbudowany. Jeśli sygnatura czasowa zgadza się z poprzednim stanem, to pomija projekt i go nie buduje. Większość problemów jest związana z tym, że manipulujemy plikami przed procesem budowania lub po nim, co powoduje, że mechanizm nie działa tak, jak powinien.

Trzeba mieć jak najwięcej projektów, które wykorzystują ten mechanizm, aby przyspieszyć czas budowania i ponowienia.

Ale jak? Po kolei.

Usuń mechanizmy bezmyślnego kopiowania

Pierwszy mechanizm, który psuje budowanie przyrostowe. Sam w sobie mechanizm kopiowania nie jest zły, ale NIGDY nie nadpisuj plików w folderze wynikowym danej aplikacji, bo naruszysz sygnatury czasowe plików, przez co proces budowania będzie ponawiany za każdym razem.

Przykładowy mechanizm kopiowania plików z folderu content do folderu głównego solucji, który psuje budowanie przyrostowe:

DestinationFiles="@(ContentToCopy->

'$(SolutionDir)\%(RecursiveDir)%(Filename)%(Extension)')" />

oraz poprawiony mechanizm kopiowania:

Include="$(MSBuildProjectDirectory)\content\*.*"

Inputs="@(ContentToCopy)"

Outputs="@(ContentToCopy->

'$(SolutionDir)\%(RecursiveDir)%(Filename)%(Extension)')" />

SourceFiles="@(ContentToCopy)"

DestinationFiles="@(ContentToCopy->

'$(SolutionDir)\%(RecursiveDir)%(Filename)%(Extension)')" />

Zmiana polega na dodaniu właściwości Inputs oraz Outputs. Zlecamy mechanizmowi budowania, aby sprawdził sygnatury czasowe plików w folderach na wejściu i wyjściu przed procesem kopiowania. Jeśli żaden plik nie zmienił się od ostatniego czasu budowania, to zadanie jest pomijane.

Innym sposobem zwiększenia wydajności jest wykorzystanie dysku podczas procesu budowania. Oczywiście im wolniejszy dysk, tym proces budowania jest dłuższy.

Warto jednak mieć na uwadze fakt, że niektóre środowiska, na których budujemy i wdrażamy aplikacje, mogą nie mieć wydajnych mechanizmów kopiowania, działać zdalnie lub najzwyczajniej w świecie trzeba używać protokołów sieciowych.

Klient wykorzystuje dyski sieciowe bazujące na HDD, przez co transfer jest średnio 10 razy wolniejszy niż na maszynach deweloperskich. Znaczną część procesu budowania i wdrażania zajmuje kopiowanie plików między systemami a środowiskami.

Jednak można to zoptymalizować.

Hard linki

Podczas budowania możemy wykorzystać mechanizm optymalizujący proces kopiowania plików. Ustawione flagi przenoszą pliki do bufora RAM-u i z niego wykonują proces zapisu i odczytu plików.

Proces jest skalowalny w zależności od ilości RAM-u na maszynie oraz plików współdzielonych między projektami. Przykładowo: u klienta udało się zejść z 135 MB/s do 10 MB/s zapisu/odczytu na wątek.

W celu wykorzystania tego rozwiązania w MSBuild.exe (lub odpowiednika, który go odpali) trzeba dodać właściwości:

MSBuild.exe /p:

CreateHardLinksForCopyLocalIfPossible=true;

CreateHardLinksForCopyFilesToOutputDirectoryIfPossible=true;

CreateHardLinksForCopyAdditionalFilesIfPossible=true;

CreateHardLinksForPublishFilesIfPossible=true;

Współdzielone foldery

Przy wykorzystaniu poprzedniej wskazówki będzie to ogromna optymalizacja. Jednak nigdy nie wykorzystuj folderu współdzielonego między aplikacjami na aplikacje wynikowe!

Każde nadpisanie pliku powoduje wyłączenie budowania przyrostowego. Wspólny odczyt? Tak! Wspólny zapis? Nie! Koniec kropka.

Skrypty budujące

Tutaj nie ma zaskoczenia – Visual Studio, Visual Studio Code czy Rider nie nadają się do budowania ogromnych solucji w .NET, więc zadania powinny być wykonywane z linii poleceń.

Ciekawostka: odpalenie 450 projektów w Visual Studio kończy się zawieszeniem systemu oraz błędem krytycznym VS.

Ogranicz informacje zwrotne

Zasada jest prosta: im mniej informacji zwrotnych, które MSBuild musi nam przekazać, tym wydajniejszy proces budowania.

Standardowo wystarczą nam informacje o błędach:

MSBuild.exe /clp:ErrorsOnly

Wykorzystaj nowy format projektów i silnik .NET Core.

Biblioteki, aplikacje windowsowe czy aplikacje konsolowe można zmigrować do nowego formatu. Obecnie ASP.NET jest z tego procesu wyłączony, ale najprawdopodobniej dołączy do tego grona w momencie opublikowania .NET 5.

Nowy format:

net472

.NET Standard oraz .NET Core są na nim zaimplementowane.

Powody są dwa. PackageReference i zbiorowe repozytorium, w którym przetrzymywane są paczki NuGet. Proces ściągania, rozwiązywania zależności i budowania w nowym formacie jest piekielnie szybki w porównaniu ze starym systemem.

Wyniki bazują na projektach kolejno dla 4 i 512 projektów w danej solucji.

Ciekawostka: u klienta dla 450 projektów czas budowania przyrostowego zmalał z 9 minut do 44 sekund (miks starego i nowego formatu, jednak to nie ostatnie słowo!).

Zbiorowe ściąganie paczek NuGet

Proces ściągania paczek NuGet jest równoległy, więc jeśli budujesz wiele solucji naraz, to ściąganie tej samej paczki spowoduje zablokowanie procesu budowania całego rozwiązania.

Jednym ze sposobów jest generowanie tymczasowej solucji, której zadaniem jest indeksowanie projektów i ściąganie paczek.

Idąc dalej tym tokiem myślenia, zamiast wykorzystywać domyślną ścieżkę w starym formacie projektu, można stworzyć plik nuget.config, w którym dodamy klucz repositoryPath:

value="%userprofile%\.nuget\OldFormatPackages" />

Dzięki takiemu zabiegowi stary oraz nowy format będą korzystać z folderu .nuget i pozwoli to zaoszczędzić czas rozwiązywania zależności w obu formatach. Co więcej, hard linking pokaże tutaj swój potencjał optymalizacyjny.

Jeden aspekt. Co z tą ścieżką jest nie tak?

Gdy wskażemy relatywną ścieżkę do zależności to każdy deweloper w zespole musi mieć taką samą ilość kroków do folderu(na przykład, 5 folderów do tyłu i 3 do przodu).

Ścieżka absolutna? Każdy deweloper musi posiadać ten sam folder na swojej maszynie, więc warto o tym pamiętać.

Wykorzystaj lokalne repozytoria

Osobiście poszedłem dalej i nie korzystam w projektach ze źródeł takich jak nuget.org, offline i innych repozytoriów dostarczonych przez Microsoft jako domyślnych dla .NET poza… ściągnięciem potrzebnych paczek do lokalnego repozytorium.

Sprawa jest prosta – odczyt z dysku SSD jest szybszy niż z sieci, dodatkowo można pracować offline, mając dostęp do lokalnego serwera NuGet.

Takie samo rozwiązanie wykorzystuje mój klient. Posiada repozytorium lokalne (per maszyna) oraz firmowe.

Plusy są dwa.

Bezpieczeństwo, bo nie ma ruchu sieciowego na maszynach budujących, oraz wydajność ze względu na systemy bezpieczeństwa, które w czasie rzeczywistym monitorują ruch sieciowy. Przez to ściąganie paczek jest bardzo wolne i system bezpieczeństwa może zablokować akcję, jeśli wykryje podejrzany plik, a to spowoduje zatrzymanie całej machiny.

Stwórz wyjątki dla antywirusa

Każdy proces i folder, który służy do stworzenia aplikacji, powinien być wyłączony ze sprawdzania przez antywirus.

Procesy do białej listy:

node.exe
msbuild.exe
code.exe
dotnet.exe
devenv.exe
ServiceHub.Host.Node.x86.exe

Można wykluczyć procesy jako proces (nazwa.[rozszerzenie]) lub jako ścieżkę do procesu z procesem. Polecam drugie podejście ze względu na możliwy wektor ataku. Przy instalacji Visual Studio, Visual Studio Code, .NET Core SDK znajdziemy w folderach powyższe procesy.

Wykorzystaj równoległe budowanie

Kwintesencja optymalizacji – wiele projektów można budować równolegle. Kilka wskazówek, aby proces był szybki i nie blokował sam siebie:

Zawsze zapisuj (kopiuj) do pustego i unikatowego folderu.
Zmniejsz liczbę zależności między projektami do minimum.
Korzystaj z hard linking oraz wspólnych folderów do odczytu.
Ściągaj zbiorowo paczki NuGet, aby nie zablokować procesu.

Dlaczego kopiujemy do pustego folderu? Uprawnienia i nałożona flaga readonly. Często gęsto zdarza się, że plik zostanie zablokowany przez inny proces lub przez system, bo system budowania nie ma uprawnień do nadpisywania plików.

Równoległy proces budowania można odpalić za pomocą flag:

MSBuild.exe /m /nr:true /p:BuildInParallel=true;

Faktycznie wystarczy jedynie flaga /m, która mówi, żeby MSBuild użył wszystkich możliwych rdzeni CPU. BuildInParallel domyślnie jest ustawione na true, jednak specjalnie nadpisujemy, aby flagi w projektach były pominięte, gdyby jakaś się trafiła. Flaga /nr oznacza ponowne użycie tego samego procesu MSBuild, ponieważ dla każdego rdzenia przewidziany jest jeden proces MSBuild.exe i w zależności od ustawienia możemy użyć tego samego procesu lub stworzyć nowy. Flaga domyślnie jest włączona.

Podsumowanie

Dzisiaj zaprezentowałem Wam czysto teoretyczną wiedzę dotyczącą możliwych sposobów optymalizacji.

W kolejnym wpisie przygotuję rozwiązanie, które spina wszystkie powyższe rady… w celu optymalizacji (a jakże!) powtarzalnej pracy oraz możliwości rozwijania swoich własnych pomysłów i zapotrzebowań.

Jeśli macie jakieś pytania, to piszcie śmiało w komentarzach.

A tymczasem do następnego!

The post Wyciśnij z MSBuilda ostatnie soki appeared first on devstyle.pl.

View more on Maciej Aniserowicz's website »

Like • 0 comments • flag

Published on September 30, 2019 21:55

Status Update [vlog #309]

The post Status Update [vlog #309] appeared first on devstyle.pl.

View more on Maciej Aniserowicz's website »

Like • 0 comments • flag

Published on September 30, 2019 13:30

September 24, 2019

Nie ma Cię jeszcze na DNA (jeszcze)? Wiem dlaczego!

Sprzedaż DNA trwa od półtora tygodnia i ma się bardzo dobrze. Jak dobrze? Otóż w poniedziałek przekroczyliśmy kwotę (kolejnego) miliona zł… dodając go do dwóch baniek z czerwcowej przedsprzedaży. WeryNajs, co nie?

Jeśli nie ma Cię jeszcze wśród nas to… szkoda. Analizowałem możliwe przyczyny tej sytuacji, by to niedopatrzenie naprawić. I… WIEM dlaczego! A skąd wiem? Pomogło mi w tym kilkaset wypełnionych ankiet :).

Jeśli po prostu wyleciało Ci z głowy to spieszę z pomocą:

== TUTAJ kupisz dostęp do DNA w wyjątkowej cenie 1599zł + VAT (NIGDY nie będzie taniej!) ==

A jeśli chodzi o coś innego, to…

Zapraszam do lektury! Zobacz, czy któryś punkt pasuje do Twojej sytuacji.

1. Nie wiem, czy to jest naprawdę takie jest dobre

Ponad 2 tysiące osób (sic!!) już ma dostęp do pierwszych dwóch tygodni materiału (a tutaj pełna agenda). Na razie materiał przygotowany przez naszych wyjątkowych Mentorów oceniany jest wyłącznie bardzo pozytywnie.

Poniżej kilka przykładowych opinii, żeby Cię nie zalewać screenami. Jest tego o wiele więcej (znajdziesz na moich socialach).

Ale co tam inni ludzie, możesz wyrobić sobie własną opinię :). Pamiętaj, że udostępniliśmy 3 lekcje DEMO. Obejrzysz je na stronie projektu w sekcji DEMO

I, co bardzo ważne: nie ponosisz żadnego ryzyka, bo jeśli okaże się, że CI jednak nie pasuje, to masz 30 dni na zwrot 100% kasy!

2. Nie wiem, czy wszystko zrozumiem

Na stronie piszemy jasno, że DNA jest kierowane do architektów, seniorów i ewentualnie midów. ALE dociera do nas feedback (duuużo tego było na poniedziałkowym webinarze), że ten materiał jest dla młodszych adeptów IT-sztuki wręcz idealny. Dlaczego? Bo po prostu nie ma innego tak ustrukturyzowanego materiału, który prowadzi od A do Z.

Nie ma.

A młoda osoba czego potrzebuje najbardziej? Dobrego Mentora! Ich mamy tutaj aż trzech, i to najlepszych.

Nie namawiam Cię do DNA, jeśli nie rozumiesz połowy słów w agendzie albo lekcje DEMO są dla Ciebie totalnie czarną magią. Jeśli jednak CHCESZ, ale nie masz pewności, to pamiętaj: niczym nie ryzykujesz. Masz 30 dni na zwrot 100% kasy.

(Miej jednak na uwadze, że możesz potrzebować dużo więcej czasu do opanowania materiału, niż bardziej doświadczeni specjaliści. I kto jak kto, ale TY KONIECZNIE musisz dołączyć do naszej społeczności na Slacku, żeby nauczyć się jak najwięcej!)

3. Czy naprawdę zostanę w tyle, jeśli nie dołączę?

Spójrz na ten obrazek, a odpowiedź pojawi się sama:

To jest licznik Architektów na Slacku, będącym bardzo ważną częścią DNA.

Ponad 1400 osób już dołączyło. Nie do DNA, a do samego do Slacka! W DNA jest już o wieeele więcej.

To prawdziwa rewolucja w polskim IT.

Możesz albo być jej częścią…

…

Albo nie.

4. Czekam na finansowanie w firmie

Broszurkę, która może pomóc w uzyskaniu finansowania w firmie, już wysyłałem. Ale proszę jeszcze raz, znajdziesz ją tutaj (polecam!).

Zdecydowanie zachęcam do tego, by starać się o sponsoring firmy. Budżet szkoleniowy to często Twoje prawo, a nie znajdziesz lepszego sposobu na jego spożytkowanie. Ba, codziennie wpadają firmowe hurtowe zamówienia na 10, 30 czy nawet 60 tysięcy złotych, więc… to działa!

ALE!

Nie czekaj zbyt długo. W czerwcowej przedsprzedaży kilkadziesiąt osób się już na tym przejechało, a potem żałowało. Procesy procesami, wnioski wnioskami, procedury procedurami, ale to Twoja przyszłość, Twoja decyzja i – co najważniejsze – Twoje konsekwencje.

Powodzenia w staraniach, jednak nie pozwól, by zawodowa rzeczywistość wykluczyła Cię z DNA.

5. To dla mnie za drogo!

1599 zł + VAT. Dużo? To zależy!

To 85zł za tydzień nauki. Niewiele mniej płacę za godzinę konwersacji po angielsku. 45 minut nauki pływania dla mojej Córki to podobna cena (zresztą ten tekst piszę właśnie na basenie):

A godzina korepetycji z matmy na poziomie liceum kosztuje pewnie z połowę tego. Nie wspominając już o wydatkach na weekendową imprezę, bo to zupełnie inna para kaloszy.

To trochę zmienia perspektywę, nie?

A w DNA masz o wiele więcej niż same świetne materiały! Tutaj otrzymujesz jeszcze dostęp do wyjątkowej społeczności na Slacku, spotkania online na żywo i wieeele innych bonusów wymienionych na stronie (plus kilka niewymienionych).

== W sumie to racja! DOŁĄCZAM do DNA za 19*85zł + VAT! (Link bezpośrednio do koszyka) ==

A jeśli dalej nie? Hmm, no to lecimy!

6. Mam już inne materiały edukacyjne

I to jest dobry argument.

Jeśli faktycznie przerabiasz te materiały, to nie kupuj DNA. Pod warunkiem, że Twoim zdaniem one naprawdę są w stanie dać Ci takiego boosta, jak Droga Nowoczesnego Architekta.

My zalecamy, by na DNA poświęcać minimum godzinę dziennie (na zapoznawanie się z przygotowanymi treściami, wykonywanie zadań domowych i dyskusje na Slacku).

Wiedz jednak, że jeśli chodzi o IT, DNA to jedyna edukacja, jakiej potrzebujesz. Nie rób kilku szkoleń naraz. Skup się na jednym.

(BTW zobacz ile czasu zaoszczędzisz! na 19 tygodni wyeliminujesz dywagacje typu “czy ja potrzebuję tego kolejnego szkolenia?”)

7. Nie mogę ruszyć z materiałem od razu tu i teraz

Spoko! Jeśli teraz dołączysz do DNA, to udostępniane materiały masz na zawsze dla siebie. Dożywotnio.

(w przyszłości być może będziemy otwierać dostęp tylko na rok, ale Ciebie już to nie będzie dotyczyło: jeśli kupujesz teraz, to masz wszystko “bezapelacyjnie, do samego końca, mojego lub jej” [wink wink])

I, co ważne: dotyczy to także ewentualnych rozszerzeń Programu w kolejnych edycjach!

Więc w tym wypadku zdecydowanie dołącz teraz, a materiał po prostu nadrobisz we własnym tempie (będzie co nadrabiać!)

A następna edycja DNA (będzie jeszcze minimum jedna) odbędzie się dopiero w 2020 roku. I w zdecydowanie wyższej cenie.

8. Czekam na sam koniec sprzedaży, żeby dostać wszystkie maile

Tak, wiem, pięknie piszę! Sam te maile również dostaję i czytam z zaciekawieniem (no dobra, nie aż tak).

ALE!

Jeśli się zagapisz, jeśli się spóźnisz, jeśli “coś wypadnie”, to ta szansa nie wróci. Zamykamy zapisy 27 września o 21:00 i koniec, kropka, do widzenia. Nigdy nikogo nie wpuściłem do Programu poza okienkiem sprzedażowym. Wszystkie zamówienia muszą być złożone przed wyznaczoną godziną. ZAWSZE ktoś pisze, że zaspał, usypiał córkę, miał wizytę u lekarza czy wypadek. Sorry, nie ma wyjątków, nigdy! Przez lata mojej działalności zostawiłem w ten sposób “na stole” dziesiątki tysięcy złotych, ale rulez are rulez. Nie po to wysyłam miliony maili i wydaję majątek na reklamy FB, żeby potem łamać własne zasady :).

Poza tym… Program już trwa. Każdy dzień zwłoki to mniej interakcji na Slacku i mniej czasu na nadrobienie pierwszych lekcji przed kolejną porcją (a ta już w poniedziałek!).

9. ???

Jeśli przyczyna jest w Twoim przypadku inna (tak jak każdy problem na StackOverflow jest absolutnie wyjątkowy i jedyny w swoim rodzaju ;) ) to napisz do mnie! Po prostu zostaw komentarz albo napisz mi maila, podziel się swoimi obawami, a ja pomogę Ci je rozwiać.

To jak?

== Dołączam do DNA JUŻ TERAZ! Bo materiały i społeczność czekają! ==

Dziękuję za Twoją uwagę i pozdrawiam Cię serdecznie.

Jak zawsze, jestem tutaj po drugiej stronie w razie jakichkolwiek pytań.

Pozdro!

P.S. A tutaj bonus: forma video z jeszcze większym zestawem wątpliwości:

The post Nie ma Cię jeszcze na DNA (jeszcze)? Wiem dlaczego! appeared first on devstyle.pl.

View more on Maciej Aniserowicz's website »

Like • 0 comments • flag

Published on September 24, 2019 21:55

September 22, 2019

DevTalk #102 – O Systemach Rozproszonych z Jakubem Kubryńskim

Wielkich powrotów ciąg dalszy!

Jak zapewne pamiętacie z poprzedniego odcinka (a jeśli nie, to możecie go sobie odsłuchać >>o tutaj<<) Łukasz Szydło bardzo pochlebnie wypowiadał się na temat i rekomendował innego mojego rozmówcę, a konkretnie Jakuba Kubryńskiego. Oto i on!

Kubę mieliście już okazję posłuchać w odcinku DevTalk #84 – O Javie. Patrząc po statystykach, jest to jedna z najczęściej odsłuchiwanych rozmów. Tym razem “we will go deeper” i nie tylko poślizgamy się po powierzchni technologii, ale wnikniemy w jej głąb. W zawiły, skomplikowany i trudny świat systemów rozproszonych.

Dla przypomnienia: Kuba 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.

I przede wszystkim: Kuba jest jednym z trzech Mentorów w Programie DNA, czyli Drodze Nowoczesnego Architekta.

Z dzisiejszej rozmowy dowiecie się czym w ogóle są systemy rozproszone, jakie warunki musi spełniać system, żeby móc nazywać się rozproszonym i jakie są ich rodzaje. Wielu doświadczonych słuchaczy podcastu i czytelników bloga na pewno zainteresuje jak takie systemy się skalują i jak można uczynić je bardziej bezpiecznymi. Do tego mówimy o optymalizacji usług, polyglot programmingu, observability / APM, CAP, transakcjach rozproszonych, czym jest MIKRO w mikro-serwisach i wielu innych równie ciekawych rzeczach.

Nic, tylko włącząć!

Ale… czy na pewno NIC? Otóż nie. Teraz jest czas wyjątkowy, bo właśnie trwa nabór do pierwszej edycji Programi DNA – Droga Nowoczesnego Architekta . Co to jest, jaką rolę pełnimy tam z Jakubem i… dlaczego warto do nas dołączyć? (a BARDZO warto)