Dodano: 22.05.2010
Bardzo dziękuję wszystkim za odzew i chęć pomocy :) Wstępny team został już złożony, więcej informacji już niedługo. Będę wdzięczny, jeśli przestaniecie mnie przez ten czas zamęczać :P
Jak już setki osób zdążyło pomarudzić, rozwój Joggera stoi w miejscu. Powodów jest wiele, brak czasu zarówno mój jak i Sparrowa (praca, u mnie również szkoła), brak chęci z powodu torpedowania każdego możliwego pomysłu, ale przede wszystkim legacy code. Nie oszukujmy się - Jogger 2 powstał dobre 4 lata temu i jest napisany po prostu źle. Nie jest to niczyja wina, po prostu dla Sparrowa było to raczej poletko do nauki języka niż poważny projekt programistyczny. Część kodu była dodatkowo pisana w przyśpieszonym tempie ze względu na narzekania użytkowników żądających (nie, nie proszących) o wersję 2.0. W tamtych czasach królował PHP4, a piątka była ledwie na połowie serwerów, więc kod nie jest ani obiektowy, ani wygodny, ani łatwy w modyfikacji. Stąd zastój.
Kolejnym poważnym powodem, dla którego Joggera 2.6, 2.7 czy jakikolwiek numerek wersji by nie został dostawiony jest opuszczenie przez naszą załogę Riddla. Jesteśmy mu bardzo wdzięczni za rozwój front-endu przez te wszystkie lata, ale niestety praca, własne życie, a i również frustracja spowodowana powodem wymienionym wyżej zrobiła swoje. Nie da się rozwijać projektu non-profit gdy pomimo starań, nic nie idzie do przodu. Rozumiem to i szanuję, cieszę się za wspólnie spędzony nad kodem czas :)
Niestety każdy bardziej skomplikowany projekt developerski składający się z dużej ilości kodu CSS ma tą wadę, że staje się hermetyczny i ciężko jest nauczyć się czy nawet zrozumieć jak działają poszczególne klasy, jak powinen być zbudowany kod, i tak dalej, i tak dalej...
Obecnie Jogger dogorywa. Wspaniała platforma, którą pamiętam jako nieopierzony noobek z czasów początków boomu webdesignu w Polsce powoli, ale niemiłosiernie zdycha. Większość ludzi zdenerwowana brakiem rozwoju lub oczekiwanych przez nich ficzerów przeniosła się na inne platformy - Tumblr, Wordpress, Blogspot... Długo by wymieniać. Szczerze mówiąc nie jestem zdziwiony, ponieważ gdybym miał w tej chwili założyć bloga, zastanowiłbym się dwa razy zanim zrobiłbym to na Joggerze. Nie ukrywam, sporo w tym mojej winy - dostęp do kodu źródłowego, bazy i serwera mam od około 2 lat, a w tym czasie poza odpisywaniem na dziesiątki maili, poprawianiem drobnych błędów i pomaganiu użytkownikom z problemami, prawie nie ruszyłem kodu. Bugger 2.0 upadł ze względów praktycznych - głównie chodziło o front-end, którego jak wyżej wspomniałem po prostu nie potrafię ugryźć. Potem doszła frustracja marudzeniem, szkoła i setki innych wymówek ;)
Jedynym sposobem na uratowanie platformy jest przepisanie całego kodu od zera. Zdaję sobie sprawę, że większość projektów, które miały się skończyć rewritem najczęściej upadała, ale to jedyne wyjście, żeby cokolwiek się zmieniło. Problem polega na tym, że Jogger jest dużą platformą i przepisanie go od zera nie zajmie jednego czy dwóch weekendów, biorąc pod uwagę, że jesteśmy tylko we dwóch - Sparrow i ja, z czego tylko ja posiadam wymaganą wiedzę do 90% rzeczy, które powinny być zrobione od nowa.
Potrzebny jest nowy model rozwoju Joggera (tak!)
Zdaję sobie sprawę, że kwestia otwarcia kodu Joggera była poruszana już wielokrotnie. Wiele osób prosiło, groziło i pomstowało, ale Sparrow pozostawał nieugięty. Niestety, muszę się z nim zgodzić - kod po prostu nie nadaje się do wypuszczenia. Zawiera zbyt wiele dziur, zagmatwań i hacków.
Dlatego też zadaję teraz, otwarcie pytanie - czy są chętni do współpracy, nie pomocy, nie 'napiszę kilka linijek po obiedzie, a potem miesiąc nie będę się odzywał', tylko współpracy przy tworzeniu nowego, otwartego Joggera 3.0 bazowanego na PHP5 przy użyciu wygodnego frameworka, z nowym front-endem, nową funkcjonalnością i usuniętymi starymi, niepotrzebnymi quirkami i problemami?
Czy tylko potraficie siedzieć na dupie i marudzić, że nikt nie rozwija Joggera, a wy byście go zrobili oh tak jak bardzo zajebiście, ale wam się nie chce i nigdy (OpenJogger) nie chciało?
Dodano: 24.08.2009
I. Podekscytowanie
Wszystko zaczyna się gdy dostajemy nowe zlecenie. Pieniążki nęcą, wszystko wydaje się być proste, klient ma nawet ciekawe pomysły. Ustalamy terminy, może nieco zbyt optymistycznie, ale z nadzieją, że w najgorszym razie zarwie się kilka nocek. Wszystko jest cud, miód i orzeszki.
Zaczynamy pisać kod. Na początku tłucze się sam, wszystko jest banalne i idzie samo. Klient czasami coś tam doda od siebie, może pomarudzi, ale ogólnie nadal jest sympatycznie. Na wszystkie maile odpowiadamy błyskawicznie, odpisujemy klientowi na smsy, rozwiewamy wszystkie wątpliwości i odpowiadamy na pytania. Gdy już mamy prawie gotowy serwis, nadchodzi druga faza.
II. Irytacja
Nagle okazuje się, że połowa z tego co zrobiliśmy "jednak klientowi nie pasuje". Zaczyna się żmudne poprawianie i przerabianie już istniejących rzeczy. Specyfikacja, która wcześniej wydawała się klarownie jasna nagle okazuje się zagmatwana, bo to jednak nie o to chodziło. Dopiero wtedy zauważamy, że mnóstwo znaczników typu jak w serwisie XYZ tak naprawdę oznacza tak jak sobie wymyśliłem i trzeba się zdrowo domyślać. Najczęściej dotyczy to frontendu, ponieważ funkcjonalności są w mniejszym lub większym stopniu kopią.
Zagryzamy zęby - jeszcze jest czas. Do deadline zostało parę dni / tygodni, zdążymy wszystko zrobić.
III. Zdenerwowanie
Deadline. Straszliwa, czerwona krecha, która straszyła nas przez całą fazę drugą właśnie nadeszła. Projekt nadal nie jest skończony, ponieważ klient zażądał funkcjonalności, których nie było w specyfikacji. Na dodatek w trakcie sprawdzania błędów nagle okazuje się, że w kodzie jest mnóstwo małych, złośliwych chochlików, które psują całokształt. Klient zaczyna wybrzydać, że to mu nie pasuje, tamto nie działa, być może zaczyna nawet grozić zerwaniem umowy albo karami finansowymi. Poprawki zaczynamy robić na odwal się i przestajemy przejmować się optymalizacją.
IV. Frustracja
Tydzień po deadline. Dwa tygodnie po deadline. Klient nadal marudzi, nagle przestaje mu się podobać cały design. Wkurzasz się i przerabiasz. Zaczyna mu przeszkadzać to jak wcześniej działał serwis, też przerabiasz. Prawie każdy mail zaczyna być oznaczony pilne albo na dziś / do jutra musi być. Gdy siadasz do projektu, zaciskasz zęby i masz ochotę uderzyć monitor. Pieniądze, które w pierwszej fazie cię nęciły, teraz wydają ci się śmiesznie małe w porównaniu z tym przez co przechodzisz. I tak powoli, powoli przechodzisz do ostatecznej fazy.
V. Zniechęcenie / olewactwo
Masz już dość. Pieprzysz pieniądze, pieprzysz klienta, pieprzysz wszystko. Zaczynasz zajmować się pierdołami lub innymi zleceniami, bo nie możesz już patrzeć na dzieło twoich rąk, które jeszcze kilka tygodni wcześniej tak radośnie kodziłeś. SMSy od klienta zbywasz wciśnięciem przycisku, a na maila wchodzisz raz dziennie, żeby przejrzeć litanię poprawek. Dorzucasz je sobie do todo i idziesz się opieprzać. Od czasu do czasu skubniesz troche kodu lub nagłym zrywem nadziei poprawiasz wszystko tylko po to, żeby dostać kolejną listę. Etap ten kończy się w zależności od cierpliwości obu stron albo zakończeniem zlecenia, które jakościowo mocno odstaje od tego, co chcieliśmy uzyskać (głównie ze względu na poprawki klienta) albo zerwaniem umowy i utratą zlecenia, co kwitujemy krótkim łatwo przyszło, łatwo poszło i idziemy pracować nad czymś ciekawszym.
Uzupełnienie
W jaki sposób uniknąć takich sytuacji? Poniżej tłumaczenie tekstu 10 Reasons to Politely Decline a Web Design Gig. Oto lista czerwonych lampek, które powinny nam zaświecić podczas przyjmowania zlecenia. Właściwie jest to lista dla webdesignerów, ale poza 4, 8 i 9 dotyczy również developerów.
- 10. Klient wciąż powtarza ci jak bardzo jego poprzedni developer był do d...
- 9. Chce mieć pewność, że zrobisz stronę tak, żeby pojawiła się na pierwszych miejscach w Google
- 8. Ma już listę ponad 100 słów, które chce wrzucić w meta tagi
- 7. Nie ma aż tyle kasy za to zlecenie, ale jest sporo ukrytych drobiazgów, które spowodują nawał dodatkowej pracy
- 6. Klient chce wiedzieć czy jesteś elastyczny jeśli chodzi o pieniądze
- 5. Mówi ci, że za stronę będzie odpowiedzialny u swoich przełożonych
- 4. Chce wiedzieć, czy znasz się na Flashu
- 3. Chce, żeby jego strona była taka jak eBay (patrz fazę II wyżej)
- 2. Właściwie to sam mógłby zrobić stronę, ale nie ma czasu
- 1. Szuka nowego "webmastera"
Dodatkowo, przed chwilą znalazłem piękny filmik obrazujący sytuacje znaną z webdeveloperki/webdesignu, ale w odniesieniu do innych zawodów:
D4rky