XAML Power Toys – generator widoku XAML

0

W dzisiejszym poście przyglądniemy się dość ciekawej wtyczce rozszerzającej możliwości Visual Studio.

XAML Power Toys jest generatorem widoków, który automatycznie tworzy kod XAML na podstawie wcześniej przygotowanego view-model-u. Siłą rzeczy, skorzystamy z niego najlepiej stosując w naszej aplikacji wzorzec MVVM, chociaż nie jest to oczywiście warunek konieczny.

Wtyczka, w swoim założeniu, ma zdjąć z nas żmudną część pisania XAML-a pozostawiając nam jedynie kwestie związane z jego stylizowaniem i drobnymi korektami.

Wtyczkę zainstalujemy w VS2015, VS2017 i VS2019 za pomocą Manage Extensions:

Przetestujemy wtyczkę w projekcie WPF-owym. Spróbujmy więc teraz stworzyć sobie solucję WPF i stworzyć jakiś testowy view-model dla naszego widoku:

class TestViewModel : INotifyPropertyChanged
{
        public event PropertyChangedEventHandler PropertyChanged;
        private string _name;
        private string _surname;
        private string _emailAddress;
        private int _age;
        private bool _isRegistered;
        public string Name
        {
            get => _name;
            set
            {
                _name = value;
                OnPropertyChanged();
            }
        }
        public string Surname
        {
            get => _surname;
            set
            {
                _surname = value;
                OnPropertyChanged();
            }
        }
        public string EmailAddress
        {
            get => _emailAddress;
            set
            {
                _emailAddress = value;
                OnPropertyChanged();
            }
        }
        public int Age
        {
            get => _age;
            set
            {
                _age = value;
                OnPropertyChanged();
            }
        }
        public bool IsRegistered
        {
            get => _isRegistered;
            set
            {
                _isRegistered = value;
                OnPropertyChanged();
            }
        }
        [NotifyPropertyChangedInvocator]
        protected virtual void OnPropertyChanged([CallerMemberName] string propertyName = null)
        {
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
        }
}

Zanim skorzystamy z dobrodziejstw XAML Power Toys musimy zbudować projekt. Podobnie należy postąpić przy jakiejkolwiek zmianie w view-model. XAML Power Toys wykorzystuje mechanizm reflekcji aby uzyskać meta dane o modelach i view-modelach a następnie wykorzystać je do prezentacji opcji możliwych do wykorzystania przy generowaniu widoku.

To co musimy teraz zrobić, to wewnątrz pustego widoku XAML wcisnąć prawy przycisk myszy i z menu podręcznego wybrać pozycję Xaml Power Toys.

Uruchomimy w ten sposób kreator, który pozwoli nam najpierw wybrać klasę zawierającą nasz view-model:

Następnie, w kolejnym oknie kreatora, wybieramy propercje naszego view-modelu, które chcemy wykorzystać w naszej formie i ustawiamy parametry:
Otrzymamy w ten sposób wygenerowany podstawowy widok w kodzie XAML, dodatkowo opakowany w ramkę jeżeli zaznaczyliśmy taką opcję.
<Border BorderThickness="1" BorderBrush="Gray" Padding="10" CornerRadius="10">
            <Grid>
                <Grid.ColumnDefinitions>
                    <ColumnDefinition Width="*"/>
                </Grid.ColumnDefinitions>
                <Grid.RowDefinitions>
                    <RowDefinition Height="Auto"/>
                    <RowDefinition Height="*"/>
                </Grid.RowDefinitions>
                <TextBlock Text="XPowerToysTest" />
                <Grid Grid.Row="1">
                    <Grid.ColumnDefinitions>
                        <ColumnDefinition Width="85"/>
                        <ColumnDefinition Width="*"/>
                    </Grid.ColumnDefinitions>
                    <Grid.RowDefinitions>
                        <RowDefinition Height="Auto"/>
                        <RowDefinition Height="Auto"/>
                        <RowDefinition Height="Auto"/>
                        <RowDefinition Height="Auto"/>
                        <RowDefinition Height="Auto"/>
                    </Grid.RowDefinitions>
                    <Label Content="Name" />
                    <TextBox Text="{Binding Path=Name, Mode=TwoWay, ValidatesOnDataErrors=True, ValidatesOnNotifyDataErrors=True, ValidatesOnExceptions=True}" Grid.Column="1" Grid.Row="0" x:Name="name" />
                    <Label Content="Surname" Grid.Row="1" />
                    <TextBox Text="{Binding Path=Surname, Mode=TwoWay, ValidatesOnDataErrors=True, ValidatesOnNotifyDataErrors=True, ValidatesOnExceptions=True}" Grid.Column="1" Grid.Row="1" x:Name="surname" />
                    <Label Content="Age" Grid.Row="2" />
                    <TextBox Text="{Binding Path=Age, Mode=TwoWay, ValidatesOnDataErrors=True, ValidatesOnNotifyDataErrors=True, ValidatesOnExceptions=True}" Grid.Column="1" Grid.Row="2" x:Name="age" />
                    <Label Content="Email Address" Grid.Row="3" />
                    <TextBox Text="{Binding Path=EmailAddress, Mode=TwoWay, ValidatesOnDataErrors=True, ValidatesOnNotifyDataErrors=True, ValidatesOnExceptions=True}" Grid.Column="1" Grid.Row="3" x:Name="emailAddress" />
                    <Label Content="Is Registered" Grid.Row="4" />
                    <CheckBox IsChecked="{Binding Path=IsRegistered, Mode=TwoWay}" Grid.Column="1" Grid.Row="4" x:Name="isRegistered" />
                </Grid>
            </Grid>
        </Border>

I to w zasadzie wszystko. Tylko tyle i aż tyle.

Rozbudowany opis można znaleźć pod adresem: https://oceanware.wordpress.com/xaml-power-toys/

Czy to się przydaje ?

Odpowiedź, jak zwykle, brzmi – to zależy. Przy złożonych formach, z dużą ilością kontrolek szybciej wygenerujemy w ten sposób czysty XAML niż pisząc go ręcznie. Potem bawimy się jedynie w korekty layoutu i stylizowanie.
Wtyczka działa tak samo dobrze w przypadku WPF jak i Xamarin Forms. W przypadku Xamarin-a w kreatorach dostępne są nieco inne opcje.
W przypadku form zawierających stosunkowo niewiele kontrolek, ale za to o dość złożonym układzie wygodniej chyba jednak napisać XAML-a ręcznie.

Randezvous z Eto.Forms

0

Eto.Forms jest jednym z dwóch ciekawych frameworków, które pozwalają na tworzenie wieloplatformowych aplikacji desktopowych z wykorzystaniem .Net (drugim jest oczywiście Avalonia).

Projekt funkcjonuje od 2012 roku – a więc już dość długo. Jest to projekt open source oparty na dość liberalnej licencji BSD-3.

Na każdym z systemów będących dostępnych jako target (Windows, MacOS, Linux) nasze GUI renderuje się za pomocą standardowych rozwiązan systemowych. W Windowsie będzie to Windows Forms (z wykorzystaniem GDI lub DirectDraw) lub WPF, w MacOS MonoMac lub Xamarin.Mac a w przypadku linux-a np. Ubuntu GTK2 lub GTK3. Istnieje również target iOS z wykorzystaiem Xamarin.IOS Trwają prace nad przygotowaniem targetu dla Androida (również z wykorzystaniem Xamarin-a). Możemy skorzystać za równo z klasycznego .Net jak i .Net Core.

Zabawę najwygodniej rozpocząć od instalacji wtyczki do Visual Studio, którą znajdziemy bez problemu pod hasłem Eto.Forms. Będziemy mogli teraz utworzyć nową solucję typu Eto.Forms Application. Niestety, na chwilę obecną nie ma wtyczki dla Visual Studio 2019, nie dostaniemy więc tutaj póki co podglądu dla tworzonego XAML-a. Być może wkrótce pojawi się dedykowana wersja.

Przy tworzeniu solucji naszym oczom ukarze się prosty wizard, który pozwoli nam zdefiniować co ma zawierać solucja i w jaki sposób będziemy chcieli tworzyć GUI

Możemy więc stworzyć jeden projekt wspólny, lub podzielić projekty pomiędzy platformy jeżeli chcemy zakodować specjalne funkcjonalności dla danej z nich.

Ciekawe są natomiast sposoby tworzenia GUI:

  • Code – całość GUI tworzymy z kodu. W czasach poprzedzających .Net 2.0 (ktoś poza mną to jeszcze pamięta ? ) takie projekty często się zdarzały. Nie mamy żadnego podglądu. Piszemy kod w C# który definiuje okna i kontroli.
  • Xaml – mamy separację definicji GUI w postaci dialektu Xaml-a (o tym jeszcze później) i code behind. Możemy się pokusić o zastosowanie MVVM. Mamy również bardzo prosty podgląd tego co zdefiniowaliśmy w XAML-u.
  • Json – jak wyżej, ale zamiast Xaml-a mamy JSON
  • Code Preview – tutaj mamy separację kodu form od code behind (na poziomie plików – z wykorzystaniem partial class – tak jak to działa w WPF i Windows Forms). Kod layoutu i kontrolek tworzymy jednak ręcznie, ale mamy dostępny podgląd.

Ze względu na moje przywiązanie do XAML-a i WPF ja skorzystałem z opcji Xaml i wybrałem projekt łączący platformy.

Alternatywnie, możemy sobie stworzyć projekt dla .Net Core korzystając z CLI, co też nie jest skomplikowane.

Najpierw instalujemy template-y:

dotnet new -i "Eto.Forms.Templates::*"

Teraz, w katalogu utworzonym dla naszej solucji generujemy szablon projektu

dotnet new etoapp -sln -xm -m xaml

W ten sposób otrzymamy solucję z plikiem .sln, którą otworzymy w Visual Studio, otrzymamy osobny projekt dla Mac-a a GUI będziemy tworzyć w XAML-u.

Natomiast jeżeli wpiszemy:
dotnet new etoapp --help

Wyświetlą się nam wszystkie opcje dostępne podczas tworzenia projektu.

Xaml pisze się calkiem przyjemnie. Podgląd odświeża się w miarę tworzenia i pozycjonowania kolejnych układów i kontrolek. Jak widać jednak, podgląd nie zawiera chociażby widoku menu czy toolbox-a.

Repozytorium dostępnych kontrolek nie jest małe. Opisy poszczególnych znajdziemy w Wiki projektu.

Jeżeli chodzi o składnię Xaml to nie jest idealnie. Chociażby często używany Grid tutaj nazywa się TableLayout. Nie przełożymy więc łatwo GUI z projektu WPF-owego. Trzeba się trochę nagłówkować i sięgać do dokumentacji.

Zarówno pod windowsem jak i na mac-u  w Visual Studio projekt buduje się i odpala bez większych problemów wykorzystując kontrolki natywne dla swojego target-u.

Nie ma problemu z otwarciem i zbudowaniem projektu w Visual Studio dla Mac.

Pod Linux-em (ja testowałem na Ubuntu 18.04) projekt spokojnie zbudujemy wykorzystując Mono, a edytować możemy chociażby w MonoDevelop, czy VSCode. W obu tych przypadkach (podobnie jak i w VS dla Mac) nie otrzymamy niestety wtyczki pozwalającej na podgląd XAML-a w trakcie jego pisania.

Co myślę o Eto.Forms ?

Generalnie bardzo przyjemnie się z nim pracuje. Do składni Xaml-a można się dość szybko przyzwyczaić. Intellisense w edytorze xaml podpowiada nam co mamy dostępne. Nie szarpałbym się chyba jednak za tworzenie całego GUI w kodzie, bez korzystania z XAML-a lub JSON-a. Podgląd formy działa całkiem sprawnie i aktywnie reaguje na wprowadzane zmiany. Szkoda, że nie ma póki co wtyczki dla VS 2019, ale to pewnie tylko kwestia czasu.

O tym, że projekt jest dość dojrzały świadczy to, że jest kilka aplikacji które zostały z jego udziałem utworzonych. Chociażby tzw pipeline tool dla frameworka do tworzenia gier MonoGame.

Pewnym problemem może być konieczność dostosowania się do istniejącego repozytorium kontrolek. Zapewne diabeł tkwi w szczegółach i przy większej aplikacji można napotkać jakieś kwiatki, ale potencjalnie wszystko działa zgrabnie i wydaje mi się że można stworzyć całkiem ładną i zgrabną aplikację desktopową, którą następnie z jednej solucji zbudujemy dla Windows, MacOS i Linux.

Lazarus + Pascal Scada i sterowniki Siemens Simatic

0

Jeszcze mniej więcej 15-20 lat temu narzędzia RAD wręcz rządziły światem developmentu. Był to okres rozwijającej się mocno sieci ale już dość dobrze ugruntowanych aplikacji desktopowych. Na świecie królował Windows XP, chociaż wiele osób korzystało jeszcze z wersji 2000. Na rynku narzędzi RAD było dwóch dużych graczy: Microsoft, ze swoim Visual Basic-iem oraz Borland z Delphi i C++ Builder. Początki mojej pracy zawodowej to właśnie obok PHP – Borland Delphi. Korzystaliśmy wtedy jeszcze z wersji 5 by potem przeskoczyć do wersji 2005.

Później świat się zmienił. Anders Hejlsberg opuścił Borland aby przejść do Microsoft i stworzyć C#. Świat odważnie wkroczył w trwającą do dzisiaj erę aplikacji webowych a Delphi w dużej mierze trafiło do lamusa. Do dzisiaj oczywiście jest rozwijane i sprzedawane przez firmę Embarcadero, ale produkcyjnie wykorzystywane jest już coraz rzadziej. Podobny los podzielił Visual Basic, który przekształcił się w istniejący do dzisiaj Visual Basic .Net, który jednak ze swoim protoplastą nie ma wiele wspólnego poza elementami składni.

Narzędzia RAD istnieją na rynku nadal. W większości są to jednak dość niszowe rozwiązania, które zrzeszają wokół siebie grupki zapalonych ludzi. Duże firmy software-owe trzymają się raczej już od takich produktów z daleka i generalnie jest to zrozumiałe. Znalezienie programisty, który ogarnie cokolwiek w projekcie, jeżeli poprzedni zespół się „wysypał” może się okazać trudnym zadaniem.

Pascal też jest już dzisiaj językiem mało używanym. Nie uczy się go już raczej w szkole a o zastosowaniach produkcyjnych raczej można tylko pomarzyć. Rozwój języka również stanął w miejscu – nie można go nijak dzisiaj porównać do Javy czy do C#. Pasjonaci Pascala, a są tacy, z pewnością by się z tym stwierdzeniem nie zgodzili, ale obiektywnie tak to właśnie wydaje się wyglądać.

Zaletą narzędzi RAD był niewątpliwie bardzo niski punkt wejścia, dla osób które z programowaniem nie miały zbyt wiele do czynienia. Można było w bardzo krótkim czasie wyklikać sobie fajny interfejs prostej aplikacji i dosłownie paroma linijkami kodu sprawić aby ożył. Te czasy już jednak chyba nie wrócą.

Lazarus, o którym mowa będzie w dzisiejszym poście jest open source-ową wersją środowiska Delphi – a może inaczej – przygotowaną na wzór Delphi. Oparta jest ona o kompilator FPC (Free Pascal Compiler) i jest wieloplatformowa. Środowisko Lazarusa odpalimy zarówno na Windowsie, Linux-ie jak i na Mac-u a nawet i na Raspberry PI. Podobnież możemy targetować nasz projekt. Samo IDE, jak i repozytorium dostępnych kontrolek do złudzenia przypomina to co mieliśmy dostępne w Delphi. Programista, który miał kiedykolwiek do czynienia z Deplhi nie będzie się tutaj czuł obco. Istnieją nawet specjalne konwertery wbudowane w Lazarus-a, które pozwalają na konwertowanie projektów Delphi do formatu Lazarus-owego.

Lazarus posiada wiele dodatkowych kontrolek i bibliotek stworzonych przez osoby trzecie. Jedną z nich – bardzo interesującą – jest Pascal Scada. Biblioteka jest oparta na licencji LGPL2.

Pascal Scada zawiera sporą ilość kontrolek, które pomagają w realizacji komunikacji z urządzeniami (w tym z całą paletą sterowników Siemens) z wykorzystaniem protokołu ISOOverTCP lub Modbus. Szczerze mówiąc, kiedy po raz pierwszy zainstalowałem ten dodatek do Lazarusa to byłem w ciężkim szoku – gdybym miał coś takiego 10-15 lat temu o ile szybciej i łatwiej można by realizować pewne projekty.

Dostajemy więc bloczki do zestawiania komunikacji, ale też bloczki które reprezentują tzw tagi, odpowiadające wartościom lub grupom wartości, które chcemy odczytać/zapisać. Cała warstwa związana z nawiązywaniem połączenia, realizowaniem odczytu i zapisu jest praktycznie przed nami ukryta.

Otrzymujemy np. kontrolkę w stylu TextEdit, do której podłączamy zdefiniowany tag w sterowniku i kontrolka automatycznie wyświetla nam wartość taga a po zapisaniu nowej wartości i potwierdzeniu trafia ona do sterownika. Znajdziemy też kontrolki typowo wizualizacyjne jak np. zawór albo zbiornik, do którego też tylko podpinamy zdefiniowane tagi.

Przygotowałem prostą aplikację, która tak naprawdę jest klonem tego, co przygotowałem przy postach o bibliotekach C# do komunikacji ze sterownikami. Komunikuje się ona z dokładnie tym samym programem w S7-1200 jak ten, z którego korzystałem w poprzednich postach. Ponieważ do Pascal Scada nie ma zbyt dużo dostępnej dokumentacji część wykonałem metodą prób i błędów, ale i tak udało się to zrobić w nieprawdopodobnie krótkim czasie.

Przygotowałem (wyklikałem) GUI:
A całość kodu, którą musiałem do tego napisać przedstawia screen poniżej. Oczywiście pewne parametry trzeba poustawiać również we właściwościach kontrolek.
Bardzo szybko, łatwo i całkiem przyjemnie osiągamy identyczny efekt, jak w aplikacji testowej w C#:
Wspomniałem wcześniej o wieloplatformowości Lazarusa… ten sam projekt skompilowany i uruchomiony w Ubuntu 18.04, bez jakichkolwiek zmian w konfiguracji i kodzie:

Nie testowałem co prawda na Raspberry PI, ale nie powinno być tu specjalnie różnicy w stosunku do Ubuntu.

Nie udało mi się też uruchomić tego projektu na Mac-u, ale głównie dlatego że nie bardzo chciało mi się walczyć z ustawieniami kompilatora aby poprawnie dodać do IDE Pascal Scada.

Mój projekt testowy w Lazarus-ie jest oczywiście dostępny do pobrania na github-ie.

I na koniec kilka słów podsumowania. Lazarus i Pascal Scada bardzo mi się podobają. Być może ze względu na sentyment do dawnych czasów. Trudno mi powiedzieć jak to rozwiązanie zachowało by się w dużej aplikacji, trzeba by dokładnie przeglądnąć kod biblioteki żeby zobaczyć jak jest zoptymalizowana komunikacja. Czy szarpnąłbym się na zastosowanie produkcyjne u klienta ? Być może tak, chociaż coraz częściej klienci nie chcą kupować czarnych skrzynek, wolą kupić także kod źródłowy aby nie zamykać sobie drogi do rozwijania aplikacji – nie koniecznie będąc przywiązanym do jednej firmy – ewentualnie wprowadzać proste zmiany własnymi zasobami. W związku z tym interesują się tym, jakie technologie zostaną wykorzystane i Lazarus, ze względu na swoją niszowość nie koniecznie przypadłby im do gustu.

Niewątpliwą zaletą Lazarus-a jest wieloplatformowość niemalże 1 do 1. Bardzo łatwo możemy przygotować cały soft na Windows, a potem skompilować pod Linuxem i odpalić na maszynie Linux-owej. Z Makami nie jest już tak dobrze, ale podejrzewam że trzeba tylko włożyć trochę wysiłku, żeby poprawnie skonfigurować kompilator – mnie troszkę zabrakło motywacji, żeby powalczyć z tym dalej ;).

RZEmiosłoIT 2019 – garść wrażeń

2

Trzecia edycja podkarpackiej konferencji RZEmiosłoIT, poświęconej tematyce Software Craftmanship, przeszła w zeszły weekend do historii. Po raz trzeci miałem okazję uczestniczyć w tym ciekawym wydarzeniu.

Tym razem organizatorzy zdecydowali się zmienić miejsce, w którym odbywała się konferencja. W miejsce budynku znajdującego się Podkarpackim Parku Naukowo Technologicznym, uczestników konferencji ugościł tym razem rzeszowski hotel Bristol.

Trudno powiedzieć, czy zmiana lokalizacji wyszła na plus czy na minus. Zaletą poprzedniej lokalizacji był z pewnością wygodny, duży parking. Tym razem zmotoryzowani musieli szukać sobie miejsc do parkowania na rzeszowskich uliczkach, ze względu na położenie hotelu w ścisłym centrum – tuż przy rynku. Na szczęście w sobotę parkingi w Rzeszowie są bezpłatne i ja osobiście problemu ze znalezieniem miejsca parkingowego w bezpośredniej bliskości hotelu nie miałem. Podejrzewam, że dla osób które skorzystały z komunikacji masowej (np. pociąg) taka lokalizacja miała swoje zalety – w okolice Jasionki z centrum trzeba by było dodatkowo dojechać komunikacją miejską.

Rozkład samych sal konferencyjnych w hotelu nie jest do końca szczęśliwy. Sala główna jest niewspółmiernie duża w stosunku do dwóch pozostałych sal i np. na prezentacji Piotra Stapp-a, która odbywała się w mniejszej sali , było dość tłoczno i część zainteresowanych osób musiała stać. Podobnież część z barem kawowym nie była w żaden sposób oddzielona od sali głównej i osoby, które uczestniczyły w prezentacji, która skończyła się wcześniej przeszkadzały trochę osobom biorącym udział w prezentacji odbywającej się na sali głównej. Zaletą poprzedniego budynku była niewątpliwie separacja sal i wyraźne wydzielenie części „kawowej” od reszty. To jednak drobne niedociągnięcia i nie wpływają jakoś znacznie na obraz całości – a ten, podobnie jak to było w poprzednich latach, był pierwsza klasa.

W konferencji brało udział ponad 300 osób, tym bardziej wielkie uznania dla organizatorów za tak sprawne ogarnięcie całości.

Poniżej krótki opis wrażeń po prezentacjach, w których brałem udział. Ponieważ część prezentacji działa się równolegle, nie byłem w stanie być na wszystkich. Jestem jednak pewien że wkrótce w sieci pojawią się nagrania i będę mógł nadrobić pozostałe ciekawe tematy.

W tym roku keynote był bardzo techniczny. Być może wynikało to z pewnej zamiany pomiędzy prelegentami – według wstępnego planu ta prezentacja miała mieć miejsce pod koniec konferencji.

Pierwszą prezentację zaserwował Szymon Pobiega. Pod tytułem „Messages on the Outside, Messages on the inside” prelegent ukrył bardzo ciekawą, hipotetyczną historyjkę, w której dwa zespoły z różnym podejściem realizowały pewne zadanie. Poparte ciekawymi przykładami różne (pod względem stosowanej metodyki) podejścia sprowadzały się do problemów z przetwarzaniem wiadomości w systemie. Komunikaty się duplikowały, ginęły, zmieniały swoją kolejność a hipotetyczne zespoły próbowały sobie radzić z tymi coraz to nowszymi wyzwaniami. Bardzo ciekawa prezentacja, z interesującą narracją, skupiająca się na metodologiach pracy z przepływem i kolejkowaniem komunikatów.

Kolejną prezentacją, w której brałem udział to prezentacja kolejnego Szymona – tym razem Szymona Kulca zatytułowana „Monolity, mikroserwisy, funkcje i … dalsze kroki w nieznane”.

Po krótkim wprowadzeniu na temat różnych podejść stosowanych do wytwarzania oprogramowania Szymon zaprezentował case study swojego side project-u – platformy dla kursów internetowych. W kolejnych iteracjach Szymon prezentował ewolucję projektu, aż do momentu gdzie większość skomplikowanych i czasochłonnych zadań oddelegowana została do dedykowanych Saas-ów. Prezentacja dość ciekawa, przedstawiająca jak dużo możemy zyskać bazując na pewnych gotowych rozwiązaniach i jak dzięki temu zminimalizować zarówno ilość pracy jaką trzeba włożyć w projekt jak i zoptymalizować koszty.

„Orkiestracja to zło (konieczne)” to z kolei prezentacja Piotra Stapp-a. Prezentacja zgromadziła szeroką rzeszę zainteresowanych. Ze względu na gabaryty sali część osób stała. Prezentacja opierała się na Kubernetesie. Mogliśmy zobaczyć całkiem ciekawe, choć bardzo ogólne (co zrozumiałe, ze względu na ograniczenia czasowe) demo. Celem prezentacji bardziej wydawało się przedstawienie jak wiele problemów i skomplikowanych sytuacji pozwala uniknąć zastosowanie orkiestracji jako takiej i jak wiele można na niej zyskać. Trudno było się doszukać jednoznacznego dowodu dlaczego jest to tytułowe „zło”. Sam prelegent zapytany o to przez osobę z sali przyznał, że chodzi głównie o pewną trudność jaką niesie ze sobą sama poprawna konfiguracja np Kubernetesa.

Kolejną prezentację „Shell, tmux, vim – krótka historia o ostrzeniu piły” przedstawił Michał Borkowski. To była bardzo fajna prezentacja, przedstawiona z dużą dozą humoru. Utwierdziła mnie w przekonaniu jak dobrze jest czasem wrócić do korzeni i szlifować swoje umiejętności. Odniesienia do Karate Kid-a w kontekście Code Kata i innych wprawek, także związanych z bezwzrokowym pisaniem na klawiaturze, były bardzo celne. Ciekawa też była konfiguracja „własnego IDE” za pomocą narzędzi wspomnianych w temacie prezentacji – w wolnej chwili chyba sam się spróbuję tak pobawić.

Ostatnią z prezentacji – o Architekturze – poprowadził Jarosław Pałka. Dużo humoru jak zwykle. Próba zdefiniowania czym jest architektura, trochę o teorii systemów i systemach jako takich. Całość prezentacji jak zwykle obfitowała w wiele zlotych myśli i trafnych spostrzeżeń. Po raz kolejny słuchalem Jarka z wielkim zainteresowaniem – chylę czoła nad bogatym doświadczeniem i pragmatycznym podejściem do tworzenia softu.

Konferencję kończył panel dyskusyjny „Kto to jest senior developer ?”. Podobnie jak w zeszłym roku, jeden z prelegentów nie mógł dotrzeć (tym razem Łukasz Szydło) i miejsce jego prezentacji zajął właśnie panel dyskusyjny. Była to chyba najciekawsza część konferencji jednocześnie przynosząca dość interesujące wnioski. Ze względu na to, że nasza branża jest bardzo młoda tak naprawdę nie istnieją prawie żadne formy standaryzacji. Pomimo prób zdefiniowania kompetencji jakie powinien posiadać senior developer, jakie podejmowali uczestnicy panelu – trudno odnieść wrażenie, że ile osób tyle opinii a ostatecznie i tak o widełkach kompetencyjnych (często bardzo dziwnych) decyduje HR. Nazwa stanowiska jest tak naprawdę dość umowna i wydaje mi się, że przepaść pomiędzy osobami na stanowiskach seniorskich może być wręcz ogromna. Najbardziej podobała mi się definicja J. Pałki, że senior powinien być „ogarniaczem” – technologie są różne, ale pewne mechanizmy są dość uniwersalne i umiejętne poruszanie się w nich poparte doświadczeniem powinno być docenione.

To wszystko częściowo obrazuje także z jak dużym bałaganem zmagamy się w branży jako całości. Już od dość długiego czasu mam takie wrażenie. Ten bałagan nie tyczy się jedynie galimatiasu technologicznego ale także kompetencyjnego i często związanego z tym – płacowego. Oczywiście żyjemy (póki co) w realiach wolnego rynku i każda firma autonomicznie sama decyduje komu za co płaci – ale wyobrażam sobie jak trudnym orzechem do zgryzienia jest zrekrutowanie kogoś do zespołu o charakterze eksperckim.

Krótki podsumowując – było świetnie – w przyszłym roku też z pewnością przyjadę z biletem pre-early bird :).

WindowsForms, WPF i .Net Core

2

Stosunkowo niedawno Microsoft ogłosił, że zarówno WPF jak i Windows Forms otrzymają wsparcie w .Net Core 3. Postaram się w tym poście zastanowić co to tak naprawdę oznacza dla programistów, którzy rękami i nogami siedzą w desktop-ie. Sam się przecież do takich zaliczam.

.Net Core zaistniał w świadomości programistów już dosyć dawno. Wraz z nim pojawiła się możliwość tworzenia cross-platformowych aplikacji webowych i nie tylko. Aplikacje nie muszą już być hostowane na systemach Windowsowych, możemy równie dobrze hostować taką aplikację na Linuxie lub odpalić ją na systemie macOS. Wkrótce doczekamy się już wersji 3-ej, technologia ta jest na tyle dojrzała że używana jest już też z powodzeniem produkcyjnie.

Do napisania tego postu skłoniła mnie m.in. poniższa prezentacja z tegorocznego NDC – byłem bardzo ciekaw, co tak naprawdę zyskamy używając nowego .Net Core na desktopie. Przy okazji sama prezentacja jest sporym rodzynkiem – bardzo rzadko na konferencjach usłyszymy cokolwiek co tyczy się bezpośrednio desktopu.

Czy to wszystko oznacza, że możemy tworzyć w WPF i WinForms aplikacje dla Linuxa i macOS ?

No niestety nie. Zarówno Windows Forms jak i WPF są tak głęboko związane z ekosystemem Windows, że nie ma na chwilę obecną takiej możliwości. Zarówno aplikacje WPF jak i WindowsForms w połączeniu z .Net Core 3 odpalimy nadal jedynie na systemie Windows.

Co więc zyskamy ?

Z jednej strony niewiele, z drugiej być może jednak sporo. Przede wszystkim wydajność. Jak pokazuje przykład z prezentacji,  operacje na plikach działają dużo szybciej. Trzeba też wziąć pod uwagę, że na chwilę obecną stanowisko Microsoftu jest takie, że klasyczny .Net Framework będzie otrzymywał głównie maintenance a wszystko co innowacyjne trafiało będzie do Core. Czy taki stan rzeczy stanie się faktem ? Zobaczymy. Znane są przecież przypadki gdy giganci wycofują się jednak ze swoich decyzji – a jak będzie czas pokaże.

Drugą ciekawą cechą jest niezależność od zainstalowanej na maszynie wersji .Net Framwork. Możemy tworzyć aplikację, która będzie zawierać zintegrowany w sobie również sam framework .Net Core. Czy to jest dobre rozwiązanie ? Z jednej strony tak, bo nie zmuszamy użytkownika do doinstalowywania czy aktualizacji tego co już ma (lub nie ma). Z drugiej strony, pozbywamy się dobrodziejstw aktualizacji publikowanych przez Microsoft – a zawierających paczki poprawiające chociażby bezpieczeństwo. Nasza aplikacja nadal będzie działała na takiej wersji, jaką do niej spakowaliśmy a o ewentualny update będziemy musieli zadbać sami.

Co z narzędziami ?

Mamy dostępny CLI. Aplikację WPF od biedy możemy stworzyć w Visual Studio Code pisząc XAML. Z Windows Forms taka zabawa raczej odpada. Pełne wsparcie otrzymamy wraz z deisgnerami jest zapowiedziane dla Visual Studio 2019.

Czy warto się tym w ogóle przejmować ?

Szczerze mówiąc, chyba nie bardzo. Migrowanie istniejących – działających aplikacji jest trochę bez sensu. Tym bardziej, że może się zdarzyć, że pomimo zgodności kodu pewne funkcjonalności zachowają się inaczej i spędzimy sporo czasu testując i poprawiając działający projekt. Tworzenie nowych aplikacji z targetem dla .Net Core jest może nieco bardziej sensowne, chociaż nie jestem przekonany co do tego, że to już ten moment. Klasyczny .Net Framework będzie z nami jeszcze bardzo długo, biorąc pod uwagę jak bardzo integralną część systemu Windows stanowi. Ponieważ zarówno WPF jak i WindowsForms są głęboko związane z platformą Windows, pytanie czy warte to jest zachodu. Pewną przesłanką może być kwestia wydajności, ale bez konkretnych i wiarygodnych benchmark-ów trudno póki co mówić o rzeczywistym skoku jakościowym.

Nie da się ukryć, że pomimo bardzo fajnie wyglądających statystyk pokazanych w początkach wspomnianej wcześniej prezentacji, desktop stał się niszą. Zdecydowanie nie pomijalną, gdyż nadal znajdziemy wiele sytuacji w których aplikacja webowa czy mobilna nie ma zwyczajnie racji bytu – ale jednak niszą. Najlepiej możemy się chyba o tym przekonać zerkając na github. W repozytoriach najbardziej obiecujących projektów cross-platformowego desktopu ze świata .Net – Eto.Forms i Avalonia nie dzieje się tak wiele jak byśmy chcieli. Bardzo obiecująca Avalonia nadal jest w wersji beta i wiele funkcji (chociażby moduł renderujący podgląd na podstawie XAML w VS) działa dość średnio.