Maciej Aniserowicz's Blog, page 10
December 18, 2019
PROŚBA czy … ? [vlog #328]
The post PROŚBA czy … ? [vlog #328] appeared first on devstyle.pl.
December 17, 2019
December 16, 2019
December 15, 2019
DevTalk #108 – O Programowaniu Obiektowym z Tomaszem Stolarczykiem
Jeśli szukasz bezpiecznego schronienia przed świąteczną gorączką, chodź tutaj! Przysięgam, że nie uświadczysz tu ani sekundy Last Christmas. ;)
Skoro już mówimy o Świętach, mam małe ogłoszenie. Robimy przerwę świąteczną w devstyle’owych i DevTalkowych publikacjach w dniach od 23.12 do 12.01. A w nową dekadę wchodzimy pełną parą! :)
Programowanie obiektowe – wielu programistów go używa, ale niewielu zna jego korzenie! O przeszłości i przyszłości tego paradygmatu opowie wyjątkowy gość – Tomek Stolarczyk, jeden z recenzentów Programu DNA!
Tomek jest programistą. Interesuje się głównie DDD oraz ogólnie pojętym designem oprogramowania i refaktoringu, ale ma do czynienia z szeroką gamą dziedzin IT, poczynając od pracy z chmurami na budowaniu IoT na morzu kończąc. Ma doświadczenie zarówno z monolitami, jak i mikroserwisami. Prowadzi bloga mrpicky.dev. W wolnych chwilach gotuje lub gra w gry.
Ze sto ósmego odcinka DevTalku dowiesz się:
Skąd wzięło się programowanie obiektowe?
Jakie są podstawy obiektówki?
Jakie są najważniejsze pojęcia: abstrakcja, hermetyzacja, polimorfizm, dziedziczenie – w prostych słowach?
Gdzie uczyć się programowania obiektowego?
Czy w programowaniu obiektowym już wszystko zostało wymyślone?
Czy ekscytujemy się ciągle tym samym?
PS. Chcesz sprawić mi prezent świąteczny? Jeśli podobał Ci się ten odcinek, zostaw gwiazdkę i opinię na iTunes!
A teraz… PLAY!
http://traffic.libsyn.com/devtalk/DevTalk_108_-_O_Programowaniu_Obiektowym_z_Tomaszem_Stolarczykiem.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 #06 O programowaniu funkcyjnym z Michałem Łusiakiem
DevTalk #65 O powrocie do programowania z Robertem Podsiadłym
DevTalk #41 o legacy code z Jarkiem Pałką
DevTalk #58 o refactoringu z Łukaszem Karskim
DevTalk #102 o systemach rozproszonych z Jakubem Kubryńskim
DevTalk #98 o architekturze z Jakubem Pilimonem
Tomek
blog
ebook i sketch note’y o coulingu i spójności
Twitter: @stolarczykt
wydanie magazynu Byte z 1981, które bardzo mocno wpłynęło na popularyzację języków zorientowanych obiektowo
książki pomagające w pracy nad designem (zalecana kolejność):
Refactoring: Improving the Design of Existing Code
Design Patterns: Elements of Reusable Object-Oriented Software warto z grubsza być świadomym wzorców i mieć ją pod ręką przy kolejnej polecanej czyli Refactoring to Patterns
Refactoring to Patterns
Working Effectively with Legacy Code
An Introduction to Object-Oriented Programming – dość fajna książka, która pokazuje też m. in. argumenty za przechodzeniem na OOP z proceduralnego i jakie problemy dręczyły wtedy programistów
Reliable software through composite design – Glenford J. Myers – wspominana w odcinku. Wprowadziła podział na typy couplingu
Bardzo fajna, wspomniana prezentacja Breta Victora The Future of Programming , która pozwala “cofnąć się w czasie” i pokazuje kawałek historii naszej branży oraz wiele starych systemów, które nawet teraz mogą wydawać się innowacyjne
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 #108 – O Programowaniu Obiektowym z Tomaszem Stolarczykiem appeared first on devstyle.pl.
December 8, 2019
Jak zbudować samozarządzalny system w .NET
W poprzednich artykułach opisywałem MSBuilda oraz przykładowy system do automatyzacji wdrożeń, czyli Cake:
Wyciśnij z MSBuilda ostatnie soki
Cake – jak wdrażać, aby się nie zrażać
Powyższe rozwiązania nie wyczerpują tematu automatyzacji, integracji usług, narzędzi oraz prostoty, za którą idzie maksyma DRY (Don’t Repeat Yourself). Pierwsze na tapet bierzemy zaawansowane funkcjonalności MSBuilda oraz rozbudowywanie procesu.
ItemGroup
Grupa elementów, w której dla każdego elementu (dajmy na to – pliku) jesteśmy w stanie zdefiniować odpowiednie atrybuty. Przykładowo: wszystkie pliki .cs są zdefiniowane jako Compile:
View the code on Gist.PropertyGroup
Grupa właściwości, w której każda właściwość pozwala przetrzymywać wartości pod daną nazwą, można nadpisywać i sklejać wiele takich zmiennych w jedną:
View the code on Gist.
Odwołanie do właściwości:
View the code on Gist.Condition
Prosty „if”, dzięki niemu powyższe elementy można włączać/wyłączać wedle ustalonych reguł. Na przykład:
View the code on Gist.Target
Naprzemiennie będę wykorzystywał target i element docelowy jako jedno i to samo. Jest to coś w rodzaju metody, którą wpinamy w proces MSBuilda. Dzięki takiemu podejściu możemy po procesie budowania powiedzieć, że chcemy, aby uruchomił się proces paczkowania:
View the code on Gist.
Służą do tego atrybuty BeforeTargets oraz AfterTargets. Jeśli jako atrybut Name podamy istniejący już element docelowy, to zastąpimy jego działanie, więc nie warto nazywać targetów tak samo, chyba że jesteśmy pewni konsekwencji:
View the code on Gist.
Sam proces, jakim jest Build, ma również elementy docelowe BeforeBuild i AfterBuild. Tyczy się to także innych podstawowych procesów, takich jak Clean, Rebuild, czyli:
View the code on Gist.Directory.Build.props
Gdy chcemy rozszerzyć funkcjonalność projektów w .NET, mamy dwie możliwości. Pierwsza – kopiowanie do każdego projektu potrzebnych targetów oraz właściwości. Druga – agregacja targetów oraz właściwości w „jakimś” miejscu oraz powiedzenie projektowi: użyj tego.
Pierwszym z agregatów jest Directory.Build.props. Plik powinien definiować tylko podstawowe elementy oraz właściwości, z których będą korzystać targety, elementy czy warunki. Zasada szukania za plikiem jest prosta – szuka go w katalogu, jak nie znajdzie, to przeskoczy katalog wyżej i powtórzy szukanie. Takie podejście powoduje, że możemy definiować ten rodzaj pliku dla pojedynczego projektu, solucji lub wszystkich systemów.
View the code on Gist.
Ważne jest to, że gdy plik zostanie znaleziony, poszukiwania się kończą, chyba że w pliku najbliższym projektowi dodamy linię:
View the code on Gist.
Kiedy mamy trzy takie pliki, to dwa poprzednie muszą mieć tę linię.
W procesie MSBuilda załączany jest wcześnie, więc wiele predefiniowanych właściwości może być pustych, gdy będziemy chcieli z nich skorzystać.
Jako że definiowany jest na początkowym etapie, możemy sami zaimplementować proces szukania za konkretnym plikiem, a potem wykonać na nim akcje. Przykładowo: chcemy, aby w momencie znalezienia pliku stylecop.json załączył go w projekcie:
View the code on Gist.
Przy takim podejściu mamy pewność, że załączy pierwszy znaleziony plik, dzięki temu istnieje możliwości, że projekt będzie miał swoją własną implementację rozwiązania, a reszta – ogólną.
Directory.Build.targets
Rozszerzenie sugeruje, że w jakiś sposób ten plik agreguje targety, i jest to prawdą. Gdy MSBuild wykryje ten plik w katalogu, to do każdego projektu, jaki znajdzie, doda wszystkie zdefiniowane przez niego elementy docelowe oraz właściwości. Zasada szukania jest taka sama jak za Directory.Build.props.
View the code on Gist.
W całym procesie jest załączany prawie na samym końcu, tuż po podłączeniu plików .target z paczek NuGet, więc jest w stanie nadpisać większość właściwości zdefiniowanych w MSBuildzie i Directory.Build.props.
Oba pliki wprowadzają podstawową agregację elementów docelowych oraz właściwości. Jednak gdy chcemy powielać te same rozwiązania, to kopiowanie i utrzymywanie 70 kopii tego samego rozwiązania jest zatrważająco ciężkie. Mówimy tutaj o MSBuildzie i sytuacji, w której jedna literówka będzie miała wpływ na to, jak system będzie się zachowywał, bo większość rzeczy została napisana w XML-u.
SDK
SDK zostało wprowadzone w MSBuild v15 i jego zadaniem jest agregować nasze właściwości oraz targety w jednym miejscu – projekcie – i dodawać jako SDK:
View the code on Gist.
Podstawowa struktura projektu:
View the code on Gist.
Folder w paczce musi nazywać się Sdk oraz pliki kolejno Sdk.props, Sdk.targets.
UsingTask
Wprawne oko zauważy, że w strukturze można załączać pliki oparte na C#. MSBuild pozwala na definiowanie własnych zadań, które możemy wpiąć w proces za pomocą elementu docelowego.
UsingTask jest informacją, że z takiej biblioteki o takiej nazwie i takim zadaniu będziemy korzystać. Tworzenie zadania wygląda następująco:
View the code on Gist.
a użycie w taki sposób:
View the code on Gist.
W przykładzie wyżej mamy właściwość XeinaemmSdkPath, czyli miejsce, gdzie ma szukać SDK mojego projektu. Jak nie znajdzie, to zaczyna szukać w folderze, w którym znajduje się Sdk.targets, tj. MSBuildThisFileDirectory. W większości wypadków oznacza to ścieżkę do folderu lib w paczce NuGet.
Gdy mam już zdefiniowane zadanie, jego użycie jest proste. Odwołujemy się do niego w elemencie docelowym. W przypadku sekcji „runtime” w app.config lub web.config najlepiej taką akcję wykonać przed elementem docelowym ResolveAssemblyReferences, bo kolejnym etapem jest generowanie tejże sekcji przez MSBuilda.
Nowy format projektu
Wokół funkcjonalności SDK został zbudowany nowy format projektów. Biblioteki używają Microsoft.NET.Sdk, a ASP.NET Core – Microsoft.NET.Sdk.Web. Obecnie z tego procesu wyłączony jest ASP.NET ze względu na brak pełnej kompatybilności (stan na dzień 15.11.2019).
Podstawowa struktura nowego formatu dla biblioteki:
View the code on Gist.
TargetFramework jest respektowany zgodnie z wytycznymi SDK. Przykładowo: można wykorzystać net48, netstandard2.1 czy netcoreapp3.0, aby mieć w pełni funkcjonalną bibliotekę bez definiowania większej liczby opcji.
Warto nadmienić, że – w przeciwieństwie do starego – obecny format jest dynamiczny. Oznacza to, że zmiana właściwości, dodanie pliku, usunięcie zostaną od razu zauważone przez projekt. Domyślnie pliki takie jak .cs są rozpoznawane i automatycznie ustawiany jest dla nich element Compile. Podobnie wykrywane są pliki .ts.
Koncept All i App
Wraz z pojawieniem się .NET Core 2.0 wprowadzono koncept agregacji paczek rozbity na dwa podejścia:
App – agregacja rozwiązań związanych z .NET Core jako całościowej biblioteki (frameworka).
All – App z rozwiązaniami budowanymi przez firmy trzecie, na przykład Json.NET (Newtonsoft).
W wersjach ASP .NET Core 2.0–2.2 można było wybrać paczkę, z jakiej korzystamy, jednak z dużym naciskiem na App, ponieważ All wycofano w wersji 3.0. App natomiast został zakorzeniony jako „by design”.
Ten sam koncept można wykorzystać w rozwiązaniach wewnętrznych, budując własne lokalne biblioteki, wykorzystywane w wielu systemach:
View the code on Gist.
Powyżej mamy przykład takiej biblioteki. Poza tym, że zbiera kilkanaście bibliotek do jednego worka, nie robi nic innego.
Takie podejście pozwala na:
Zebranie rozwiązań najczęściej wykorzystywanych w systemach i załączenie ich jako jedną paczkę.
Upewnienie się, że taka paczka zawiera wszystkie potrzebne zmiany do działania, czyli jest bardzo blisko koherentności.
Zarazem:
Powoduje dołączenie niepotrzebnych bibliotek.
Agreguje wszystkie zmiany, więc podbicie wersji takiego agregatu wymusza na nas wprowadzenie wszystkich poprawek „breaking changes”.
Wykorzystywanie zewnętrznych rozwiązań może powodować niekoherentność, zwłaszcza w dużych agregatach.
Koherencja rozwiązania
Brak koherentności oznacza, że system jest niespójny i prawdopodobnie w błędnym stanie, co w naszym wypadku najczęściej wiąże się z posiadaniem wielu wersji tej samej paczki. W systemach .NET i NuGet przy zarządzaniu paczkami przez Visual Studio mamy zakładkę „Konsolidacji”. Listuje ona wszystkie paczki, które są w różnych wersjach – to brak koherencji.
Przy wprowadzaniu zmian w bibliotekach współdzielonych często jedna zmiana oddziałuje na inne paczki przez co, gdy zaktualizujemy jeden system to inne systemy dalej posiadają ten sam błąd. Często zdarza się, że nawet w jednym systemie możemy wywołać brak spójności, wystarczy podbić jedną paczkę, która znajduje się najniżej w zależnościach(inne paczki z niej korzystają) i zawiera zmiany, które spowodują, że system się wysypie bo jedna z paczek nie zawiera potrzebnych zmian. To również jest brak koherencji.
Agregacja wielu paczek w jedną pozwala nam do pewnego stopnia zaradzić temu problemowi, jednak jeśli wykorzystujemy zewnętrzne rozwiązania, której mają swoje własne zależności, problem się rozrasta. Warto więc uważać na takie zależności.
Prostym rozwiązaniem na wiele zależności może być wykorzystanie SDK zbudowanego przez Microsoft:
View the code on Gist.
Za pomocą pliku Packages.props definiujemy listę paczek oraz wersji, a SDK będzie dbał o to, aby projekt nie definiował wersji oraz paczek, których nie ma na liście, poprzez blokowanie kompilacji.
Podsumowanie
.NET Core bazuje na systemie zarządzania znanym pod nazwą Arcade, z którego można czerpać inspirację. W dokumentacji problem koherencji można spotkać pod nazwą Release Shutdown.
Niezależnie od wersji MSBuilda w pliku Microsoft.Common.CurrentVersion.targets mamy zdefiniowanie elementy docelowe, w które możemy się wpiąć. Zatem: sky is the limit.
Przykłady kodu wziąłem z bibliotek Jarvis oraz Xeinaemm.Sdk.
Do następnego!
The post Jak zbudować samozarządzalny system w .NET appeared first on devstyle.pl.
December 3, 2019
December 1, 2019
DevTalk #107 – o UX z Wojtkiem Kutyła
User Experience jest wymysłem naszych czasów? Nic bardziej mylnego! Już po II wojnie światowej inżynierowie Toyoty kombinowali, jak poprawić ergonomię samochodów. Bez nadawania specjalnej nazwy temu procesowi. Wraz z rozwojem technologii, UX przeniknął do digitalowego świata i zadomowił się w nim na dobre.
UX wydaje się być działką UX designerów. Gość sto siódmego odcinku podcastu DevTalk pokaże, jak ogromny wpływ w tej dziedzinie mają programiści. Poznaj Wojtka Kutyłę!
Wojtek jest niezależnym konsultantem i trenerem UX oraz service design. Mieszka w Edynburgu. W sektorze cyfrowych produktów i usług pracuje od 1999 roku. Współpracuje z wieloma międzynarodowymi organizacjami. Regularnie odbywa wizyty w Polsce, prowadząc warsztaty, występując na konferencjach i ucząc projektantów UX zaawansowanych metod pracy w zawodzie. Propaguje UX bez napinki. Prowadzi poczytnego bloga Opowieści ze świata UX.
Jeśli chcesz rozpocząć karierę jako UX Designer albo wynieść swoje programowanie na wyższy poziom, ten odcinek jest dla Ciebie!
Dziś dowiesz się:
Czym jest UX?
Dlaczego UX jest ważny dla programistów?
Jakie są konsekwencje UXowych błędów?
Jak rozpocząć swoją przygodę z UX?
Jaki wpływ na UX ma programista / architekt oprogramowania?
Z jakich narzędzi korzysta UXowiec?
PS. Nic nie rozgrzewa serca jak ciepłe słowo. ;) Jeśli podobał Ci się ten odcinek, zostaw gwiazdkę i opinię na iTunes!
Czas na PLAY!
http://traffic.libsyn.com/devtalk/DevTalk_107_-_O_UX_z_Wojtkiem_Kutya.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 #44 – O produktywności z Michałem Śliwińskim
DevTalk #38 – O dążeniu do celu z Michałem Szafrańskim
DevTalk #56 – O stresie i porażkach z Krzysztofem Skubisem
DevTalk #92 – O błędach w tworzeniu WWW z Tomaszem “Comandeer” Jakutem
Wojtek Kutyła
blog
fanpageWojtek Kutyła o UX
artykuł napisany specjalnie dla Was przez Wojtka
Linki warte uwagi
UX Design Collective— bardzo solidne źródło UXowej wiedzy, dobre artykuły rozsyłane co tydzień. Mało lipy.
UX Matters— potwornie brzydka strona pełna świetnej treści.
Inclusive Components— bardzo dobre źródło pomocne frontendowcom: komponenty z sensem!
How User Experience Shapes Software Development— jeden z przykładowych, niezłych artykułów na ten temat.
How UX Design integrates with Agile and Scrum— napisane przez Jeffa Gothelfa, jeden z większych mózgów na scenie UXowej.
Norman/Nielsen Group— zbiór doskonałych artykułów na tematy związane z UX.
Opowieści ze świata UX— to mój blog i strona z informacjami na temat szkoleń i wystąpień.
UX Magazyn— polski magazyn dla projektantów i nie tylko.
Poza tym polecam Google z masą fajnych informacji.
Podcasty warte przesłuchania
UX Podcast— chyba najlepszy podcast o UX, a w każdym razie mój ulubiony, w którym często mówi się o przekraczaniu barier w stronę innych dziedzin digital.
Archiwum podcastu Jareda Spoola— kopalnia wiedzy o UX.
Nietylko.design— Tomek Skórski rozmawia z ciekawymi ludźmi.
Książki warte przeczytania
Design na co dzień— kultowa już pozycja Dona Normana. Dobre wprowadzenie w temat użyteczności.
Badania jako podstawa User Experience— dobra książka rodem z Polski, która wprowadza w tajniki badań z użytkownikami.
The User Experience Team of One— jak się za to wziąć przy minimalnych zasobach.
UX Strategy— następna świetna książka o UX w podejściu “partyzanckim”. Wersja polska jest fatalnie przetłumaczona, polecam oryginał.
Let my people go surfing— chyba najlepsza książka o projektowaniu usług jaką znam, w której ani razu nie pada nic na temat “UX” ani “service design”. Cudo. To przeczytać powinni zwłaszcza szefowie zespołów i founderzy startupów.
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 #107 – o UX z Wojtkiem Kutyła appeared first on devstyle.pl.
November 30, 2019
November 28, 2019
November 27, 2019
Szczęście POWSZEDNIEJE [vlog #322]
The post Szczęście POWSZEDNIEJE [vlog #322] appeared first on devstyle.pl.
Maciej Aniserowicz's Blog
- Maciej Aniserowicz's profile
- 22 followers
