PAWEŁ STREJCZEK

Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – protokół S7 i konfiguracja sterownika

.Net
TECH

PStrejczek

-

2017-07-31

Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – protokół S7 i konfiguracja sterownika

Witaj w kolejnej części cyklu o bibliotekach .Net do komunikacji ze sterownikami Siemens-a. Zajmiemy się dzisiaj pokrótce samym protokołem komunikacyjnym oraz niezbędną konfiguracją po stronie sterownika (w przypadkach gdy jest takowa potrzebna).

Do niedawna niekwestionowanym królem w świecie Siemens-a jeżeli chodzi o komunikację PC-PLC był standard Profibus/Mpi. Komunikacja ethernetowa była oczywiście dostępna, ale w przypadku niższych modeli sterowników wymagała dokupienia specjalistycznego procesora komunikacyjnego. W najnowszych seriach sterowników 1200 i 1500 ethernet jest już standardowo na pokładzie.

W tym cyklu będziemy się zajmować jedynie komunikacją ethernetową. Zestawienie komunikacji Profibus/Mpi wymagło by zakupu dodatkowej karty pośredniczącej lub konwertera Profibus/Mpi – Ethernet (np. takiego). Problem ten dotyczy głównie sterowników starszych i pewnych specyficznych układów, gdzie z różnych względów nie można zastosować ethernetu.

PROTOKÓŁ S7

Komunikacja w świecie sterowników Siemens bazuje na tzw. protokole S7. Protokół ten, w warstwie ethernetowej bazuje na standardzie ISO over TCP. Poszczególne bloki nazywane są tutaj PDU (Protocol Data Unit) a ich długość zależy od CPU lub procesora komunikacyjnego realizującego komunikację po stronie sterownika i jest negocjowana w trakcie nawiązywania połączenia (rozmiar mieści się w zakresie 240 – 960 bajtów). W przypadku gdy przesyłana ilość danych przekracza wynegocjowaną długość PDU, wiadomość jest odpowiednio dzielona.

Protokół S7 bazuje na komendach. Każda ramka zawiera albo komendę wysyłaną do sterownika albo odesłaną odpowiedź. Komendy mogą dotyczyć zapisu/odczytu danych z bloków, sterowania stanem sterownika, odczytu parametrów konfiguracyjnych czy też funkcji związanych z bezpieczeństwem. Wszystkie biblioteki, które będę tu opisywał implementują w postaci odpowiednich metod te komendy.

Protokół S7 nie jest niestety opisany w żadnej oficjalnej dokumentacji Siemens-a. Jeżeli chcielibyśmy się pokusić o własną implementację to pozostaje jedynie podsłuchiwanie np. za pomocą Wireshark komunikacji (nota bene posiada on specjalny plugin filtrujący jedynie komunikację S7) lub analiza kodu istniejących bibliotek.

Warto tutaj nadmienić, że ze względu na pewne zaszłości związane z architekturą sprzętową formaty danych w sterowniku różnią się od tych, z którymi mamy do czynienia w przypadku systemów komputerowych. W przypadku liczb mamy do czynienia z tzw. notacją Big Endian. W notacji tej najbardziej znaczący bajt zapisywany jest jako pierwszy. W przypadku rodziny x86 z którą mamy do czynienia w przypadku klasycznych komputerów stosowaną notacją jest Little Endian – najmniej znaczący bajt jest zapisywany jest jako pierwszy. W specyficzny sposób zapisywane są również formaty daty i czasu oraz stringi. Większość bibliotek komunikacyjnych ma odpowiednie funkcje związane z konwersją tych formatów.

PARAMETRYZACJA STEROWNIKA

W przypadku sterowników S7-300 i S7-400 a także starych S7-200 i LOGO mamy do czynienia z klasyczną implementacją protokołu S7. Żadna dodatkowa parametryzacja (oczywiście poza konfiguracją adresu IP, bramy itp. ) nie jest tu potrzebna, aby skorzystać z biblioteki komunikacyjnej.

W przypadku sterowników S7-1500 i od pewnego czasu S7-1200 mamy do czynienia z rozszerzoną wersją protokołu S7, związaną z kodowaniem komunikacji ze względu na zaimplementowane funkcje bezpieczeństwa. Kodowana komunikacja nie jest póki co obsługiwana przez żadną ze znanych mi bibliotek. Możemy jednak zmusić te sterowniki do pracy w trybie protokołu zgodnym z serią 300/400. Warto jednak mieć na uwadze, że rezygnacja z funkcji zabezpieczających może mieć pewne realne konsekwencje, warto więc zastanowić się jak można w inny sposób zabezpieczyć system sterownikowy przed niepowołanym dostępem.

Dodatkowo w przypadku sterowników 1200 i 1500 mamy do czynienia z nowym formatem bloków danych (tzw. optymalizowanym) gdzie adres odpowiedniej zmiennej jest dynamiczny a do samej zmiennej programując sterownik odwołujemy się po jej nazwie. Jeżeli chcemy czytać takie dane, blok w którym się one znajdują musi być oznaczony jako nie optymalizowany – musimy znać konkretny adres zmiennej aby się do niej odwołać.

Należy dodatkowo wyłączyć wszystkie funkcje bezpieczeństwa i zezwolić na realizację komunikacji PUT/GET.

Warto pamiętać również o tym, że w każdym z w/w przypadków nawiązując połączenie musimy poprawnie podać numer kasety (rack) oraz pozycję (slot) , w której znajduje się CPU. W zależności od rodziny sterowników wygląda to nieco inaczej:

W kolejnej części przejdziemy do opisu pierwszej z bibliotek.

Wszystkie posty w tym cyklu:

Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – wstęp
Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – protokół S7 i konfiguracja sterownika
Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – projekty testowe
Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – biblioteka s7netplus
Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – biblioteka Sharp7 (Snap7)
Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – biblioteka DotNetSiemensPlcToolboxLibrary

Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – wstęp

.Net
TECH

PStrejczek

-

2017-07-25

2

Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – wstęp

Tym postem chciałbym dać początek krótkiej serii opisującej biblioteki .Net do komunikacji ze sterownikami PLC Siemens.

Tematyka jest co prawda trochę niszowa, ale skutkuje to również brakiem szerszej informacji na ten temat w sieci. Ponieważ mam sporo doświadczenia w realizacji tego typu komunikacji w .Net chciałem się nim nieco podzielić zarówno w kwestii doboru biblioteki komunikacyjnej jak i dobrych praktyk, które udało mi się wypracować zajmując się tą tematyką.

Sterowniki PLC Siemens Simatic są jednymi z najczęściej spotykanych w przemyśle nie tylko w Polsce ale i w Europie. Bardzo często są również wykorzystywane na zajęciach akademickich do nauki programowania – szczególnie najprostsza i najbardziej atrakcyjna cenowo seria LOGO.

W wielu układach automatyki, zarówno tej domowej jak i tej przemysłowej, sam sterownik wystarcza do realizacji wszystkich zadań. Często jednak pojawia się potrzeba wizualizacji danych, parametryzacji i sterowań na żądanie. Te zadania możemy zrealizować za pomocą dedykowanego, łatwo konfigurowalnego panela operatorskiego, jednak koszt jego zakupu jest zwykle dość spory, i szczególnie w małych układach, może przekroczyć koszt zakupu samego sterownika.

W dzisiejszych czasach, gdy mamy do czynienia z coraz większym wzrostem popularności tzw. Internet Of Things, chcemy często też dane ze sterownika rejestrować np. w chmurze by potem je prezentować w sieci i tutaj panel operatorski już nam nie pomoże. Idealne jest w takim układzie wykorzystanie komputera i oprogramowania, które pomoże nam te dane ze sterownika wyciągnąć (jednocześnie pozwalając na ich wizualizację, parametryzację procesu czy też sterowanie nim na żądanie) i następnie w dowolny sposób zarejestrować czy też obrobić.

Bardzo popularną metodą wymiany danych ze sterownikami jest wykorzystanie protokołu Modbus. Jest to standard funkcjonujący od wielu lat w automatyce, wspierany w lepszym lub gorszym stopniu przez praktycznie wszystkich producentów sterowników. Minusem wykorzystania protokołu Modbus jest jednak konieczność przeprowadzenia odpowiedniej konfiguracji lub wręcz oprogramowania jej po stronie sterownika. W tym cyklu postów nie będziemy się zajmować tym protokołem.

Proponowanym przez wielu producentów sterowników, w tym przez Siemens-a, mechanizmem wymiany danych jest standard OPC. W chwili obecnej w coraz większej ilości przypadków mamy do czynienia ze standardem OPC UA. Serwer OPC jest niejako pośrednikiem pomiędzy urządzeniem (w tym przypadku sterownikiem) a systemami odczytującymi i zapisującymi dane do sterownika. Już wkrótce w najnowszej wersji sterownika Siemens S7-1500 serwer OPC UA ma być zaimplementowany w samym sterowniku – jest to bardzo obiecujące rozwiązanie i być może przyszłość realizacji komunikacji pomiędzy sterownikiem a światem zewnętrznym.

Z moich doświadczeń z OPC wynika jednak, że taka wymiana danych jest stosunkowo mało efektywna. Wykorzystanie dodatkowej aplikacji serwera OPC powoduje ograniczenia w czasowej wydajności komunikacji przez co nie do końca nadaje się np. do realizacji sterowań na żądanie, gdzie wymagana jest natychmiastowa odpowiedź systemu na zadane sterowanie. Spokojnie jednak serwer OPC można wykorzystać np. do cyklicznej rejestracji danych.

Ostatnią z metod komunikacji jest komunikacja bezpośrednia. Protokół komunikacyjny implementowany przez sterowniki Siemens jest dość złożony, trudno więc się porywać na własną jego implementację (aczkolwiek jest to oczywiście przy odrobinie wysiłku możliwe). Istnieje natomiast szereg bibliotek Open Source o mniej lub bardziej restrykcyjnych licencjach, które znacznie ułatwiają zarówno wymianę danych jak i konwersję formatów. Z kilkoma z tych bibliotek miałem do czynienia i stosowałem je w środowisku produkcyjnym. Postaram się je w kolejnych postach przedstawić wskazując na ich zalety i wady. Przygotuję też proste projekty do ich testowania (ich uruchomienie będzie jednak oczywiście wymagało posiadania fizycznego sterownika, z którym będzie można wymieniać dane).

Sterowniki S7-1200 i S7-1500 przyniosły pewną rewolucję w warstwie komunikacji. Ze względu na wprowadzenia różnego rodzaju zabezpieczeń (których genezą jest prawdopodobnie zagrożenie wywołane kilka lat temu przez wirusa Stuxnet) protokół komunikacyjny, w momencie włączenia w/w funkcji bezpieczeństwa, uległ zmianie i wtedy nie jest możliwe wykorzystanie opisywanych tu bibliotek. W takiej sytuacji konieczna jest odpowiednia parametryzacja samego sterownika, aby umożliwić odczyt i zapis danych przez aplikację zewnętrzną. Sposobem konfiguracji sterownika, pozwalającym na dostęp do niego z aplikacji .Net korzystających z opisywanych bibliotek zajmę się w kolejnym poście.

Warto mieć na uwadze, że jedną z lepszych metod zapewnienia bezpieczeństwa jest zastosowanie separacji sieci chociażby przez wykorzystanie w komputerze dodatkowej karty sieciowej dedykowanej jedynie do komunikacji ze sterownikiem.

Wszystkie posty w tym cyklu:

Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – wstęp
Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – protokół S7 i konfiguracja sterownika
Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – projekty testowe
Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – biblioteka s7netplus
Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – biblioteka Sharp7 (Snap7)
Biblioteki .Net do komunikacji ze sterownikami PLC Siemens – biblioteka DotNetSiemensPlcToolboxLibrary

XAML Standard i o standaryzacji słów kilka

.Net
TECH

PStrejczek

-

2017-07-05

0

XAML Standard i o standaryzacji słów kilka

Podczas ostatniego Microsoft Build zaanonsowano powstanie dwóch nowych pojęć. Mowa tu o .Net Standard 2.0 i XAML Standard 1.0.

.Net Standard obecny był już od jakiegoś czasu a obecnie anonsowana jego wersja 2.0 ma zapewnić bardziej rozbudowany zakres API wspólnego dla wszystkich wspieranych przez .Net platform. Nie będę się tutaj rozwodził nad zakresem możliwości jakie daje .Net Standard 2.0. Zainteresowanych odsyłam do tego blog post-a na MSDN.

Zaproponowany XAML Standard jest zupełną nowością. XAML jest opartym na XML-u językiem definiowania interfejsu użytkownika. Pojawił się on w technologiach .Net-owych wraz z pojawieniem się WPF, które miało zastąpić wcześniejszą technologię – Windows Forms.

Jak dobrze wiemy Forms-y żyją do dzisiaj i mają się całkiem nieżle. Nadal są technologią bardzo często wybieraną przy tworzeniu aplikacji desktopowych. Jest to szczerze mówiąc trochę dziwne, biorąc pod uwagę możliwości jakie daje WPF, ale być może po prostu łatwiej jest „sklikać” interfejs w designerze niż przygotować go za pomocą XAML-a. O Formsach nie zapomniał również sam Microsoft, dodając niedawno wsparcie hi-dpi dla Windows Forms

Wróćmy jednak do tematu. XAML-a obecnie spotkamy w WPF, w UWP, w Xamarin Forms oraz w Silverlight, chociaż ta ostatnia technologia jest już w zasadzie martwa. Każdy z tych XAML-owych targetów używa innego zestawu kontrolek, innego zestawu parametrów i nieco innych mechanizmów. O ile inne zestawy kontrolek są zrozumiałe – mamy przecież do czynienia z różnymi platformami, to inne funkcjonowanie części mechanizmów lub ich brak na niektórych platformach jest trochę trudny do zrozumienia.

Zdecydowanie najbardziej rozwinięty XAML spotkamy w WPF. Programista WPF nie będzie czuł się zupełnie obco tworząc interfejs np. w Xamarin Forms, ale napotka kilka problemów. Wspominałem o tym w jednym z wcześniejszych postów.

Sama idea standaryzacji jest świetna. Tworząc jakiś czas temu aplikację własnie w Xamarin Forms bardzo żałowałem, że nie ma jakiegoś większego stopnia ujednolicenia. Jestem w stanie sobie wyobrazić wspólny XAML, który pozwoli może nie koniecznie przenosić aplikacje pomiędzy platformami tylko kompilując pod inny target (przy zachowaniu .Net Standard) ale pozwoli programiście dużo łatwiej poruszać się pomiędzy platformami. Wdrożenie i poznanie obu tych standardów spowoduje że programista desktop będzie praktycznie z marszu programistą mobilnym i odwrotnie (oczywiście do pewnego tylko stopnia, pewne specyficzne dla platfrom kwestie nadal trzeba będzie z pewnością rozwiązywać na poziomie platformy – nie spodziewam się, żeby Apple, Microsoft i Google kiedykolwiek próbowali się dogadywać odnośnine standaryzacji mechanizmów stosowanych w swoich systemach desktopowych i mobilnych).

Na chwilę obecną XAML Standard jest w powijakach. Na github znajdziemy listę propozycji tego, co mogłoby być częścią standardu otwartą do dyskusji. Znajdziemy draft zawierający wstępne propozycje. Znajdziemy też pierwszy milestone zawierający zaakceptowane propozycje.

Fajnie, że tematyka tej standaryzacji jest dyskutowana w community ale wydaje mi się, że sprawa nie nabrała jeszcze wystarczającego rozpędu. Miejmy nadzieję, że wkrótce przyspieszy i zestandaryzowany XAML stanie się popularny i szeroko wykorzystywany. Fajny byłby np. Xaml-owy wrapper dla jakiegoś frameworka Javascript + Bootstrap. Opisanie za jego pomocą interfejsu webowego i „zbindowanie” go z backendem mogłoby być bardzo ciekawe.

Ostatnie lata to bardzo duży podział specjalizacji jeżeli chodzi o programistów. Główną przyczyną oczywiście jest złożoność i skrajna różnorodność technologii dla platform. Być może wprowadzenie standaryzacji jest pierwszym krokiem do tego aby ten podział zacierać.

Jedno jest pewne. Jeżeli tylko te idee nie stracą swojego rozpędu to czekają nas ciekawe czasy. Nie mogę się tego doczekać 🙂

MVVM i XAML w Visual Studio 2015 – Jacek Matulewski – recenzja książki

Recenzje książek

PStrejczek

-

2017-06-18

0

MVVM i XAML w Visual Studio 2015 – Jacek Matulewski – recenzja książki

WSTĘP

Na rynku wydawniczym nie ma w tej chwili wielu książek poruszających tematykę XAML-a w WPF. Aplikacje desktopowe są w tej chwili w zdecydowanym odwrocie na korzyść aplikacji webowych i nic nie zapowiada, aby w najbliższej przyszłości miało się to istotnie zmienić.

Z XAML-em w podejściu MVVM spotkamy się również w przypadku pisania aplikacji mobilnej z wykorzystaniem Xamarin Forms. Ale Xamarin-owy XAML różni się mocno od tego, który mamy w tej chwili w WPF (nieco bardziej przypomina XAML znany z zapomnianego już dziś Silverlight).

Pewne nadzieje można wiązać z obwieszczonym podczas Build 2017 XAML Standard, ale wszystko jest nadal w trakcie opracowania. Można to obserwować w tym repozytorium

Biorąc pod uwagę powyższe fakty, cieszy mocno obecność pozycji poświęconej tematyce XAML w ujęciu MVVM właśnie w kontekście WPF. Cieszy tym bardziej, że jest to pozycja polskiego autora a nie tłumaczenie (których to jakość bywa mocno dyskusyjna).

Książka ma niewiele ponad 300 stron. To niedużo, biorąc pod uwagę zakres materiału jakiego dotyczy.

Autor zaczyna od zwięzłego wstępu do samego XAML-a, by przez definicję wzorca MVVM przejść do jego implementacji. Przeczytamy więc o modelu i viewmodelu, wiązaniu danych, konwerterach, poleceniach, attached property i dependency property aż po zaawansowaną tematykę związaną ze stylami i animacjami. I to wszystko w ujęciu MVVM !. Znalazło się nawet miejsce na rozdział o testach jednostkowych.

RECENZJA

W pierwszej części autor przedstawia konwersję prostej aplikacji, której kod mamy w całości w code-behind, do wersji w której wszystko przygotowane jest zgodnie z wzorcem MVVM. Druga część to już tematy zaawansowane jak np. szablony kontrolek. W trzeciej przeczytamy o Universal Apps.

Książka napisana jest stosunkowo nietrudnym językiem, trzeba ją czytać jednak ze sporą uwagą bo wiedza jest bardzo skondensowana i nie trudno przegapić ważny fragment.

Szkoda trochę, że autor nie pokusił się o chociaż ogólny opis bibliotek MVVM Light i Prism (albo przynajmniej jednej z nich) np. zamiast części o Universal Apps. W większości przypadków, gdy rozmiar aplikacji i przewidywany cykl jej życia powoduje, że decydujemy się na MVVM będziemy jednak chcieli skorzystać z którejś z tych bibliotek zamiast implementować pewne mechanizmy na piechotę.

W kliku miejscach znajdziemy również informacje o tym, że pewne zagadnienia wykraczają poza ramy publikacji. Trochę szkoda, jednak ze względu na gabaryty książki jest to zrozumiale.

PODSUMOWANIE

Ponieważ na rynku wydawniczym brak jest dobrych pozycji na temat XAML-a i MVVM polecam zakup tej książki zainteresowanym tą tematyką osobom.

Nie można jej jednak traktować jako książki dla rozpoczynających przygodę z WPF. Zdecydowanie lepiej zacząć od jakiegoś prostego kursu czy zwyczajnej zabawy z kontrolkami na podstawie tutoriali znalezionych w sieci. Książka nie porusza tematów związanych np. z layoutami, których dobra znajomość jest kluczowa przy przygotowywaniu interfejsu. Bardziej skupia się na implementacji MVVM od strony modelu i viewmodelu niż samego widoku.

Dla osób, które mają już pewne pojęcie o XAML-u będzie to bardzo dobra pozycja prezentująca skondensowaną wiedzę, po którą łatwo jest sięgnąć również w odniesieniu do konkretnego problemu.

Zdecydowanie bardziej warto zaopatrzyć się w tę pozycję, niż w WPF 4.5 Księga eksperta, które w polskim tłumaczeniu jest kompletnie nie zjadliwe.

Książkę wydało wydawnictwo Helion.

Rzemiosło.IT – garść wrażeń

FELIETONY

PStrejczek

-

2017-06-11

4

Pierwsza podkarpacka konferencja Rzemioslo.it o tematyce Software Craftmanship odbyła się 27.05.2017 w Rzeszowie.

Ponieważ mieszkam w odległości niecałych 100km od Rzeszowa szkoda nie było skorzystać z możliwości udziału, tym bardziej że przedsprzedażowe bilety były w cenie dobrej kawy. Lista prelegentów również przedstawiała się bardzo interesująco.

TL;DR;

Było super. Jeżeli planujesz już swój kalendarz konferencji na przyszły rok zdecydowanie umieść tam Rzemiosło.It. Uważam, że naprawdę warto !.

LOGISTYKA

Konferencja odbywała się w Podkarpackim Parku Naukowo-Technicznym Aeropolis w Jasionce pod Rzeszowem. Z mojego punktu widzenia lokalizacja została wybrana doskonale. Obiekt znajduje się poza centrum miasta i jest doskonale skomunikowany z autostradą (dosłownie niecałe 5 minut od zjazdu). Znajduje się też w bezpośredniej bliskości lotniska. Dużym atutem jest spory parking, nie było więc problemu z zaparkowaniem samochodu (ja nawet miałem miejsce pod dachem, który okazał się też być baterią ogniw słonecznych 🙂 ).

Nie bez znaczenia był również sobotni termin, nie wymagający kombinowania z urlopem.

Konferencja organizowana była po raz pierwszy, ale organizatorzy staneli na wysokości zadania. Wszystkie kwestie związane z rejestracją, kawką, cateringiem, organizacją sal i pilnowaniem harmonogramu były dopięte na ostatni guzik.

PRELEKCJE

Keynote konferencji należał do Piotra Stapp. Pod ciekawym tytułem prezentacji „Od juniora do seniora czyli tam i z powrotem. Jak kierować swoją karierą na przykładzie własnym i znajomych” kryła się garść doświadczeń zawodowych, którymi prelegent zechciał się podzielić. Bardzo fajnie było posłuchać o drodze zawodowej programisty w innej gałęzi branży niż moja. Ciekawe wnioski, okraszone humorem z pewnością dają nieco do myślenia i muszę przyznać, że była to wartościowa prezentacja zarówno dla programisty posiadającego już pewien bagaż doświadczeń jak i zapewne dla osób dopiero stawiających pierwsze kroki zawodowe w świecie kodu.

Szymon Kulec w prezentacji „The only thing that matters” zaprezentował techniczne mięcho w najlepszym tego słowa znaczeniu. Bazami danych zajmuję się w jakimś tam zakresie od dawna (pewnie z resztą jak każdy programista) ale tak głęboko w tematykę nie wchodziłem nigdy. Bardzo ciekawe były informacje odnośnie działania Kafki jak i Event Store, o którym przyznam, że wiedziałem tylko tyle że jest :).

O tym „Co grzyie świadomego programistę DDD” mówił Sławomir Sobótka. Przyznam, że na tę prezentację czekałem najbardziej, nie tyle ze względu na tematykę co na samą osobę prelegenta. Wiele wystąpień Sławka oglądałem na youtube i jestem pod wielkim wrażeniem jego umiejętności prelegenckich. Tematyka DDD nie jest mi szczególnie bliska, a prezentacja była raczej ukierunkowana na osoby, które w tej tematyce poruszają się swobodnie. Nie mniej jednak udało mi się tam również znaleźć coś dla siebie. Na pewno w pamięci pozostało mi zdanie „Jesteś zasobem, uświadom to sobie” pochodzące z przykładu bazującego na działaniach HR :).

O Elixirze opowiadał Jakub Gutkowski. To była naprawdę dobra techniczna prezentacja w formie wprowadzenia dla osób, które z tym językiem nie miały do tej pory do czynienia (czyli np. ja 🙂 ). Gutek porównał ten język z innymi językami funkcyjnymi i przedstawił sporo przykładów. Wyniosłem z tej prezentacji to co chciałem – wiem co to jest Elixir, z grubsza biorąc wiem ile czasu zajmuje przygotowanie środowiska, wiem gdzie szukać i od czego zacząć gdybym kiedys potrzebował z niego korzystać.

Równolegle do prezentacji Gutka odbywała się prezentacja o tym „Dlaczego warto „skakać” pomiędzy technologiami”, którą prowadził Namysław Jerzy Szymaniuk. Na niej niestety nie byłem.

O trudnościach na linii programista-PM, PM-klient opowiadali Hubert Zub i Marcin Bartoszuk w prezentacju zatytułowanej „Dlaczego programiści nie rozumieją wymagań”. Świetne były scenki w formie kabretowej przedstawiającej perypietie programisty, jego szefa i klienta. Trudno jednak określić do kogo była adresowana tak naprawdę ta prezentacja a pokazane problemy nie były niczym nowym z punktu widzenia dev-a. Generalnie był to fajny humorystyczny przerywnik ale dla mnie bez większej wartości merytorycznej

Ostania prezentacja należała do Jarosława Pałki, który zdecydowanie zawładnął sceną. Duża doza humoru i ogromne doświadczenie, którym Jarek się podzielił zrobiły na mnie wrażenie. Jest coś takiego w mentalności dev-a, że chętnie się słucha o bałaganie i fakapach w innych organizacjach, ale też warto z tego wyciągać wnioski i ciągle windować jakość swojej pracy nie zapominając jednak o zdrowiu swojej kariery zawodowej.

PODSUMOWANIE

Jeżeli dobrnąłeś do końca tego tekstu pewnie już wiesz, że konferencja bardzo mi się podobała. Poza świetną organizacją, prelekcje również okazały się ciekawe i wartościowe. Duże gratulacje dla chłopaków z Rzeszowa za tak profesjonalną organizację tak dużego eventu. Do zobaczenia w przyszłym roku w Rzeszowie !