W tym mocno technicznym wpisie, chciałbym przedstawić technologie, jakie wykorzystujemy w codziennej pracy w KISS digital. Początkowo miał tutaj znaleźć się także opis metod pracy, jednak samego opisu języków i narzędzi zrobiło się tyle, że o jestem zmuszony napisać o nich kolejnym razem. Mimo to - szykujcie się ponieważ będzie dużo specyficznej terminologii. Samo mięso, zero lania wody. Zaczynamy!

...Albo nie. Najpierw coś dla tych, których goni czas:

TLDR

Aplikacje na Androida piszemy w Javie, eksperymentujemy też z Kotlinem. Aplikacje mobilne na iOS to głównie Swift. Unikamy technologii hybrydowych (a powód opisaliśmy tutaj). Narzędzia Continuous Integration to Bitbucket + Jenkins + Fabric.

API z reguły oparte jest na RESTful + JSON, dokumentowane w Swagger 2.0. Automatyzacja budowania oparta na Bitbucket Pipelines, deployment przy użyciu envoyera. Do podglądu odpowiedzi z API korzystamy ze świetnego narzędzia, jakim jest PAW na OS X.

Serwisy internetowe to z kolei PHP z Laravel, MySQL, a na froncie React, ECMAScript 6, SASS, Gulp i Webpack. Monitoring z użyciem StatusCake, analizy przy użyciu Google PageSpeed Insights, Google Analytics i Yandex Metric.

Aplikacje mobilne

Aktualnie w KISS oferujemy programowanie aplikacji mobilnych na systemy iOS i Android. Jednak ze względu na kilku naszych stałych klientów, utrzymujemy także aplikacje napisane dla systemu Windows. Być może kiedyś trend się odwróci i system Microsoftu ponownie(?) stanie się popularny. Będziemy wtedy gotowi do rozwijania nowych projektów w tej technologii. Co ma być to będzie, ale jeżeli mowa o Windows, to aplikacje dla niego były tworzone w C#, oraz częściowo z użyciem technologii hybrydowych PhoneGap i Cordova.

Dużo więcej można powiedzieć natomiast o pozostałych dwóch systemach mobilnych. Głównym językiem w jakim piszemy na Androida jest wciąż Java - i chociaż w tym momencie realizujemy już nasz pierwszy projekt w Kotlinie, to na ten moment uważamy że jest zbyt wcześnie, na trwały wybór tego języka w kolejnych projektach. Poczekamy jeszcze i zaobserwujemy jak się język rozwija, a o przejściu zdecydujemy wtedy gdy osiągnie on określoną przez nas "zdolność produkcyjną". Pamiętamy jak to było ze Swiftem na iOS - gwałtowny rozwój i zrywanie kompatybilności wstecznej, stwarzało problemy z utrzymywaniem dłuższych czasowo projektów. I chociaż nasi programiści, jak i większość programistów na całym świecie, z entuzjazmem podchodzą do wszelkich nowych narzędzi. Choć sam mam trudności, aby bronić się przed Hype Driven Development, to produkcyjnie działamy ze sprawdzonymi technologiami o ugruntowanej pozycji. Z tego samego powodu, w bardzo nikłym stopniu wykorzystujemy technologie hybrydowe. Pomimo wielu lat rozwoju, wciąż nie zapewniają one oczekiwanej przez nas jakości - ani PhoneGap, ani Cordova, ani React Native, nie potrafią dać tego, co może dać dobrze napisana aplikacja natywna. Więcej o tym pisał Piotr we wpisie porównującym technologie cross-platfomowe z natywnymi aplikacjami.

Wspomniałem już wyżej o Swift - obecnie jest to nasz podstawowy język w jakim tworzymy nowe oprogramowanie na iOS. W wersji trzeciej jest już wystarczająco dojrzały, a przy tym jest zwyczajnie fajnym i nowoczesnym językiem. I choć moim zdaniem wprowadza on kilka niepotrzebnych konstrukcji, które miejscami drastycznie zmniejszają czytelność kodu, to summa summarum jednak pisze się w nim dużo szybciej i wyraźnie łatwiej niż w Objective-C. No a czego, jak nie wysokiej wydajności i jakości, oczekują od nas nasi klienci, prawda? :) A jeżeli już o wydajności mowa - to w kilku projektach (w których konieczne było wykonywanie intensywnych obliczeń, np. do analizy obrazów), zaprzęgliśmy do pracy czysty C++.

API i serwisy internetowe

Większość aplikacji mobilnych, jakie programujemy w KISS, korzysta z takich czy innych zasobów serwerowych. Przyjętym więc u nas powszechnie standardem komunikacji dla API jest protokół RESTful+JSON, który jest wystarczający w 95% przypadków. Specyfikację API tworzymy przy użyciu schematu Swagger 2.0, dzięki czemu taka specyfikacja staje się od razu zarówno dokumentacją, jak i plikiem źródłowym do automatycznego generowania klienta API, generowania części aplikacji serwerowej, a także generowania testów. Przykładowo, importujemy przygotowaną specyfikację do klienta PAW, który w super wygodny sposób pozwala wywoływać metody API i obserwować rezultaty.

Backend rozwijamy na frameworku Laravel - wcześniej korzystaliśmy z Symfony, którego osobiście oceniam nieco wyżej, jednak ostatecznie efektywność i elastyczność Laravela wygrała i większość projektów powstaje właśnie na nim. Silnik bazy danych to oczywiście MySQL - "oczywiście" ponieważ jest to najpowszechniej wybierane rozwiązanie w przypadku używania PHP, ale jesteśmy także w stanie obronić merytorycznie nasz wybór, przed zwolennikami Postgresa czy innych baz danych.

Mamy kilka własnych narzędzi, od całkiem prostych - jak np. skrypt dla yeomana zakładający nowy projekt, aż po gotowy panel administracyjny typu "CRUD and more", który bardzo łatwo może być wdrażany w różnorodnych projektach.

Frontend natomiast to miks wielu technologii. Można by tutaj ukuć termin "frontend mix": Node.js, React, Angular (historycznie raczej), jQuery, SASS, Gulp, Webpack. Przyjęliśmy też, że piszemy już skrypty Javascript w zgodzie ze specyfikacją ECMAScript 6 (takie masło maślane). Ale w sumie TypeScript jest taki fajny, i tak bardzo porządkuje kod, że też by się chciało go używać :) Zasadniczo, jeżeli chodzi o front, to tutaj zdecydowanie częściej trzeba dobierać odpowiednie narzędzia do projektu. W backendzie jest prościej, narzędzia są bardziej uniwersalne.

Continuous Integration

Teraz rzut oka na to, jak wygląda nasz typowy workflow "od developera do testera i heja na produkcję!".

Zacznijmy od części procesu, która jest wspólna zarówno dla programowania aplikacji mobilnych, jak i serwisów internetów: projekty powstają i są uruchamiane lokalnie na komputerach developerów (ta informacja wbrew pozorom nie jest taka bezsensowna), każdy ma u siebie lokalne repozytorium gita, skonfigurowane środowisko (np. serwer w przypadku webdeveloperów), zmiany commituje do gałęzi (feature, bugfix albo hotfix branch), po czym całość trafia do bitbucketa jako pull request. Zanim kod zostanie zmergowany do gałęzi develop, przechodzi code review - czyli drugi programista przegląda wprowadzone zmiany i zatwierdza je, albo przeciwnie, zwraca kod do autora wskazując popełnione błędy.

Tutaj jednak już zaczynają się różnicę pomiędzy web, a mobile developmentem. Aplikacja webowa, po wrzuceniu zmian na bitbucketa, jest poddawana od razu testom uruchamianym w bitbucketowych pipeline'ach. Pipelines uruchamiają testy jednostkowe, ale także przeprowadzają statyczną analizę kodu w PHP CodeSniffer oraz w PHP Mess Detector.

Z kolei aplikacja mobilna, po pojawieniu się nowych pull requestów, trafia na nasz serwer z Jenkinsem, gdzie przeprowadzane są testy integracyjne. Wynik tych testów jest przekazywany z powrotem do repozytorium, wskazując czy można bezpiecznie przeprowadzić łączenie z gałęzią develop. W kolejnym kroku, po zatwierdzeniu Pull Requestów, aplikacja ponownie trafia do Jenkinsa, gdzie jest kompilowana, a następnie gotowy build jest wysyłany do Fabrica, który to z kolei rozprowadza nową wersję aplikacji wśród testerów i do klienta.

Oprogramowanie webowe jest natomiast wdrażane na serwer testowy dopiero po wydaniu przez programistę stosownego polecenia. Do automatyzowania deploymentu na serwerze wykorzystujemy jedną z paczek z Laravela - Envoyera. Programista wydaje polecenie, na serwerze testowym wykonywana jest kopia, następnie są zaciąganie najnowsze zmiany, przeprowadzana jest migracja w bazie danych, cache jest czyszczony. Voila - nowa wersja stoi na serwerze, gotowa do testów funkcjonalnych.

Podsumowanie

Nie wnikałem w tym wpisie w wiele możliwych kwestii. Bazując tylko na tym co napisałem wyżej, widzę jak wiele różnych tematów można rozwinąć, i mam nadzieję, że rozwinę je w miarę szybko. A na chwilę obecną, jeżeli jeszcze nie uciekłeś przerażony, a masz pomysł na projekt do zrealizowania - zapraszamy do kontaktu! Napisz założenia projektu, a my umówimy się z Tobą na rozmowę, przeanalizujemy wymagania i przygotujemy dla Ciebie wycenę. Proste, prawda?