Podsumowanie Daj Się Poznać 2016

I oto nadszedł – koniec konkursu “Daj Się Poznać 2016”. Dzisiejszy wpis jest ostatnim – dwudziestym – postem konkursowym. Czas więc podsumować te ostatnie trzy miesiące.

Konkurs kosztował mnie (jak i wszystkich uczestników) mnóstwo pracy i czasu. Pod wieloma względami (nakład pracy, rozwijanie projektu, opisywanie go, wymagana systematyczność, wiszący nad głową termin) przypominał mi zeszłoroczne zmagania z pracą magisterską.

Czy było warto? Na pewno. Jakie mam odczucia względem efektu końcowego? Cóż, mieszane. Najłatwiej będzie mi je sprecyzować, jeśli podzielę je na dwie kategorie:

Projekt

Jeśli chodzi o projekt, to mam powody do zadowolenia. Udało mi się stworzyć silnik wykonujący wyrażenia, opracować składnię zapisu tych wyrażeń i zaimplementować parser tej składni. Ujmując rzecz bardziej szczegółowo, na chwilę obecną DSLExecutor implementuje / wspiera / posiada:

• 3 rodzaje wyrażeń: wartości stałe, funkcje, zbiory wyrażeń,
• silnik wykonujący te wyrażenia,
• łatwe dodawanie funkcji “biblioteki standardowej”,
• dość łatwą implementację parserów składni DSL,
• testy automatyczne kluczowych modułów,
• apkę webową pozwalającą na własnoręczne przetestowanie wykonywania wyrażeń.

Jest to solidna baza, która sprawia, że gdybym miał implementować podobne funkcjonalności w rzeczywistym projekcie, zaproponowałbym właśnie wykorzystanie DSLExecutora. To mój pierwszy pet project, o którym mogę to powiedzieć – stąd powody do zadowolenia.

Tę bazę można jednak dalej rozbudowywać. Podczas implementacji kolejnych fragmentów co chwilę przychodziły mi do głowy pomysły na nowe funkcjonalności. Niestety ostatecznie po prostu nie miałem czasu na ich dodanie. Zbiorę je tutaj, bardziej jako notatki dla siebie niż informacje dla Czytelnika. Przydałoby się:

• Zebrać to wszystko do kupy. Teraz DSLExecutor i parser są wołane osobno – warto stworzyć pojedyncze, spójne API.
• Wesprzeć konfigurowalność, np. różne sposoby ładowania funkcji i ich handlerów.
  • Kod jest mniej więcej przygotowany, pozostało dostosować konstruktory głównych klas.
  • Ciekawostka: motywacja do spełniania punktów takich jak ten i poprzedni jest wprost proporcjonalna do liczby użytkowników narzędzia (czyli niezbyt wysoka ).
• Wesprzeć nowe typy wyrażeń:
  • zmienne:
    • deklaracja i inicjalizacja zmiennych,
    • używanie zmiennych (tak jak stałych),
  • definiowanie funkcji,
  • z drugiej strony, w sporej części DSLi pewnie wystarczą stałe i wywołania funkcji (czyli to co jest).
• Dodać kontekst wywołania funkcji, czyli stan przekazywany pomiędzy funkcjami w obrębie całego pojedynczego wykonania DSLa:
  • Np. musiałem się nagimnastykować aby zaimplementować funkcję Log tak, żeby nie mieszała logów z różnych requestów,
  • Mając kontekst, mógłbym łatwo zaimplementować zmienne używając funkcji, np. dodając funkcje:
    • SetVar([nazwa zmiennej], [wartość]) – pisząca do kontekstu,
    • GetVar([nazwa zmiennej]) – czytająca z kontekstu.
• Wesprzeć przeciążanie funkcji.
• Rozbudować aktualną składnię DSL:
  • wesprzeć liczby ujemne (wstyd się przyznać, ale kompletnie o nich zapomniałem ),
  • wesprzeć lambda expressions (np. jako literał o wartości typu IExpression).
• Wesprzeć inne składnie:
  • np. odwrotną polską,
  • a potem wyciągnąć część wspólną parserów, żeby łatwiej było dodawać nowe.

Jak widać, większość z tych pomysłów to kroki w stronę implementacji platformy do tworzenia pełnoprawnych języków programowania, a nie DSLi – dlatego ich priorytet był raczej niski. Co więcej, ich realizacja wymagałaby oczywiście zmian w paru klasach, ale nie wywróciłaby kodu do góry nogami – a to dodatkowy powód do zadowolenia.

Podsumowując, z projektu jestem zadowolony – pokodowałem sobie

Danie się poznać

Jeśli jednak chodzi o drugi aspekt konkursu, czyli “danie się poznać”, to poszło znacznie gorzej. Pisanie postów szło mi raczej mozolnie i ciężko, nie zawsze udawało mi się zgrabnie zmieścić w postach wszystko, co chciałbym w nich zawrzeć. Być może regularne blogowanie nie jest jednak dla mnie.

Co więcej, nie znalazłem w sobie zacięcia do “uspołecznościowiania” bloga. Nie byłem obecny na konkursowym Slacku, dotNETomaniaku, fejsie czy twitterze (oprócz automatycznych wordpressowych powiadomień na ostatnich dwóch). Co za tym idzie, statystyki odwiedzin bloga nie są imponujące. W tym miejscu chciałbym pozdrowić regularnego komentatora postów, BONZO. Dzięki i pozdro!

Czy zatem uważam bloga za kompletną klapę? Nie. Opisywanie postępów prac pozwoliło mi przez cały czas mieć świadomość tego, w jakim stanie jest projekt i jaka jest droga do celu. Kilkukrotnie pisząc posty wykryłem luki w swoich rozwiązaniach. Na potrzeby bloga narysowałem kilka diagramów, które mi samemu pomogły poukładać rzeczy w głowie. Poza tym, sam fakt pisania postów – jako ustrukturyzowanych tekstów dłuższych niż smsy – jest rozwijający (a właściwie hamujący degradację językową).

Podsumowując, mimo społecznościowej porażki, blogowanie dla samego siebie uważam za sukces. Z doświadczenia wiem, że zestaw “projekt + apka + kod źródłowy + blog” bardzo atrakcyjnie wygląda w CV.

Co dalej

Na koniec wypadałoby napisać, czy zamierzam kontynuować blogowanie i pracę na projektem. Odpowiedź na to pytanie wymaga trochę prywaty.

Otóż wygospodarowanie czasu na konkurs było dla mnie naprawdę sporym wysiłkiem. Mniej więcej od połowy konkursu musiałem przestać kodować w weekendy, mniej więcej połowa postów powstała w pociągach. To wszystko dlatego, że… za niecały miesiąc biorę ślub, a chwilę potem wybywam w podróż poślubną. (Jeśli masz wrażenie, że to kiepska wymówka, Czytelniku, to sam weź ślub .)

Odpowiedź jest zatem prosta: przez najbliższe tygodnie moje myśli będą dość daleko od kodu i bloga. W przyszłości (mam nadzieję, że niedalekiej) prawdopodobnie podejmę kolejną próbę wyjścia z cienia – jeszcze nie wiem, w jakiej formie. A tymczasem dziękuję za uwagę, pozdro i do zobaczenia na Gali Finałowej!