Od programisty PHP do założyciela ADV Digital

Strona główna » Od programisty PHP do założyciela ADV Digital
2+
PHP

Nastawienie na ciągły rozwój, głód technologii i praca pod presją czasu – to między innymi te elementy pomogły Maciejowi Kobuszewskiemu, który zaczynał jako programista PHP, a obecnie prowadzi swoją firmę ADV Digital. W wywiadzie dla Twilit opowiedział o swojej drodze oraz wyzwaniach w pracy.

Twoja kariera zawodowa zaczęła się w 2008 roku, pracowałeś jako regularny PHP programista. Po 9 latach zostałeś założycielem firmy ADV Digital. Jak wyglądała droga do tego momentu?

 Na początku zwyczajnie. Zaraz po tym, jak rzuciłem na drugim roku studia, rozpocząłem pracę jako programista PHP w małym software house. Tam w ciągu 6 lat przeszedłem ścieżkę do Solutions Architecta, po czym zacząłem rozglądać się za czymś innym. Chyba każdy po takim czasie potrzebuje jakiejś zmiany, a w tamtej firmie nie widziałem już nadziei na nic nowego, ekscytującego.

Wtedy trafiłem do startupu, gdzie miałem kierować małym zespołem i stworzyć MVP produktu do inbound marketingu. W tamtym czasie nie było to trudnym zadaniem, ani  dużym wyzwaniem, ponieważ zajmowałem się takimi rzeczami w poprzedniej firmie na co dzień. Jednak praca spodobała mi się ze względu na to, że dostałem praktycznie nieograniczoną swobodę w doborze technologii, wyborze zespołu i sposobu prowadzenia projektu.

Dzięki zaufaniu moich szefów mogłem skupić się na budowaniu aplikacji według ustalonych założeń. W ten  sposób po kilku miesiącach powstał nowoczesny i innowacyjny jak na tamte czasy produkt, który stopniowo zdobywał uznanie klientów, jednak wskutek pewnych problemów w spółce inwestora, spółka ta rozpadła się, a ja dostałem propozycję pracy w powiązanej firmie ADV Experience.


 Gdy zaczynałem tam pracę nie do końca było wiadomo czym będę się zajmował, ponieważ ADV działało głównie na rynku reklamy wizualnej, więc raczej nie spodziewałem się dużych, ambitnych projektów softwarowych.  Po kilku tygodniach, dostaliśmy od jednego z naszych klientów prośbę o przygotowanie koncepcji i prototypu urządzenia typu self-service – kiosku do zamawiania jedzenia na stacjach benzynowych.

Była to duża odmiana w porównaniu do tego co robiłem do tej pory. Projekt był wielopłaszczyznowy: trzeba było napisać software, przygotować urządzenia od strony elektroniki i sysops, a na koniec  to “opakować” w  obudowę, żeby faktycznie przypominało to kiosk.

Jakby tego było mało, jeszcze na etapie analizowania wymagań dostaliśmy zapytanie, czy uda nam się to wszystko przygotować w 3 tygodnie 🙂  Wtedy zaczęło się prawdziwe wyzwanie. Postanowiłem, że podejmę się tego, ponieważ hobbystycznie interesowałem się elektroniką, systemem Linux i projektowaniem.

W ciągu kilku tygodni udało się sprowadzić sprzęt, przygotować go do pracy w trybie kiosk i napisać proste oprogramowanie do jego obsługi.   Pod koniec zainstalowaliśmy wszystko na kilka godzin przed ‘deadlinem’, którym była prezentacja dla zagranicznych przedstawicieli spółki.

Pomysł spodobał się na tyle, że zostaliśmy poproszeni o jego rozwijanie. Przez kolejne miesiące, już na spokojnie wykonaliśmy kilkanaście instalacji usprawnionego  systemu na stacjach benzynowych w Polsce, Czechach, Słowacji i na Węgrzech. W pracy nad takimi projektami najbardziej spodobało mi się to, że mogę być obecny na każdym etapie tworzenia i mieć na to wpływ. Począwszy od architektury oprogramowania, a kończąc na konstrukcji takiego urządzenia.


 W  naturalny sposób w ramach spółki ADV Experience powstała spółka ADV Digital, którą obecnie kieruję. Następne projekty były również mocno związane z elektroniką, systemami embedded, IoT, a ostatnio coraz więcej z machine learning.

W tym także drugi duży projekt dla stacji benzynowych: CPMS, który pozwolił naszemu klientowi zintegrować wyświetlacze na monolitach cenowych z systemem kasowym tak, aby móc centralnie, za pomocą dedykowanej aplikacji zarządzać cenami na stacjach paliw.

Tu również musieliśmy działać wielopłaszczyznowo:  przeprowadziliśmy inżynierię wsteczną na urządzeniach, które technologicznie były już przestarzałe, zaprojektowaliśmy wykonaliśmy i zainstalowaliśmy przystawki IoT, które potrafiłyby komunikować się ze sterownikami wyświetlaczy, napisać aplikacje WWW i mobilne do obsługi systemu itd.

Praca przy tego rodzaju projektach bardzo rozwija. Ze względu na pracę w małym zespole i szeroki wachlarz technologii musiałem udzielać się na każdym etapie projektu. Dzięki temu nie jestem już tylko programistą PHP, jak wtedy gdy zaczynałem, ale znam też zagadnienia frontendowe, odnajduję się w programowaniu w Embedded C, tworzę własne modyfikacje dla systemu Linux, a dodatkowo rozwinąłem się biznesowo.

Oczywiście po tym czasie trudno byłoby mi się odnaleźć w korporacji, gdzie specjalizacje programistów są coraz węższe, a złożoność pewnych obszarów powoduje, że co chwila powstają nowe specjalistyczne stanowiska. Kiedy ja zaczynałem pracę, nikt nie potrzebował DevOps’ów, bo samo pojęcie chmury dopiero się rozwijało, a programiści wspierali się sys adminami.

Z jakimi językami programowania najbardziej lubisz pracować i dlaczego?

Nie będzie pewnie dla nikogo zaskoczeniem, jeśli powiem, że są to języki skryptowe typu PHP lub Python, w których w dosyć krótkim czasie da się prototypować. PHP lubię, ponieważ jestem z nim związany od czasów nastoletnich, gdy pojawiła się dopiero wersja 3.

Od tamtego czasu ten język zyskał bardzo na popularności, a ze względu na łagodną krzywą uczenia i łatwość w korzystaniu z niego przyciągnął wielu amatorów i zdobył złą opinię wśród profesjonalistów związanych np. z Java lub Ruby.

To fakt, PHP późno otrzymało wsparcie dla technik i rozwiązań znanych chociażby z Ruby, ale dzisiaj, głównie dzięki frameworkowi Symfony i PHP 7, pojęcia takie jak TDD (Test-Driven Development), DDD (Domain Driven Development) są codziennością dla programistów PHP.

Pythona lubię za ogromną społeczność i zasoby pakietów, dzięki którym często bez zbędnego zagłębiania się w kod można stworzyć prototyp szkieletu jakiegoś rozwiązania. Później oczywiście w celu optymalizacji można zmienić technologię, ale często jako proof of concept korzystam z Pythona i jego bogactwa bibliotek open source.

W firmie ADV Digital zajmujecie się między innymi dostarczaniem usług IoT, machine learning i data science. Jakiego rodzaju branże obecnie najbardziej potrzebują takich usług?

Trudno wymienić konkretne branże, ponieważ np. dzięki data science można usprawnić działanie procesów w każdej firmie, w której w jakiś sposób przetwarzane są dane. Dla takich firm jak nasza, najtrudniejsze jest to, że klienci nie zdają sobie z tego sprawy, więc myślą, że tego nie potrzebują. A już proste rozwiązania z zakresu data science potrafią przynieść wymierne korzyści sprzedażowe dla naszych klientów.

Podobnie sprawa ma się z IoT i machine learning. Dajmy na to branża automotive: z jednej strony rozwija się szybko, powstają zaawansowane technologicznie samochody autonomiczne itd., a z drugiej strony, kupując nowe auto ze średniego segmentu w salonie nie jestem w stanie sprawdzić podstawowych parametrów auta za pomocą aplikacji w telefonie. I to wszystko w czasach, gdy za kilkadziesiąt złotych mogę sobie zainstalować w domu żarówkę, którą będę sterował smartfonem.

Jest wiele takich konserwatywnych branż, którym możemy zaoferować proste i tanie usprawnienia. Np. dla jednego z naszych klientów tworzymy obecnie zamek QR, który może być zainstalowany np. w pokoju hotelowym. Gość nie będzie musiał używać karty, żeby wejść do pokoju. Wystarczy mu wygenerowany kod QR, który będzie ważny tylko na czas rezerwacji, a będzie mógł być wysłany na telefon w momencie zameldowania, lub jeszcze nawet rezerwacji, ale to nie jedyne zastosowanie.

Wyobrazi sobie Pani, jakie oszczędności i wygodę przyniesie to np. wspólnocie mieszkaniowej, która nie musi już więcej zarządzać identyfikatorami RFID (tzw. pestkami). Każdy mieszkaniec będzie korzystał z aplikacji, dzięki której może np. wygenerować kod ważny 5 minut dla kuriera, czy kogoś z rodziny. A tym bardziej staroświeckim wystarczy wydrukować kod QR na zwykłej drukarce i zamknąć w plastikowym breloczku (żeby nie było, że nie myślimy też o naszych babciach i dziadkach :)).

A skoro już jesteśmy przy osiedlach mieszkaniowych – nie denerwują Panią piloty do bram garażowych? Zawsze się gdzieś zapodzieje, trzeba pamiętać żeby wozić go cały czas w samochodzie.

Rozwiązaniem takich problemów może być np. system ALPR, który przy dzisiejszym dostępie do technologii jest tani we wdrożeniu i utrzymaniu. Jeden pilot kosztuje zazwyczaj kilkadziesiąt złotych. Dla klienta końcowego, tj. mieszkańca trzy razy tyle, ze względu na to, że ktoś musi przyjechać i zaprogramować sterownik bramy.

My proponujemy  moduł ALPR (tj.automatycznego rozpoznawania tablic rejestracyjnych), który może współpracować ze wszystkimi dostępnymi na rynku sterownikami bram, Deweloper, który zdecyduje się na zainstalowanie takiego modułu może całkowicie zrezygnować z tradycyjnych pilotów radiowych, bo mieszkaniec będzie mógł awaryjnie otworzyć bramę np. z poziomu aplikacji na smartfonie, np. gdy tablica rejestracyjna będzie brudna i niemożliwa do odczytania.

Podsumowując, w każdej branży znajdzie się przestrzeń dla wspomnianych technologii. Dla nas jako dostawcy, kłopotliwy jest brak otwartości i być może strach przed nimi.

Jak wygląda otwartość polskich firm na wdrażanie tego typu rozwiązań, a jak to wygląda w przypadku zagranicznych firm?

Po części odpowiedziałem już na to pytanie wyżej. Większą rolę zapewne odgrywa wielkość firmy. Zagraniczne małe firmy pewnie niewiele będą różniły się od naszych rodzimych w kwestii otwartości. My jako kraj mamy bardzo wysoki współczynnik obeznania społeczeństwa z nowymi technologiami, więc tym bardziej dziwi zamknięcie na ten kierunek rozwoju.

Inaczej sytuacja ma się w przypadku dużych, międzynarodowych korporacji. Tu widzimy coraz większe zainteresowanie i oddolne zapytania o konkretne technologie. Cieszy mnie to, że duże firmy coraz więcej o tym myślą i przeznaczają coraz większe budżety nie tylko na zakup takich technologii, ale także ich rozwój.

Czy w związku z powyższym mógłby nam Pan przedstawić jakieś case study klienta?

Chyba najciekawszym case study będzie tutaj wspomniany system CPMS, jako jeden z najdłuższych i największych projektów, które zrealizowaliśmy. Oprócz tego wyróżnia się tym, że przyniósł korzyści i wygodę nie tylko samej firmie, ale także jej pracownikom, co nie zawsze idzie w parze.

 Przez naszego klienta, z którym współpracowaliśmy już przy systemie food-service na stacjach benzynowych zostaliśmy poproszeni o sprawdzenie, czy można zrobić użytek z zainstalowanych dotychczas monolitów cenowych tak, aby umożliwić kontrolę cen na stacjach i ułatwić pracę pracownikom, ponieważ sterowanie wyświetlaczami odbywa się cały czas za pomocą pilota.

Dostaliśmy dwa miesiące na zbadanie tematu i przygotowanie rozwiązania typu proof of concept. W tym czasie okazało się, że:

  • istnieje 4 producentów elektroniki do wyświetlaczy używanych na stacjach
  • istnieje wiele różnych wersji elektroniki w ramach jednego producenta różniących się znacznie od siebie, nie do końca kompatybilnych ze sobą
  • system kasowy, z którego miałyby być przesyłane ceny został napisany na początku lat 90 (system DOS) i nie jest już aktywnie rozwijany
  • istnieją dwa różne standardy, w których pracują urządzenia na stacji i system kasowy

Aby móc sprawdzić, czy da się zintegrować nasze rozwiązanie z monolitami, musieliśmy prześwietlić wszystkie kombinacje. Niektóre rozwiązania posiadały dokumentację, a kontakt z producentami był wzorowy.

Dostaliśmy odpowiednie wsparcie nawet w zakresie modyfikacji oprogramowania dla naszych potrzeb. W innych przypadkach musieliśmy sami, przy pomocy inżynierii wstecznej, rozgryźć i udokumentować na nowo protokoły komunikacyjne oraz zabezpieczenia w tych urządzeniach.

Mimo przeszkód udało się. Po dwóch miesiącach mieliśmy zrobiony audyt, wstępnie udokumentowane rozwiązanie dla każdego usecase’a i gotowy prototyp, który pozwalał na zdalne zarządzanie cenami na monolitach i ich monitorowanie w trybie ciągłym.

Otrzymaliśmy zielone światło i podpisaliśmy umowę na instalację systemu na ponad 300 stacjach w Polsce. Rozpoczął się okres ciężkiej pracy, podczas której musieliśmy:

  • zaprojektować wersje produkcyjne prototypowych urządzeń IoT, ich obudowy i elektronikę (technologie: IFSF LON, GSM, WIFI)
  • przejść badania laboratoryjne na zgodność z odpowiednimi normami i dyrektywami, aby móc posługiwać się oznaczeniem CE
  • stworzyć aplikację WWW, która potrafi w czasie rzeczywistym monitorować stan całego systemu i nim zarządzać (React + Symfony + MQTT)
  • stworzyć dwie aplikacje mobilne (jedna dla serwisantów, druga dla obsługi stacji) do zarządzania monolitami (Android, Java, React Native)
  • przygotować bezpieczne środowiska uruchomieniowe w chmurze
  • stworzyć dokumentację i procedury dot. instalacji i obsługi systemu

Wszystko co wymieniłem powyżej udało się przygotować w zaledwie pół roku przy wykorzystaniu jedynie kilkuosobowego zespołu. Kolejne pół roku to był czas instalacji systemu na 320 stacjach w Polsce. Nie obyło się bez trudności, na bieżąco musieliśmy się mierzyć z problemami integracyjnymi lub  nowymi przypadkami oprogramowania lub sprzętu, które nie zostały wykryte podczas audytu początkowego.

Dodatkowym problemem były zaostrzone procedury bezpieczeństwa dla osób pracujących na stacjach benzynowych. Nasze zespoły serwisantów musiały przejść szereg szkoleń, dzięki którym mogły zostać dopuszczone do pracy.

Na koniec, gdy system został już zainstalowany i był w pełni sprawny, znowu dotknęły nas specjalne procedury. kilkudziesięciostronicową dokumentację systemu musieliśmy stworzyć w 3 kopiach dla każdej ze stacji. Kilkadziesiąt kartonów zadrukowanego papieru, skrzętnie pogrupowanego w opisane segregatory. Musieliśmy wynająć busa, by przewieźć to do archiwum klienta 🙂

Czytaj także – Dwie warstwy strony internetowej, czyli czym różni się Front-end od Back-endu

2+
ZOBACZ RÓWNIEŻ
Share on twitter
Share on facebook
Share on linkedin
Share on whatsapp