MD Tech Blog

Mój projekt nie jest wielką innowacją. Istnieje już całkiem sporo narzędzi do pisania tekstu, ale dzięki temu mam na czym się wzorować. Jest MS Office, OpenOffice, AbiWord, WPS Office i wiele innych.

Skoro istnieją aplikacje podobne do mojej to czemu nie miałbym trochę z tego skorzystać? Korzystając z dobrodziejstw projektów open-source’owych, mogę zobaczyć jak dana funkcjonalność została zaimplementowana.

Już od jakiegoś czasu miałem oko na spróbowanie F#. Połączenie szybkiego programowania funkcyjnego wraz z potężną biblioteką .NET brzmi bardzo fajnie i takie jest w rzeczywistości.

Zobaczyłem, że NUnit ma w swoich przykładach projekt w F#, więc postanowiłem przepisać moje obecne testy na F#. Nie przewidziałem jednak trudności wynikających z nieznajomości tego języka…

Dotychczas nie pisałem testów (jakoś kod testowałem ręcznie) i odkrywam jak bardzo są pożyteczne. Po pierwsze i najważniejsze, umożliwiają wykrycie błędów w implementacji klas zanim zaczniemy ich używać.

Tworząc nowy projekt testów w Visual Studio dostajemy MSTest, który nie działa pod Linuxem. W związku z tym sięgnąłem po NUnit.

Jest wiele sposobów na znajdowanie błędów w aplikacji: dowody matematyczne, testy jednostkowe, ręczne testowanie i debugowanie. Niestety debugowanie może być bardzo czasochłonne jeśli nie wiemy, w którym miejscu znajduje się problem. Tworzenie logów może nam pomóc zlokalizować ten problem.

Istnieje kilka .NETowych frameworków do logowania, m.in. log4net, WisdomCloud.Log i NLog, który postanowiłem użyć w moim projekcie. Można go pobrać z NuGet:NLog.

Piszemy kod, commitujemy, pushujemy. I jesteśmy potem zajęci, zapominamy o kodzie. W tym czasie ktoś stwierdza, że ściągnie sobie nasze repo. Więc klonuje, pobiera paczki, odpala build i … nie działa.

Powyższe spowodowane jest tym, że programista nie zawsze pamięta by skompilować, uruchomić, przetestować kod po wprowadzeniu zmian. Powinien pamiętać, ale zdarza się, trudno. To jest jeden ze scenariuszy gdzie CI, czyli Continuous Integration, może pomóc.

Jakiś czas temu pisałem o DI i IoC oraz o tym, że będę używał kontenera do automatycznego ładowania wielu modułów podczas startu aplikacji. Początkowo zrobiłem metodę ContainerWrapper.AutoRegister(), która iterowała po wszystkich bibliotekach związanych z SharpOfficem i rejestrowała odpowiednie klasy. Ale było to dość zagmatwane, więc postanowiłem trochę to uprzątnąć.

W weekend zdecydowałem się na upublicznienie mojego zmigrowanego bloga, więc pofatygowałem się na stronę mojego providera domeny i zmieniłem CNAME na manio143.github.io, aby domena wskazywała w nowe miejsce.

Zastanawialiście się kiedyś co się stanie jeśli serwery DNS aktualizują cache z różną prędkością?

Czemu postanowiłem zmienić silnik bloga? Głównie z powodu mojej niecierpliwości. Czas oczekiwania ~10 sekund (a czasem dłużej) na stronę zachodzi za skórę. Rozwiązanie nr. 1 - plugin cache’ujący. Rozwiązanie nr. 2 - Jekyll. Wybrałem Jekyll.

Aby dodać trochę kontekstu, dodam, że postawiłem stronę na Azurze (AppService) wraz z maszyną wirtualną do bazy danych. Możliwe, że takie ułożenie również przyczyniło się do spowolnienia strony. Wraz ze zmianą silnika na Jekyll, robię migrację bloga na GitHub, ponieważ jest taniej ($7/miesiąc), a jako student mam to za darmo.

Jakie kroki musiałem przejść aby zakończyć migrację?

Moja ,,stacja robocza” składa się z dwóch laptopów - jednym z Windows 7 i drugim z linuxem Manjaro. Po co mi dwa systemy? Pierwszy powód - lubię linux, nawet bardzo, ale są aplikacje, których na nim nie uruchomię (Visual Studio, Adobe After Effects, etc.). Drugi powód - bardzo lubię ideę aplikacji cross-platformowych i ze względu, że sam próbuję taką napisać, potrzebuję dwóch środowisk do testowania.

Ale nie o tym chciałem napisać. Moim ulubionym systemem kontroli wersji jest GIT, więc instaluję go na każdym swoim komputerze. Jestem również wyznawcą korzystania z gita z linii poleceń, bo często jest to szybsze i przyjemniejsze niż jakiekolwiek gui. Jedyną płaszczyzną kiedy uruchamiam aplikację niekonsolową jest historia, czyli gitk. Nie mam nic przeciwko git log / git show, ale gui jest ciut czytelniejsze.

Dawno, dawno temu, w zeszłym roku napisałem post ,,Working Windows&Linux dual-boot”, w kórym opisałem kroki jakie trzeba zrobić aby zainstalować GRUB bootloader po instalacji Windowsa. Te kroki dotyczą również instalacji dowolnego innego systemu.

Ponieważ robiłem te same kroki czwarty albo piąty raz, przypomniałem sobie powiedzenie:

Jeśli robisz coś więcej niż raz, można to zautomatyzować.

Więc napisałem skrypt w bashu, który w dużym stopniu upraszcza moje zmagania.