Jak dodać wielojęzyczność na stronie. Częste problemy (cz. 2. case study)

Jeszcze wiele wyzwań czeka Cię na drodze między wyborem metody a kompletnym wdrożeniem wielojęzyczności na stronie WWW. Nie daj się zaskoczyć częstym problemom.

Skorzystaj z rozwiązań wypracowanych w naszym ostatnim projekcie, częściowo zrealizowanym w ramach prezentu gwiazdkowego dla Stowarzyszenia Sarcoma.

Jak dodać wielojęzyczność na stronie. Częste problemy. Na przykładzie serwisu rejestracji na Onkobieg.
Tłumaczenie treści zgód w procesie rejestracji na Onkobieg. Wersja angielska jeszcze w fazie testów.

Z serii artykułów dowiesz się:

  1. Jak wybrać sposób wdrożenia wielojęzyczności.
  2. Na jakie problemy wielojęzycznych stron WWW uważać (poniżej).
  3. O czym pamiętać w tłumaczeniu strony.

Krok 2. Uważaj na częste problemy wielojęzycznych stron WWW

Skorzystaj z gotowych rozwiązań często występujących problemów. Sprawdź, jak poradziliśmy sobie z kilkoma trudnościami, które napotkaliśmy, tłumacząc serwis Onkobieg.

Funkcje wspólne dla całego systemu

Problem:

Może się zdarzyć, że niektóre funkcje systemu nie będą przypisane do wersji językowych, tylko będą wspólne.

Formularz logowania do konta użytkownika. Nieprzypisany do wersji językowej.

W przypadku serwisu Onkobieg przykładem takiej funkcji był formularz logowania – dostępny w oknie modalnym, które po zalogowaniu kierowało na stronę główną. Takie rozwiązanie sprawdzało się w serwisie jednojęzycznym, ale w serwisie tłumaczonym na inne języki brakowało kontekstu – informacji o tym, z której wersji językowej witryny korzysta użytkownik.

Rozwiązanie:

Dodaliśmy do sesji użytkownika informację o używanej wersji witryny.

Treści zaszyte w szablonie strony

Problem:

Niektóre elementy (np. treści w stopce strony) mogą być zaszyte w kodzie szablonu. Wdrożenie wielojęzyczności wymusza przeniesienie tych treści do systemu CMS (Systemu Zarządzania Treścią) lub do plików językowych.

Stopka serwisu Onkobieg. Z odnośnikami i elementami graficznymi zaszytymi w szablonie strony.

Poziom złożoności kodu HTML serwisu Onkobieg uniemożliwiał zarządzanie treściami za pomocą systemu CMS i edytora WYSIWYG. Wprowadzanie dowolnych zmian w formatowaniu treści mogłoby doprowadzić do błędów w strukturze kodu HTML.

Z drugiej strony, treści serwisu zawierały m.in. linki. Z tego powodu nie powinny być przenoszone do plików językowych.

Rozwiązanie:

Przebudowaliśmy problematyczną sekcję. Przepisaliśmy reguły CSS, tym samym upraszczając kod HTML, by można go było edytować z poziomu CMS.

Treści zgód (np. RODO)

Problem:

Niektóre serwisy internetowe mają rozbudowany system zarządzania klauzulami.

Dla przykładu, by wziąć udział w Onkobiegu, trzeba wyrazić zgodę m.in. na: regulamin biegu, regulamin operatora płatności PayU, politykę prywatności.

Przykładowe zgody w procesie rejestracji na Onkobieg.

Akceptacja klauzuli w danym języku powinna być równoważna z udzieleniem zgody także na treść jej tłumaczenia. Postanowiliśmy jednak zabezpieczyć naszego klienta przed sytuacją, w której tłumaczenia tej samej zgody różniłyby się między sobą – np. gdy już zacznie obowiązywać zaktualizowana klauzula w wersji angielskiej, a jej odpowiednik w wersji polskiej jeszcze nie.

Rozwiązanie:

Na ten moment klauzule w serwisie Onkobieg nie są grupowane. To oznacza, że akceptacja klauzuli w jednym języku nie wiąże się z automatyczną akceptacją jej tłumaczenia.


W efekcie rosnąca grupa uczestników Onkobiegu spoza Polski zyska możliwość rejestracji na bieg w języku angielskim. Dzięki wdrożonemu rozwiązaniu, organizator wydarzenia będzie mógł w dowolnym momencie dość łatwo dodawać kolejne wersje językowe.

„Trudno znaleźć tak zaangażowanego partnera jak Sidnet. Znaczną część tłumaczenia strony wykonali bez kosztów, w ramach prezentu świątecznego dla Stowarzyszenia. Jesteśmy za to bardzo wdzięczni!”

Szymon Bubiłek
Członek Zarządu Stowarzyszenia Sarcoma

#DarowiznySidnet: Mariusz dla Webpack i Fundacji TipTop

Mamy „jeden prosty sposób” na zbliżający się Blue Monday (nazywany najbardziej depresyjnym dniem w roku, lecz niepotwierdzony naukowo). Stosujemy go raz w miesiącu, a efekty potrafią zaskoczyć. Co ma tak dobroczynny wpływ? Comiesięczne #DarowiznySidnet – przekazywane projektom open source i charytatywnym zgodnie z życzeniem zespołu.

Tym razem typuje Mariusz Różański – najmłodszy w całym zespole, a już z kilkuletnim doświadczeniem w web developmencie i byciu tatą. Mariusz na co dzień pracuje z Torunia, głównie w projektach dla naszych brytyjskich klientów: THG i UK2.

Webpack

Open source’owe narzędzie JavaScript. Pozwala na scalanie zasobów, stylów, skryptów czy grafik, tworząc jeden, zoptymalizowany plik wyjściowy. Webpack łączy poszczególne moduły projektu (np. pliki JavaScript, Sass, Less, HTML, zewnętrzne biblioteki i inne), uwzględniając kolejność i zależności.

Nasz developer od kilku lat używa tego narzędzia zarówno w małych, jak i złożonych projektach webowych.

Jakie cechy Webpacka szczególnie trafiają do Mariusza?

  • Konfigurowalność. Webpack jest znany z szerokich możliwości konfiguracji. Umożliwia łatwe dostosowanie każdego detalu do potrzeb projektu.
  • Optymalizacja stron. Webpack pozwala na dzielenie plików wyjściowych na mniejsze kawałki. Tzw. „chunks” mogą ładować się w danych okolicznościach, a być pomijane w innych (np. w wersji mobilnej).

„Codziennie powstają kolejne technologie frontend, z których część jest nieprzydatna lub wręcz bezsensowna. W formie żartu powstała strona zliczająca dni od wydania ostatniego frameworku JavaScript – nie widziałem do tej pory, żeby na liczniku było więcej niż 3 dni. Wsród wszystkich tych narzędzi są takie, które faktycznie zwiększają wydajność pracy i stają się jej nierozłącznym elementem. Dla mnie takim narzędziem jest Webpack. – mówi Mariusz.

Fundacja TipTop

Organizacja niesie pomoc dzieciom cierpiącym z powodu niepełnosprawności, ubóstwa lub trudnej sytuacji, która dotknęła ich rodzinę.

„Fundacja TipTop jest mi tak bliska, bo pomaga dzieciom z obniżonym i wzmożonym napięciem mięśniowym. Dyskomfort i ból od pierwszych dni życia sprawiają, że niezbędna jest rehabilitacja maluszka i wytrwałość rodziców. Znam to z własnego doświadczenia” – mówi nasz developer.

Fundacja wspiera rodziców dzieci, m.in. poprzez: finansowanie leczenia, organizowanie rehabilitacji i wypoczynku, pomoc w zbieraniu środków. Działa także na rzecz domów dziecka, gdzie z zebranych datków realizuje remonty, dostarcza wyposażenie, niesie bezpośrednią pomoc podopiecznym.

„Są dzieci, które bez pomocy z zewnątrz nie są w stanie prawidłowo się rozwijać. To wspaniałe, że wolontariusze Fundacji TipTop otaczają je opieką. Wcześnie wykryte dolegliwości związane z napięciem mięśniowym dają się całkowicie wyleczyć. Nic więc nie powinno stawać na przeszkodzie, by takie dzieci otrzymały pomoc i równe szanse wyrośnięcia na silnych, mądrych ludzi, którzy będą tworzyć naszą przyszłość” – dodaje Mariusz.

Jak dodać wielojęzyczność na stronie. Wybór sposobu (cz. 1. case study)

Planujesz dodać kolejne wersje językowe Twojej strony WWW? Dowiedz się, jak zrobić to krok po kroku. Na przykładzie realnego projektu, którego część, z okazji świąt, wykonaliśmy pro bono na rzecz organizacji charytatywnej.

Jak dodać wielojęzyczność na stronie. Wybór sposobu. Na przykładzie serwisu rejestracji na Onkobieg.
Dwie wersje językowe serwisu rejestracji na Onkobieg – wersja angielska jeszcze w fazie testów.

Z kolejnych artykułów dowiesz się:

  1. Jak wybrać sposób wdrożenia wielojęzyczności (poniżej).
  2. Na jakie problemy wielojęzycznych stron WWW uważać.
  3. O czym pamiętać w tłumaczeniu strony.

Krok 1. Wybierz sposób wdrożenia wielojęzyczności

Zanim zaczniesz dodawać tłumaczenie, zastanów się, jaka metoda najlepiej sprawdzi się na Twojej stronie.

Rozważaliśmy 3 sposoby wdrożenia wielojęzyczności w istniejącym systemie CMS (Systemie Zarządzania Treścią) serwisu rejestracji na Onkobieg. Poznaj zalety i wady każdego z nich.

A. Kopia całej strony

Przebieg:

Skopiowanie kodu źródłowego i bazy danych. Uruchomienie kopii pod innym adresem, a następnie podmiana wszystkich tekstów na inny język.

Zalety:

  • Prostota. Rozwiązanie najprostsze i najszybsze do wprowadzenia.
  • Zero zmian w bazie danych. Nie trzeba modyfikować bazy danych – wystarczy wykonać jej kopię.
  • Łatwość modyfikacji tekstów zaszytych w szablonach (np. informacji w stopce strony). Wystarczy edycja – nie trzeba używać narzędzi do obsługi wielojęzyczności w szablonach.
  • Zróżnicowana zawartość. Wersje językowe tej samej strony mogą się od siebie różnić – niektóre mogą być bardziej rozbudowane, inne mniej.

Wady:

  • Oddzielne bazy danych. Bez dodatkowej synchronizacji nie można współdzielić danych między wersjami językowymi.
    Przykład: konto użytkownika. Jeśli użytkownik założy konto w polskiej wersji strony, to po zmianie języka na angielski, będzie musiał założyć drugie.
  • Brak powiązania podstron. Utrudnione przełączanie między wersjami językowymi danego zasobu.
    Przykład: powrót na stronę główną z podstrony. Jeśli użytkownik przegląda jakąś podstronę po polsku, to po zmianie języka na angielski, nie zostanie odesłany do tłumaczenia tej podstrony, tylko na stronę główną (home).
  • Wyższy koszt utrzymania. Zmiany w systemie (m.in. zmiany w szablonie, zmiany w bazie danych, dodanie nowej funkcji) wykonuje się oddzielnie dla każdej wersji językowej.

B. Tłumaczenia poszczególnych zasobów

Przebieg:

Dodanie nowych pól w bazie dla kolejnych języków (np. tytuł artykułu EN, opis artykułu EN itd.). Tłumaczenie strony poprzez uzupełnianie tych dodatkowych pól treściami w innych językach.

Zalety:

  • Niewielka ingerencja w architekturę systemu. Zmiana wersji językowej jest możliwa przez dodanie np. jednego globalnego parametru w adresie URL.
  • Łatwe przełączanie między wersjami językowymi. Każdy zasób w systemie występuje we wszystkich wersjach językowych. To znaczy, że znajomość ID zasobu wystarczy, by pobrać jego dane w innym języku.
  • Wspólna baza danych. Wszystkie wersje językowe korzystają z jednej bazy danych.
  • Niższy koszt utrzymania. Każda zmiana w szablonie jest od razu widoczna we wszystkich wersjach językowych.

Wady:

  • Identyczna zawartość stron. Wersje językowe strony nie mogą się od siebie różnić. To oznacza, że każdy zasób musi zostać przetłumaczony na wszystkie języki.
  • Utrudniona modyfikacja tekstów zaszytych w szablonach. Należy wydzielić je do plików językowych.
  • Ograniczona skalowalność. Każda kolejna wersja językowa wymaga dodania kolejnych pól dla każdego zasobu do uzupełniania w panelu administracyjnym.

C. Jeden system obsługujący wiele wersji witryny

Przebieg:

Stworzenie oddzielnych witryn z wersjami językowymi w ramach jednego systemu. Podpięcie każdej z witryn pod osobną domenę, subdomenę lub katalog w domenie głównej. Przypisanie poszczególnych zasobów (np. podstron czy artykułów na blogu) do witryny w danym języku.

Zalety:

  • Skalowalność. Raz wdrożone rozwiązanie znacznie ułatwia dodawanie kolejnych wersji językowych.
  • Zróżnicowana zawartość. Wersje językowe tej samej strony mogą się od siebie różnić – niektóre mogą być bardziej rozbudowane, inne mniej. Nie trzeba tłumaczyć całej zawartości strony (w tym np. archiwalnych artykułów na blogu).
  • Łatwe przełączanie między wersjami językowymi. Baza danych jest współdzielona. Wszystkie wersje językowe danej podstrony mają wspólny identyfikator.
  • Wspólna baza danych. Wszystkie wersje językowe korzystają z jednej bazy danych.
  • Niższy koszt utrzymania. Każda zmiana w szablonie jest od razu widoczna we wszystkich wersjach językowych.

Wady:

  • Znaczna ingerencja w architekturę systemu. Należy przerobić każdy moduł, by jego zasoby były przypisane do konkretnej witryny.
  • Utrudniona modyfikacja tekstów zaszytych w szablonach. Należy wydzielić je do plików językowych.

Nasz wybór

Onkobieg to serwis rejestracji na wydarzenie biegowe. Pozwala m.in. założyć konto użytkownika, dokonać płatności online i wygenerować kartę startową do druku. Charakter serwisu uniemożliwia uruchomienie jego anglojęzycznej wersji za pomocą oddzielnej bazy danych (sposób A.).

Ostatecznie do wdrożenia wielojęzyczności wykorzystaliśmy rozwiązanie C. – choć bardziej pracochłonne, to skalowalne i niewymagające tłumaczenia strony w 100% (w tym np. archiwalnych wpisów).

Potrzebowaliśmy jeszcze narzędzia do przetłumaczenia treści osadzonych w kodzie źródłowym (np. treści w szablonach, powiadomieniach, komunikatach o błędach). Ponieważ serwis Onkobieg jest napisany we frameworku Laravel, to do tłumaczenia tych treści użyliśmy zestawu funkcji do translacji, wbudowanego w ten framework.


W efekcie rosnąca grupa uczestników Onkobiegu spoza Polski zyska możliwość rejestracji na bieg w języku angielskim. Dzięki wdrożonemu rozwiązaniu, organizator wydarzenia będzie mógł w dowolnym momencie dość łatwo dodawać kolejne wersje językowe.

„Trudno znaleźć tak zaangażowanego partnera jak Sidnet. Znaczną część tłumaczenia strony wykonali bez kosztów, w ramach prezentu świątecznego dla Stowarzyszenia. Jesteśmy za to bardzo wdzięczni!”

Szymon Bubiłek
Członek Zarządu Stowarzyszenia Sarcoma

#DarowiznySidnet: Łukasz dla WordPress Foundation i Fundacji Unaweza

Nie potrzebujemy świąt, żeby zabawić się w Mikołaja. W każdym miesiącu przekazujemy prezent twórcom oprogramowania open source i organizacjom dobroczynnym. Tym razem „najgrzeczniejsze” fundacje wskazuje Łukasz Nowicki, nasz zdalny Senior WordPress & PHP Developer. Łukasz w otoczeniu mazurskich jezior pracuje w projekcie dla naszego klienta z wysp – THG i UK2 (należącego obecnie do THG).

Jakie organizacje otrzymają świąteczne darowizny od Sidnet?

WordPress Foundation

Fundacja WordPress od 2010 dba o to, by dostęp do narzędzi publikowania w sieci pozostał wolny i demokratyczny. Założona przez twórcę WordPressa – Matta Mullenwega, odzwierciedla filozofię stojącą za platformą WordPress.

Promuje takie projekty i oprogramowanie, które:

  • są objęte licencją GNU Public License,
  • są dostępne bez opłat – dla każdego i w dowolnym celu,
  • można modyfikować, a następnie dalej udostępniać,
  • umożliwiają tłumaczenie treści na inne języki,
  • dają się rozszerzać za pomocą wtyczek, bez modyfikowania głównego kodu.

„WordPressa poznałem w 2005 roku, kiedy szukałem czegoś, na czym będzie można łatwo założyć blog – wtedy to nie było takie oczywiste. Przetestowałem kilka rozwiązań, wiedziałem o istnieniu b2/cafelog, wiedziałem o b2evolution, które z tego wyewoluowało. Ale dowiedziałem się też o tym, że jest inna gałąź tej ewolucji. To był WordPress” – wspomina Łukasz.

Dziś WordPress to nie tylko platforma blogowa, ale styl życia. 140 WordCampów i 700 grup organizujących regularne spotkania poświęcone WordPressowi na całym świecie. Ponad 200 wersji językowych serwisu, 54 tysiące darmowych wtyczek, 3 tysiące szablonów stron. Na platformę WordPress składa się 350 tysięcy linii kodu, co można przeliczyć na 91 lat pracy developerów.

WordPress to od lat podstawowe narzędzie pracy i szczera pasja Łukasza, który udostępnia własne pluginy: Moje wtyczki dostępne w katalogu WordPress są zainstalowane na kilku tysiącach aktywnych stron gdzieś na świecie. Nawet nie wiem gdzie, ale gdzieś komuś się przydają. To niesamowite uczucie” – dodaje nasz developer.

Unaweza

Fundacja Martyny Wojciechowskiej, znanej z programu TVN „Kobieta na krańcu świata”. Powołana, by wyrównywać szanse ekonomiczne, społeczne i prawne kobiet i dzieci z różnych krańców świata.

Obecnie fundacja gromadzi środki na pomoc:

  • dzieciom z albinizmem, na które poluje się w Tanzanii,
  • dzieciom, które nie mają innych perspektyw niż przekopywanie śmieci w Meksyku,
  • dziewczynkom i kobietom – ofiarom handlu ludźmi w Rumunii.

„Tanzania i Meksyk mogą wydawać się odległe, ale Rumunia już nie tak bardzo. A to właśnie ona przoduje w Europie pod względem liczby dzieci sprzedawanych i zmuszanych do niewolniczej pracy w seksbiznesie. Unaweza ściśle współpracuje z organizacją Reaching Out Romania, ratującą kobiety i dzieci przed okrucieństwem” – alarmuje Łukasz.

Fundacja wkrótce rozszerzy swoją działalność na kolejne kraje: Salwador, Filipiny, Boliwię i Liban. Nazwa fundacji wzięła się od słowa „unaweza”, które w języku suahili oznacza „możesz”.

„Miałem przyjemność poznać Martynę Wojciechowską na rajdzie Orlen Trophy 4×4, dawno temu. Wierzę jej, dlatego wspieram fundację Unaweza prywatnie i bardzo mnie cieszy, że Sidnet też przekaże jej datek, zgodnie z moim wyborem” – mówi nasz developer.

#DarowiznySidnet: Olga dla Creative Commons Polska i hospiCare

Wnosi „human touch” do zespołu inżynierów. Przekłada z technologicznego na język odbiorcy. W Sidnet odpowiada za komunikację marketingową. Olga łączy w sobie analityczność i kreatywność. Wskazane przez nią wartościowe projekty open source i non-profit dobrze obrazują to połączenie.

Poznaj ludzkie oblicze technologii – projekty zasługujące na wsparcie według naszego człowieka od marketingu.

Creative Commons Polska

Polski oddział Creative Commons (CC) – organizacji non-profit, która pomaga dostosowywać prawo autorskie do realiów internetu i promuje powszechny dostęp do kultury i nauki. Creative Commons od 2001 roku udostępnia licencje i narzędzia prawne gotowe do użycia przez autorów zdjęć, nagrań, książek czy stron internetowych. To pozwala twórcy samodzielnie określać zasady dzielenia się swoją twórczością w internecie, a odbiorcom daje więcej praw do korzystania z udostępnionych przez niego materiałów.

4 podstawowe warunki licencji CC:

Uznanie autorstwa, CC-BY. Utwór możesz swobodnie kopiować, zmieniać, przedstawiać i rozpowszechniać, jeśli wskażesz autora oryginału i licencję.

Na tych samych warunkach, CC-SA. Utwór możesz swobodnie kopiować, zmieniać, przedstawiać i rozpowszechniać, pod warunkiem, że udostępnisz go na tej samej licencji.

Użycie niekomercyjne, CC-NC. Utwór możesz kopiować, zmieniać, przedstawiać i dystrybuować, ale nie możesz na tym zarabiać.

Bez utworów zależnych, CC-ND. Utwór możesz kopiować, przedstawiać i dystrybuować jedynie w oryginalnej postaci. Nie możesz tworzyć adaptacji, opracowań, remiksów.

Powyższe oznaczenia w różnych konfiguracjach można znaleźć w takich serwisach jak m.in.: Flickr, YouTube, Wikipedia, Medium, Behance.

„Ideę Creative Commons poznałam dzięki narzędziu CC0, które pozwalało mi wykorzystywać zdjęcia i grafiki bez wskazywania autora. To było bardzo przydatne na studiach, kiedy odpowiadałam za promocję koła naukowego i chciałam to robić bezkosztowo, ale (w miarę możliwości) profesjonalnie. Chcę wesprzeć polski oddział, który wraz z Centrum Cyfrowym Projekt: Polska pomaga m.in. instytucjom kultury i nauczycielom dzielić się i korzystać z otwartych zasobów.” – mówi Olga.

Ikony: Creative Commons, CC BY 4.0

hospiCare

Społeczny projekt aplikacji mobilnej, która usprawni współpracę wszystkich osób zaangażowanych w opiekę nad pacjentem dziecięcego hospicjum domowego.

„Nie znałam terminu hospicjum domowego, dopóki nie poznałam Elizy i Pauli – twórczyń hospiCare. Nie wiedziałam, że nieuleczalnie chore dziecko może być na stałe we własnym domu i jednocześnie pod opieką hospicjum. Ani tego, że w praktyce oznacza to wizyty kilkunastu specjalistów dziennie u jednego pacjenta, wymianę setek połączeń telefonicznych i wiadomości, ogromne ilości leków i rozproszoną dokumentację medyczną, której przybywa każdego dnia.” – mówi Olga.

Aplikacja hospiCare ułatwi pracę zespołów medycznych i pomoże opiekunom w codziennych zmaganiach z chorobą. Znajdą się w niej m.in.: pełna dokumentacja medyczna pacjenta dostępna online dla wszystkich uprawnionych, przypomnienia o dawkach leków, narzędzia ułatwiające zdalne konsultacje medyczne. Aplikacja będzie darmowa dla wszystkich dziecięcych hospicjów domowych w Polsce.

„Zachwycił mnie ten projekt, a jeszcze bardziej jego twórczynie. Dziewczyny czerpią z własnych doświadczeń w opiece nad terminalnie chorymi bliskimi, ale są dalekie od cierpiętnictwa. Mają konkretne pomysły na finansowanie hospiCare. W jego rozwój chcą angażować innych rodziców chorych dzieci, którzy często mimo wykształcenia i kompetencji nie mogą znaleźć pracy.” – dodaje Olga.

Ekipa hospiCare ciągle potrzebuje środków na rozwój i utrzymanie aplikacji. By wesprzeć projekt, wpłać pieniądze na konto Fundacji Zostaw Swój Ślad, w tytule przelewu wpisując „hospiCare”.

Święto technologii mobilnych w Łodzi. Relacja z Mobilization IX

Ostatnią sobotę spędziłem na konferencji zaprzyjaźnionego JUG Łódź. W przerwach między wspieraniem organizacji wydarzenia, wysłuchałem prelekcji o MVVM i CI/CD w budowaniu aplikacji mobilnych. Dzisiaj podzielę się wrażeniami z wykładów.

Otwarcie konferencji Mobilization IX 2019
Otwarcie konferencji (fot. Paweł Włodarski/Mobilization).

“Building a CI/CD pipeline for your mobile app”

Ponieważ w Sidnet stosujemy procesy ciągłej integracji i ciągłego dostarczania (CI/CD), chciałem sprawdzić, jak robią to inni i upewnić się, że niczego nie pomijamy.

Peter-John Welcome, który przyjechał aż z Johannesburga, przedstawił cały proces od początku do końca w sposób klarowny, w większości zbieżny z moim doświadczeniem. Continuous Integration i Continuous Deployment (/Delivery) to nic innego jak automatyzacja manualnych zajęć z codziennej pracy programistów i usprawnianie różnych jej aspektów.

Peter-John Welcome na temat CI/CD w budowaniu aplikacji mobilnych podczas Mobilization IX 2019
Peter-John Welcome podczas prelekcji na temat CI/CD w budowaniu aplikacji mobilnych (fot. Paweł Włodarski/Mobilization).

Prelegent przypomniał, że procesy w IT nie muszą być sztywne. Jeśli pojawia się potrzeba wyeliminowania któregoś kroku, to można to zrobić. Przykładowo, poruszył temat wykorzystania botów sprawdzających kod źródłowy (np. weryfikujących ustalone standardy kodowania czy formatowanie kodu), które wyręczają programistów. Uznał, że gdyby programiści nie prowadzili ze sobą zażartych dyskusji w Code Review na temat różnych standardów, to kontrolę przez boty można by pominąć.

Pomysł nieszkodliwy, ale w moim odczuciu nieoptymalny. Moje doświadczenie podpowiada, że wprowadzenie standardów eliminuje niepotrzebne dyskusje. Dla wszystkich w projekcie staje się jasne, jakiego formatowania kodu powinni się trzymać. Także bot ma wówczas proste zadanie – upewnić się, czy dany fragment kodu jest napisany zgodnie z określonym standardem. Automatyzacja tego kroku zaoszczędzi czas całego zespołu, dlatego nie rezygnowałbym z niej.

“MVVM as good (anti)pattern in iOS”

Wielu developerów zachwyciło się ostatnio wzorcem MVVM (Model-View-ViewModel). Czy robią słusznie, wykorzystując go w aplikacjach na iOS? Mateusz Szklarek uważa, że nie. Swój pogląd opiera na doświadczeniu m.in. z pracą nad aplikacją mobilną z 250 tysiącami linijek kodu źródłowego.

Mateusz Szklarek na temat wzorca MVVM w budowaniu aplikacji mobilnych podczas Mobilization IX 2019
Prelekcja Mateusza Szklarka poświęcona wzorcowi MVVM (fot. Paweł Włodarski/Mobilization).

Jak zauważył prelegent, MVVM eliminuje problem ogromnego pliku kontrolującego widok („Massive View Controllers”), który często występuje przy używaniu wzorca MVC (Model-View-Controller). W MVVM pojawia się jednak inny problem – ogromne pliki View Model (“Massive View Models”).

Model-View-ViewModel nie jest doskonały, bo doskonałe rozwiązania nie istnieją. To, czy dowolna idea lub narzędzie zda egzamin, w dużej mierze zależy od sposobu wykorzystania przez samych developerów. Zdaniem prelegenta nie warto podążać za tłumem i bezrefleksyjnie sięgać po MVVM.

Rozwiązanie? Jak zwykle – rozsądek. Ze wszystkich wzorów czy narzędzi należy korzystać racjonalnie. Rozwiązania powinny pasować do problemów, nie odwrotnie. Chcę też podkreślić (za prelegentem), jak ważne są zasady programowania. Trzymanie się ich umożliwia dopasowanie wybranego wzorca i przezwyciężenie problemów występujących w każdym z wzorców.

Chociaż nie było mi dane uczestniczyć w całej tegorocznej konferencji, to cieszę się, że mogłem pomóc organizatorowi.

“Krzysztof, szacun za gotowość do działania ramię w ramię w dniu konferencji. Dzięki za mobilizację!”

Marek Defeciński
Organizator Mobilization