Warning: ksort() expects parameter 2 to be long, string given in /home/platne/mwiacek/public_html/www/index.php on line 293 Też miałem przyjemność z Mozillą... Nie jest dobrze, moim zdaniem oczywiście. (2020) @ Marcin's page ON-LINE
 mwiacek.comColorColor | Mobile  
Też miałem przyjemność z Mozillą... Nie jest dobrze, moim zdaniem oczywiście. (2020)
Submitted by marcin on Fri 17-Jan-2020

Polski
Polski blog
dobreprogramy.pl
Android
TrueFenix
Chrome



Tym wpisem nie mam zamiaru się chwalić, tylko na swoim skromnym przykładzie chciałbym potwierdzić, że źle się dzieje w państwie duńskim.

Paradoksalnie zacznę od Google Chrome. To ogromny projekt, a mówiąc dosadniej kobyła.

Znają go wszyscy, a ja przez ostatnie kilka lat zgłaszałem tam trochę uzupełnień głównie do części napisanej w Javie (Android) - były to w większości optymalizacje i tzw. refaktoring kodu (tu uciąć 1000 linijek kodu, tam 1500, takie tam zabawy).

Oprócz kodu dosyć aktywnie podawałem tam wiele informacji o stosunkowo prostych błędach interface użytkownika czy błędach renderowania (dużo ich widziałem niejako przy okazji swoich głównych projektów).

Linki są na mojej stronie, bardzo duże rozczarowanie wzbudziło we mnie chociażby:

  • decyzja o wyłączeniu tzw. buildów Jumbo - tą decyzją Google wydłużyło czas kompilacji projektu o dobre kilkaset procent (np. z godziny do ponad czterech), w zamian jedynie proponując dostęp do swoich serwerów, ale... uwaga! tylko dla części konfiguracji. Nie muszę chyba dodawać, jak podobne działanie wpływa na zużycie energii elektrycznej i środowisko naturalne (w takich dużych projektach kompilacje robi się setki lub tysiące razy dziennie).
  • brak implementacji keydown i keyup - pomimo ogromnego zainteresowania użytkowników nikt wewnątrz firmy nie chce przyjąć żadnej opcji i tego poprawić.
  • wstrzymywanie zmian ulepszających napisane wieki temu elementy interfejsu - np. taka pierdółka czyli zwijanie czy rozwijanie grup w oknie historii wisi do dzisiaj
  • błędy regresji i podstawowe problemy ze zrozumieniem kodu przez osoby sprawdzające moje poprawki

Mógłbym podawać więcej przykładów, zauważyłem, że z czasem tzw. responsywność inżynierów zaczęła maleć, a błędy coraz częściej sprawdzali ludzie z pewnego państwa z Azji (co niestety odbiło się na jakości dyskusji).

Z miesiąca na miesiąc widziałem, że część inżynierów (reagujących naprawdę rewelacyjnie) odchodzi z tego projektu, a niektórzy pozostali stopniowo zaczęli zachowywać się coraz bardziej nazwijmy to zapobiegawczo w akceptowaniu jakiegokolwiek kodu.

Przyszedł grudzień 2019 i pojawił się chociażby błąd, przy którym część użytkowników mogło stracić swoje dane.... Zmiany w Chrome nie są normalnie wprowadzane z dnia na dzień i jeżeli coś takiego przeszło, to albo

  • nie było w ogóle testowane (nie wierzę, że nie przyjęto scenariusza, żeby zaktualizować aplikację z danymi) albo
  • mówiąc kolokwialnie zostało przepchnięte bokiem w ostatniej chwili

Źle, źle i jeszcze raz źle.

Myślę, że stopień skomplikowania kodu przekroczył pewne granice - starsi inżynierowie powoli odchodzą (z CV, gdzie jest wpis o pracy w Google, nie jest to trudne), młodsi mają bardzo dużo do nauki.

Sytuacji nie poprawia fakt, że spora część kodu została napisana w starszej Javie (wiem, wiem, że to nie Cobol, ale wszyscy zaczynają cieplej myśleć o Kotlinie niż o utrzymywaniu tysięcy linijek w Javie).

Widzę, że część firm wzięła ten kod i zmienia go u siebie na swoją modłę (np. taki Brave ma repozytorium na GitHub). Jest to tragedia - czasami zajmuje się tym garstka ludzi, którzy oprócz rozwijania nowości muszą się zajmować portowaniem zmian od Google.

Nie lubię tych forków, gdyż każda, ale to każda firma stawia sobie za cel dodanie swoich, czasem bardzo nachalnych, funkcji (tak samo zrobił Microsoft - mamy te wszystkie integracje).

Gdzie jest w tym użytkownik?

W tym momencie wrócę do Mozilli. Zdarza mi się używać jej aplikacji, i owszem czytałem o różnych problemach... ale jakoś mnie nie obchodziły.

Zgłosiłem kilka błędów do zespołu zajmującego się wersją Preview, i wróciłem do nich teraz w styczniu 2020.

Zespół pisze w swoim GitHubie, że jest mały, nie ma zasobów, itp.

Jak tak można? Chcą zdobyć użytkowników czy nie?

Myślę, że powinni zachęcać ludzi do zgłaszania ulepszeń, a nie odstraszać.

Jeden z moich zgłoszonych błędów dotyczył tego, że nie działa JetStream 2. Po prawie trzech miesiącach i moim followup dostałem informację, że w sumie problem jest taki, że Gecko pyta się o to, że wykonywać dalej wolny skrypt, czy nie (i nie dostaje odpowiedzi).

Dodanie tego to w najprostszej wersji trzy linijki kodu, nie muszę chyba dodawać, że nie zadziało się to do dziś (o tym jeszcze poniżej).

Udało mi się przeprocesować jeszcze trzy zmiany, i niestety okazało się, że na tym chyba koniec - problem był nawet w zmianie na dwie linijki kodu (jeśli dobrze zrozumiałem aż trzeba było się zastanawiać, czy URL bar ma mieć tekst w jednej czy dwóch linijkach)

Czy widzieliście kiedyś przeglądarkę, która miałaby element do wpisywania URL w dwóch linijkach?

Myślę, że aplikacja mobilna powinna być priorytetem, tymczasem w mojej ocenie okazuje się, że błędy będące faktycznie podstawą (JetStream2) są na dole listy, a zewnętrzne zmiany często są wręcz niemile widziane.

Powiedziałbym, że to może być zrozumiałe (ludzie z zewnątrz mogą nie znać zasad, pisać niskiej jakości kod, etc.), ale im dalej w las (kod), tym więcej grzybków.

Zacząłem się bawić kodem i już na pierwszy rzut znalazłem miejsce do różnych optymalizacji czy przeróbek na lepsze.

Kilka zrzutów ekranu (widać ekran główny, gdzie obszar jest lepiej rozdysponowany; ustawienia, gdzie wszystko jest logiczne; historię ze zwijalnym obszarem):

image image image image image image image

Mój plan jest prosty - w wolnym czasie zamierzam popracować trochę na GUI, robiąc go logicznym i prostym do bólu, a potem przejść niżej.

Kilka przykładów:

  • Chcę usunąć kolekcje - zrobić zamiast nich foldery zakładek (po co dwa obiekty?)
  • Chcę dodać zmienialną stronę główną - nie ma już tej wielkiej części z logiem (bądź co bądź użytkownik wie, czego używa), ale jest miejsce na najczęściej otwierane, itp.
  • Chcę usunąć telemetrię, która istotnie może spowalniać całość
  • Chcę usunąć błędy, które są widoczne na pierwszy rzut oka

Na dzień dzisiejszy potwierdzam, że źle się dzieje w państwie duńskim i polityczna poprawność w Mozilli zasłoniła pracę inżynierską - mają niezłą podstawę, ale co najmniej kilka projektów mobilnych (stąd niepotrzebny podział zasobów) i dużo, ale to dużo "misji".

W mojej ocenie to obecnie korporacja, która ma w nazwie "fundacja".

Stąd mój projekt, który jest teraz eksperymentem (ma mi pokazać, czy w krótkim czasie można coś z tego wszystkiego zrobić), ale mógłby przerodzić się w coś większego. Całość planuję umieścić na GitHub. Nie interesuje mnie, czy ktoś tu napisze, że się chwalę, że się chcę dowartościować, itp.

Napisanie przeglądarki to dzisiaj gigantyczna robota, nie zmienia to faktu, że podobne zabawy z kodem dają solidną dawkę wiedzy do innych projektów.

Miałem już w życiu dwie podobne sytuacje:

  1. w 1999 zrobiłem fork projektu Gnokii, potem napisałem swój, który zmieniałem do 2007 (wtedy pojawił się iOS i projekt zaczął tracić rację bytu; kod jest zmieniany i używany do dziś)
  2. ok. 2011 zrobiłem coś lepiej niż inni - pewne rzeczy wtedy zaczęte służą mnie i tysiącom użytkowników do dziś

Jeżeli się teraz uda, to może za jakiś czas będzie seria artykułów.