Zasadniczo robię dwa typy projektów po godzinach. Te, które mają mnie czegoś nauczyć i te, które mają przynieść jakąś wartość innym. Projektem drugiego typu jest Star Trek API, nad którym pracuję w ramach tegorocznego konkursu DSP.

Zrobiłem przez ostatnie trzy lata kilka projektów na GitHubie i dwa poza nim – nieudane POC-i. Historia większości z nich była podobna – zaczynałem je robić, po czym z różnych powodów je porzucałem.

Moje projekty

• Mój pierwszy wrzucony na GitHuba projekt, a jednocześnie jedyny w tej chwili ukończony, to simone, javascriptowy manager okien. Zyskał nawet kilka gwiazdek na GitHubie i parę osób wykonało forki. Na szczęście ten projekt nie wymaga ode mnie utrzymania, być może dlatego, że nikt go na poważnie nie używa.
• Kolejny był qunit-desktop-notifications, plugin do QUnita, który prawie ukończyłem, ale straciłem nim zainteresowanie, ponieważ skończyłem w pracy projekt, w którym QUnit był w użyciu. Ten projekt, w przeciwieństwie do simone, był już budowany na Travisie i miał raporty z pokrycia kodów testami trzymane na Coveralls. Jego zakres był tak wąski, że nie sądzę, żeby kiedykolwiek komuś się przydał.
• Następnie był ComicCMS2, próba stworzenia następcy dla ComicCMS. Dodatkowo realizowanym celem było zaznajomienie się z technologiami, których miałem używać w nowej pracy. Były to głównie Zend 2, Doctrine, PHPUnit i Angular. Porzuciłem ten projekt, ponieważ zmieniałem technologię na Javę.
• Aby zmienić technologię na Javę, rozpocząłem projekt Carmen. Miał to być projekt, który pozwoli na zbieranie statystyk na temat wszystkich repozytoriów na GitHubie, i, z czasem, także statystyk z innych źródeł (Bitbucket, GitLab, itd.). Zawiesiłem go na czas robienia Star Trek API, ale widzę jeszcze jakąś szansę, że do niego wrócę, w przeciwieństwie do wcześniejszych projektów.
• Były też 2 projekty, które nie wyszły poza fazę proof of concept. Pierwszym z nich była pisana w Rubym aplikacja, która miała za zadanie porównywać pliki PSD. Została porzucona, ponieważ bibliteka do parsowania PSD, psd.rb, była zabugowana w stopniu, który uniemożliwiał pracę nawet z prostymi plikami.
• Drugim projektem, który nie wyszedł poza fazę POC, była próba przepisania części Gita na PHP, w celu umożliwienia wrzucania kodu na serwery tam, gdzie nie było Gita – a pracowałem w PHP z klientami, którzy mieli naprawdę archaiczne i ubogie serwery, i żadnej woli upgrage’u. Porzuciłem projekt, ponieważ przepisywanie kodu z C i implementacja protokołu Gita w PHP mnie przerosły.
• Był jeszcze mały projekt szkoleniowy, z którym chciałem się nauczyć Django i Reacta, ale spędziłem nad nim raptem 4 dni.

Wnioski

W eseju Katedra i bazar znajdujemy zdanie mówiące, że every good work of software starts by scratching a developer’s personal itch. Dobrze sprawdza się to w moim przypadku. Problem w tym, że wówczas, gdy personal itch przestaje mi dokuczać, także projekt przestaje być przeze mnie rozwijany. I tak stało się z kilkoma z nich. Dostrzegam tutaj wzorzec.

Wydaje mi się też, że nie idzie mi dobrze łączenie prób nauki technologii z próbami stworzenia wartości dla innych. Robiąc projekt, który ma mnie nauczyć technologii, z konieczności wybieram coś łatwiejszego w stosunku do tego, na co mógłbym się zdecydować, gdybym pracował ze znaną mi technologią. Tym samym, gdy zaznajomię się już z technologią, projekt przestaje być interesujący.

Kilka moich projektów wzięło się z problemów, które napotykałem w pracy. Przeglądarkę diffów plików PSD chciałem zrobić dlatego, że graficy, z którymi pracowałem, nie informowali o zmianach, które robili, ograniczając się do przesłania nowej wersji pliku. Reszty trzeba było się domyślać. qunit-desktop-notifications chciałem zrobić dlatego, że javascriptowe testy długo trwały i nie wiedziałem, kiedy się skończyły, więc chciałem mieć tę informację w notyfikacji dekstopowej. Implementację części Gita w PHP chciałem zrobić dlatego, że klienci, z którymi pracowałem, nie mieli Gita na swoich serwerach. Z czasem, gdy to przestawało być moim problemem, przestawałem się interesować projektami, które miały rozwiązać problem.

Wydaje mi się, że lepiej wychodzi mi robienie projektów, gdzie znajduję coś, czego jeszcze nie ma, co mnie fascynuje, i co jest w moim zasięgu. Wówczas jest szansa, że to skończę. A co do tych projektów, w których tylko uczę się technologii, być może po prostu trzeba zaakceptować, że będą one porzucone, gdy już z zaznajomię się z technologią, w której naukę celowałem.