Siedlce.dev spotkanie branży informatycznej

Ważną częścią rozwoju programistów i osób związanych się wytwarzaniem oprogramowania jest wymiana doświadczeń, wiedzy i pomysłów z innymi. Tak ważny aspekt jak networking, może być częściowo realizowany online. Szczególnie w naszej branży, gdzie swobodnie posługujemy się nowymi technologiami, zaś wymiana informacji na czacie czy bycie ciągle online to coś normalnego. Ale nic nie zastąpi swobodnego spotkania twarzą w twarz. Daje to większe zaangażowanie, wspólne środowisko i więcej możliwości.

Dlatego organizowane są konferencje, warsztaty i różne spotkania. Szczególnie cieszy się tym branża IT. W większych ośrodkach takich jak Warszawa, Karków czy Wrocław nie ma problemu ze znalezieniem interesującego nas wydarzenia. Odbywa się ich przynajmniej kilkanaście w miesiącu, prawie codziennie coś się dzieje. Przykładowa baza z wydarzeniami IT to Crossweb.

Dlaczego nie lokalnie?

Częste wyjazdy do innego miasta wiążą się z pewnymi niedogodnościami, chociażby długi czas i męcząca podróż. Na większe wydarzenia np. Warszawskie Dni Informatyki lub InfoMEET przybywają słuchacze również z okolicznych miejscowości. Na te mniejsze już rzadko komu chce się jechać.

Dlaczego by nie robić wydarzeń również lokalnie? Otóż są. Przykładowo w Siedlcach:

  • konferencja Inżynieria Gier Komputerowych (IGK) – wydarzenie dla twórców gier komputerowych, towarzyszą im Siedleckie Targi Gier,
  • konferencja Współczesne Zastosowania Informatyki – przeznaczona do bardziej ogólnych tematów,
  • seminaria kół naukowych (np. Koła Naukowego Informatyków Genbit, Koła Naukowego Programistów) – zazwyczaj studenckie spotkania,
  • inne okazjonalne wydarzenia.

Jak widzimy nie ma tego dużo. Trochę brakowało zainteresowania lokalnej branży informatycznej, tak jak to jest w większych ośrodkach. Na szczęście się to jednak zmienia. Być może niektórzy już zauważyli, że warto wyjść do innych i zainwestować w społeczność, bo zamknięcie się tylko na siebie jest krótkowzroczne.

Wreszcie spotkanie dla programistów!

Powstało to czego brakowało w Siedlcach. Regularnych spotkań dla programistów z branży. Nisza wreszcie została częściowo zapełniona. Inicjatorami oraz organizatorami Siedlce.dev i bliźniaczego Podlasie.dev w Białej Podlaskiej są Rafał Muszyński i Karol Wójciszko. Rafał przed laty był organizatorem, już wspomnianej, konferencji Inżynierii Gier Komputerowych (którą po nim przejąłem na lata 2014-2015). Z pewnością mógł wykorzystać nabyte doświadczenie w organizacji takich wydarzeń. Karol prowadzi bloga wojciszko.com na temat zarządzania projektami, analizą i wytwarzaniem oprogramowania.

Pierwsza edycja już była

Pierwsza, pilotażowa edycja Siedlce.dev odbyła się 27 kwietnia 2017.

Relacje z wydarzenia:

Wystąpienia były trzy:

  • „SOLIDny kod” – Rafał Muszyński
    Każdy kto uczył się programowania obiektowego pewnie zetknął się z tymi pięcioma podstawowymi założeniami projektowania i pisania kodu (SOLID). Gdyby jednak wszyscy się do tego stosowali, to kod byłby piękny. Dlatego tak ważnych, prostych w założeniach, a jednocześnie trudnych do ciągłej realizacji, tematów nigdy za wiele.
  • „HTTP Cache – dlaczego/kiedy/jak?” – Paweł Mikołajczuk
    Czyli głównie omówienie Varnish Cache. Jak jakiś startup napisał aplikację bez optymalizacji, a serwera już przestaje wyrabiać, to można na szybko wrzucić to rozwiązanie. Oczywiście w normalnych sytuacjach również można je stosować z powodzeniem. Często nawet po prostu się powinno, trzeba tylko uważać co keszować, a czego nie.
  • „Twój pierwszy startup” – Karol Wójciszko
    Temat mniej techniczny, ale przydatny jeśli ktoś myśli o zakładaniu startupa, co od jakiegoś czasu stało się wręcz modne. Trzeba mieć dobry pomysł, żeby zaspokoić jakieś zapotrzebowanie rynku (nawet jeśli sami to zapotrzebowanie wytworzymy 😉 ). Pierwsze co przychodzi do głowy, to to, że rozwiązanie ma być przeznaczone dla użytkowników końcowych. Okazuje się jednak, że dużym polem do popisu dla startupów jest także rynek B2B, czyli rozwiązywanie problemów innych firm.

Na koniec kilka słów zabrała lokalna firma Tech-Media, która była sponsorem spotkania (darmowa pizza!). W wytwarzaniu oprogramowania, obecnie specjalizuje się głównie w PHP.

Można było też usłyszeć, że w Siedlcach planowane jest coś większego dla społeczności programistów i startupów tzn. biura coworkingowe i mentoring. Więcej informacji zapewne będzie wkrótce.

Drugie spotkanie Siedlce.dev

Pierwsze spotkanie cieszyło się dosyć dużą frekwencją (oczywiście jak na tej wielkości miasto). Na kolejnym, 1 czerwca 2017, nie było gorzej. Byli zarówno ci mający komercyjne doświadczenie, początkujący, studenci, jak również trafiały się osoby, które chcą się przebranżowić. Miejmy nadzieje, że będzie to wydarzenie cykliczne, a prelegentów, firm i słuchaczy nie zabraknie.

Ogłoszenie z agendą było dostępne standardowo na Facebooku w wydarzeniu.

Tak jak na poprzednim spotkaniu, tak i teraz były trzy wystąpienia:

„Testy i ich automatyzacja” – Bartosz Cholewiński

Na początku o podstawach testów. Są takie, które użytkownik testuje bez znajomości wnętrza aplikacji (czarna skrzynka) oraz takie, w której kod jest znany (biała skrzynka). Programista jest przywiązany do swojego kodu i zazwyczaj lepiej jest, gdy to ktoś inny ma go „popsuć” tzn. przetestować. Wiadomo, że ktoś z zewnątrz znajdzie więcej błędów, szczególnie takich, których do głowy podczas pisania kodu nie przyszły.

W sytuacji, gdy testów robi się coraz więcej, a praca coraz bardziej żmudna i powtarzalna nadchodzi czas na testy automatyczne np. takie, które automatycznie klikają w aplikacji webowej i sprawdzają zwrócony wynik na stronie. Można użyć do tego np. narzędzia Nightwatch.js. Korzysta ono z Selenium. Warto zainteresować się także PhantomJS i np. Headless Chrome. Testy w Nightwatch.js pisze się łatwo i przyjemnie. Początkowo trzeba poświęcić trochę czasu, ale potem można testować w sposób ciągły (np. podpiąć do Jenkinsa i prowadzić statystyki). Wybierać elementy na stronie w Nightwatch.js można za pomocą selektorów CSS (podobnie jak np. w jQuery) lub XPath (ma trochę więcej możliwości).

„Jak zacząć zarządzać projektem?” – Karol Wójciszko

Większość projekty nie jest kończona na czas i nie mieści się w ustalonym budżecie. Jest to często wina złego zarządzania projektem i niepełnej analizy projektu.

Trzeba poznać kilka zagadnień, żeby móc swobodnie poruszać się w temacie zarządzania projektami.

  • Czym się różni projekt od procesu? Projekt jest unikalny. Jeśli coś jest powtarzalne, to jest już proces.
  • Czym się różni cel od zakresu? Cel to korzyść, coś po co robimy projekt. Zakres to czynności, które należy wykonać, aby zrealizować cel.
  • Trójkąt projektu: zakres, czas i koszt. Nie możemy swobodnie zmieniać jednego parametru bez naruszania innych. Są ze sobą powiązane.

Czy warto robić analizę? Przecież to kosztuje… Okazuje się, że pisząc projekt bez wykonania analizy i tak ją robimy fragmentami w głowie podczas pisania kodu. Lepiej zrobić ją na początku raz a dobrze. Zaoszczędzimy czas, pieniądze i nerwy.

Dobra analiza powinna być negatywna, a nie pozytywna. Od reklamy jaki to projekt będzie dobry jest dział sprzedaży. Analitycy mają płacone za logiczne myślenie i ustalenie co da się zrobić. Lepiej powiedzieć klientowi na początku czego się nie da zrobić niż na końcu. Jak zgodzi się na założenia, które są bardziej realne, to po skończeniu projektu będzie miał większą satysfakcję. Po prostu spełni to jego oczekiwania.

Jak wycenić projekt? Oprócz czasu, można użyć dwóch parametrów: czasochłonność i skomplikowanie. Przepisanie danych do Excela będzie czasochłonne, ale nie skomplikowane. Wymyślenie jakiegoś algorytmu może być mało czasochłonne (przecież to tylko kilka linii kodu), ale jest mocno skomplikowane. Parametr „skomplikowanie” mówi nam jakie jest ryzyko. To właśnie tutaj może coś się nie udać lub zająć dużo więcej czasu niż przewidywaliśmy.

Jednym z typów zadań, które są ryzykowne to zadania „worki”. Jeśli coś jest opisane na bardzo wysokim poziomie abstrakcji, to może okazać się, że składa się tak naprawdę z wielu zadań. Powoduje to, że projekt jest bardziej skomplikowany, bo nie wiemy co dokładnie ma robić. Przez to rośnie ryzyko niepowiedzenia projektu lub przekroczenie zaplanowanego czasu albo kosztów. Takie zbiorcze zadania należy zidentyfikować i zdekomponować (podzielić) na mniejsze. Jedno zadania powinno rozwiązywać jeden problem. Po podzieleniu zadań często okazuje się, że estymowany czas i koszt zwiększa się, zbliżając się tym do tego rzeczywistego (przypominam, że większość projektów przekracza termin i budżet).

„BDD – change your thinking” – Radek Osak

BDD czyli Behavior Driven Development. To podejście w wytwarzaniu oprogramowania wyrosło na TDD (Test Driven Development) czyli pisaniu najpierw testów, a dopiero potem kodu, który przejdzie napisane testy. Dzięki temu wiemy co dokładnie kod ma zrobić, kiedy jest gotowy i… magicznie mamy gotowe testy, które normalnie nie zawsze się pisze.

Opis zadań opiera się na zdaniach sformułowanych za pomocą trzech słów:

  • W celu (co chcesz osiągnąć, po co coś robić)
  • Jako (kto? interesariusz, nie klient, który jest aktorem)
  • Chcę (co zrobić)

W pierwszym wyrażeniu „w celu”, nie należy mylić celu (do czego dojść) z zakresem (jak dojść).

Analiza powinna być jak najkrótsza, ale treściwa. W tym pomaga opis za pomocą BDD. Istnieje do tego specjalny język Gherkin. Tak przygotowany opis zadań (wykonana analiza) można wykorzystać do automatycznego testowania oprogramowania. Służy do tego narzędzie cucumber.

Dzięki takiemu podejściu, wykonana dokumentacja podczas analizy jest bardziej zwięzła (chociaż ja uważam, że czasem potrzebny jest dodatkowy opis). Dokumentacja sporządzona przez analityków służy do testowania projektu. Jest bliższa programistom. BDD ma ułatwić komunikację.

Oczywiście testerzy nadal są potrzebni. Nie wszystko da się przetestować takim opisem zadań. Przykładowo, często potrzebne są testy, które sprawdzają jak wygląda aplikacja.

Britenet

Firma Britenet była sponsorem tego spotkania (pizza!). Co ciekawe w 2015 i 2016 została wytypowana w rankingu AudIT, prowadzonym przez Computerworld, za najlepsze miejsce pracy IT w Polsce. Jak to duże firmy, szczególnie te skupione na outsourcingu, pracują w wielu różnych technologiach (w tym ostatnio coraz popularniejsze Salesforce).

Kolejne spotkania

Szykują się kolejne spotkania. Miejmy nadzieję, że jeszcze w czerwcu (najpewniej w któryś czwartek). Obecnie trwa nabór prelegentów.

Na fanpage na Facebooku Podlasie.dev pojawiają się aktualne informacje. Jeśli ktoś ma jakieś ciekawe doświadczenia lub idee warte rozpowszechniania (trochę jak idea TED), to zachęcam do zgłaszania się do aktywnego uczestnictwa.

Istnieje również grupa na Facebooku Siedlce.dev, na której można pogadać z lokalną społecznością programistów z Siedlec i okolic.

6 responses on “Siedlce.dev spotkanie branży informatycznej

  1. Afterweb

    No niestety Wschód ma to do siebie ze mało się dzieje z meetup’ów;/ Niestety zawsze musiałem jeździć do Wwa. Sam planowałem w swoim mieście czyli BP zacząć przygodę z tworzeniem takich wydarzeń. Jednak wyjechałem do większego miasta żeby mieć większą styczność z IT. Szkoda ze wschód jest trochę ograniczony co do IT w sensie mało jest firmy które mogły by zatrzymać tam osoby na dłużnej.

  2. Informatyka

    Dzięki za wpis. Bardzo podobało mi się rozdzielenie między „czasochłonnością”, a „skomplikowaniem”. To może posłużyć nawet jako argument przy wycenianiu projektu i uzasadnianiu skąd wzięła się cena X. Za czasochłonność się płaci – w końcu potrzebny jest czas. A za skomplikowanie… się również płaci. W końcu potrzebna jest konkretna wiedza.

Skomentuj Krzysiek Hostyński Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *