W skrócie
Dla armatora morskiego Shipsnavo zbudowaliśmy firmowy portal, który zbiera w jednym miejscu wszystkie procedury, formularze i przepisy obowiązujące na pokładzie. Wdrożyliśmy mechanizm synchronizacji danych między aplikacją desktopową na statku a CMS-em.
Pierwszy kontakt
Żegluga to specyficzna branża. Duże statki, brak stałej łączności, długie dni z dala od lądu i masa regulacji prawnych.
Kluczowe jest utrzymywanie dokumentacji pokładowej w aktualnym stanie. Dane identyfikacyjne armatora, zakres uprawnień kapitana, wymagania wobec personelu i wiele innych niezbędnych informacji powinny znajdować się na pokładzie każdego statku.
Do przechowywania tych danych klient posiadał już dedykowane oprogramowanie w postaci aplikacji desktopowej. Aplikacja była uruchamiana osobno na komputerze z systemem Windows na każdym statku. Pozwalało to personelowi skorzystać z odpowiedniej instrukcji w razie potrzeby.
Powodem, dla którego klient postanowił nawiązać z nami współpracę, był długi czas aktualizacji danych we wspomnianej wyżej aplikacji.
Gdy zachodziła potrzeba aktualizacji dowolnej instrukcji czy biuletynu informacyjnego, właściciel statku musiał zgłosić to dostawcy oprogramowania, który z kolei wprowadzał poprawki bezpośrednio w oprogramowaniu. Po wprowadzeniu danych dostawca wydawał nową wersję aplikacji, a zmienione dane trafiały na komputery personelu przy kolejnej aktualizacji.
Pożar, wybuch, kolizja, wejście na mieliznę i wiele innych wypadków nawigacyjnych czy środowiskowych mogą zaskoczyć marynarza. Na te i inne scenariusze przewidziano odpowiednie procedury, z którymi załoga powinna być zapoznana i do których musi mieć szybki dostęp w razie potrzeby.
Klient przyszedł do nas z konkretnym zapytaniem – o wyeliminowanie konieczności komunikacji z pośrednikiem przy aktualizacji danych. Nie chodziło o automatyzację tego procesu, lecz o całkowite pominięcie tego kroku.
Naszym zadaniem było znaleźć rozwiązanie, dzięki któremu zmiany w dokumentacji pokładowej trafiają do załogi w możliwie najkrótszym czasie.
My, jako Koncewicz Software House, takie rozwiązanie znaleźliśmy.
Zbieranie danych
Po rozpoczęciu współpracy klient przekazał nam wszystkie niezbędne informacje. Najwięcej uwagi poświęciliśmy aplikacji desktopowej wykorzystywanej już przez klienta. Była to typowa aplikacja uruchamiana w środowisku Windows.
Po głębszej analizie zdaliśmy sobie sprawę, że kod źródłowy jest poddany obfuskacji i nie nadaje się do wprowadzania jakichkolwiek zmian.
Aplikacja nie posiadała skomplikowanej logiki. Przechowywała statyczne teksty, obrazki i linki do zewnętrznych dokumentów. Doszliśmy do wniosku, że możemy stworzyć podobną aplikację o tych samych właściwościach i że nie ma ryzyka nieukończenia projektu, jeśli podejmiemy się wyzwania zbudowania jej od nowa. Każdy zbadany obszar aplikacji utwierdzał nas w przekonaniu, że w całości nadaje się do sklonowania.
Znaleźliśmy też sposób na pobranie wszystkich danych z dotychczasowej aplikacji. Wyeliminowało to konieczność ponownego wprowadzania danych do nowego systemu.
Poinformowaliśmy klienta o wynikach naszej analizy i zasugerowaliśmy, że nową aplikację zbudujemy w technologii NativePHP. Specjalizujemy się w Laravelu, więc NativePHP był naturalnym wyborem jako technologia do zbudowania aplikacji desktopowej.
NativePHP to stabilna i sprawdzona technologia z dużą społecznością. Umożliwia opakowanie aplikacji opartej na Laravelu w aplikację desktopową.
W trakcie prac rozpoznawczych ukształtowała się architektura przyszłego ekosystemu, który miał rozwiązać kwestię szybkiej aktualizacji dokumentacji pokładowej. Centralne miejsce zarezerwowaliśmy dla panelu, z poziomu którego miało się odbywać zarządzanie treścią całej dokumentacji pokładowej dystrybuowanej do każdego ze statków.
Zbieranie danych dobiegło końca. Projekt nazwaliśmy wewnętrznie Embedded CMS i przeszliśmy do etapu implementacji.
Dlaczego NativePHP
W poprzednim rozdziale udzieliłem częściowej odpowiedzi na to pytanie. Znamy Laravel, a NativePHP jest częścią ekosystemu tego frameworka, więc był naturalnym wyborem.
Stwierdzenie to jest prawdziwe, ale dość powierzchowne. Szczegółowy wgląd w architekturę dostarczonego przez nas systemu ujawnia, jak dużo czasu i zasobów zaoszczędziliśmy, decydując się na tę technologię w tym konkretnym przypadku.
Cały ekosystem, który dostarczyliśmy klientowi, składa się z następujących elementów:
- CMS do zarządzania treścią dokumentacji pokładowej
- Strona internetowa dla marynarzy z dokumentacją pokładową dostępną online
- Aplikacja desktopowa dla marynarzy z dokumentacją pokładową w trybie offline
- Interfejs API do synchronizacji dokumentacji pokładowej między wersją internetową a aplikacją desktopową
Strona internetowa dla marynarzy jest najważniejszym elementem, wokół którego powstała reszta systemu. Jest wpięta bezpośrednio w CMS przez iframe, gdzie administrator dokonuje modyfikacji danych. Jest też udostępniona pod specjalnym adresem URL wyłącznie w trybie do odczytu – do wykorzystania przez marynarzy. Dzięki technologii NativePHP trafia na komputery marynarzy w postaci aplikacji desktopowej.
Tu kryje się odpowiedź na pytanie, dlaczego NativePHP. Zbudowaliśmy jedną aplikację – zawierającą zbiór dokumentacji pokładowej – która jest wykorzystywana od razu w trzech miejscach.
Owszem, nie było to takie proste w realizacji. Nie wszystko, co NativePHP dostarcza „z pudełka”, działało zgodnie z naszymi wymaganiami. Nagrodą był jednak piękny finał: wprowadzenie zmian w jednej bazie kodu daje potrójny efekt. Przy wdrażaniu nowych funkcjonalności wprowadzamy zmiany tylko na stronie internetowej dla marynarzy, a po pewnych zabiegach trafiają one do podglądu w CMS-ie oraz do aplikacji offline.
Podsumowanie
Skróciliśmy czas wprowadzania zmian w dokumentacji pokładowej kilka tysięcy razy. Wcześniej klient musiał przekazać informację o poprawkach dostawcy oprogramowania, który następnie wydawał nową wersję aplikacji i dystrybuował ją na komputery marynarzy. Teraz administrator CMS-a o dowolnej porze loguje się do systemu i wprowadza zmiany, które natychmiast – w ciągu 1-2 minut – trafiają do marynarzy.
Po stronie klienta mieliśmy świetnego Product Ownera, we współpracy z którym poznaliśmy wyzwania branży armatorskiej, dobraliśmy właściwe technologie i dostarczyliśmy rozwiązanie na kilka tygodni przed planowanym terminem ukończenia projektu.