OneNoteNotifier – plan działania

Po co planować?

Przed rozpoczęciem prac nad jakimkolwiek większym projektem, warto najpierw sobie wszystko poukładać w głowie, a później przelać to na papier (lub zapisać na innym dowolnym nośniku danych, jak kto woli). Dzięki temu będziemy mieli plan działania, który poprowadzi nas do określonego celu – w tym przypadku jest to działająca aplikacja, spełniająca swoją funkcję. Wystarczy tylko ów plan konsekwentnie realizować. Proste, prawda? Otóż nie do końca. Trudno jest bowiem ułożyć perfekcyjny plan realizacji, który pozostanie niezmienny do ostatniego etapu procesu tworzenia. Na szczęście nie o to chodzi. Plan nie musi być doskonały ani niezmienny. Plan może (a nawet powinien) ewoluować, w zależności od różnych sytuacji napotykanych podczas implementacji poszczególnych części aplikacji. Ważne jest natomiast, aby główne cele zostały niezmienne i w końcu zrealizowane.

Z własnego doświadczenia wiem, że poważne potraktowanie etapu planowania owocuje podczas samego kodowania. Dzięki temu, że mamy jasno określone cele, łatwiej nam się skupić na ich realizacji. Kiedy zaczynałem pisać aplikacje typu pet project i nie miałem jasno określonych celów (wiedziałem co program ma robić, ale nie zdefiniowałem jasno wymagań), łapałem się na tym, że podczas kodowania dorzucałem różne nowe funkcjonalności, których nie planowałem, a wydawały mi się użyteczne. Przez to projekt nie był kończony, bo nie realizował głównych założeń, ale miał masę pobocznych funkcji. Kiedy mamy jasno określone cele główne, pozostaje tylko konsekwencja w ich realizacji. Masz pomysł na dodatkową funkcjonalność? Super, ale dorzuć ją dopiero w kolejnej wersji, a póki co: stick to the plan!

Drugą, równie istotną, zaletą planowania jest identyfikacja potencjalnych problemów jeszcze przed procesem kodowania. Rzetelnie przeprowadzona identyfikacja pozwoli na dobór odpowiednich technologii, bibliotek oraz narzędzi. Dodatkowo ograniczymy liczbę zastojów wynikających z natrafienia w późniejszym etapie na poważny problem, o którym wcześniej nie pomyśleliśmy. Dzięki temu będziemy w stanie uniknąć (lub przynajmniej ograniczyć) ilość ślepych uliczek. Tak w procesie powstawania oprogramowania nazywam moment, w którym pojawia się problem nie do obejścia i który zmusza nas do cofnięcia się o krok (lub kilka) w celu zmiany już zaimplementowanych funkcjonalności, wykorzystywanych bibliotek, czy nawet architektury. Musimy zdać sobie jednak sprawę, że prawdopodobnie nie będziemy w stanie przewidzieć wszystkiego jeszcze w przedbiegach. Nie powinniśmy się też tym szczególnie przejmować. Jeśli przyłożymy się do etapu planowania, najprawdopodobniej uda nam się wyłapać wszystkie poważne problemy na początku, a te które zostaną powinny być możliwe do rozwiązania bez konieczności przepisywania połowy kodu.

Kolejną istotną kwestią jest dobór odpowiednich narzędzi do realizacji naszego projektu: język programowana, IDE, frameworki, biblioteki itp. Tutaj wszystko zależy od zdefiniowanych wcześniej wymagań, zidentyfikowanych problemów oraz naszych preferencji. W przypadku tej części planowania musimy być jednak ostrożni, możemy bowiem wpaść w pułapkę tzw. paraliżu analitycznego, czyli zbyt długiego zastanawiania się nad wyborem odpowiednich narzędzi. Dlatego jeśli nie wiemy, której biblioteki użyć (ale wiemy, że obie są dobrze napisane oraz poradzą sobie ze zdefiniowanym problemem) i nie mamy konkretnych upodobań, rzućmy monetą – pozwoli to nam zaoszczędzić czas i nerwy.

Podsumowując, podczas etapu planowania należy:

  1. Ustalić zakres funkcjonalności do zaimplementowania w pierwszej wersji aplikacji.
  2. Zidentyfikować potencjalne problemy do rozwiązania, związane z realizacją wymagań funkcjonalnych.
  3. Dobrać odpowiednie narzędzia do realizacji projektu.
  4. Przygotować ogólny plan implementacji.

Pragnę nadmienić, że opisane tutaj podejście jest kwestią raczej indywidualną i działa w moim przypadku. U innych może to wyglądać trochę inaczej. Zachęcam do pisania w komentarzach jak to wygląda u Was.

OneNoteNotifier – plan działania

Po teorii przyszedł czas na praktykę, czyli mój plan realizacji projektu konkursowego – OneNoteNotifier. Jak wspominałem w poprzednim wpisie,  aplikacja ma za zadanie powiadamiać współużytkowników danego notesu (lub notesów) o wprowadzanych zmianach. Pierwsza wersja ma obsługiwać powiadomienia email oraz integrować się z komunikatorem Slack. Nadszedł czas na zdefiniowanie dokładniejszych założeń.

Główne założenia funkcjonalne

  • Użytkownik, korzystając z dedykowanego UI (w tym przypadki aplikacja webowa), może podejrzeć swoje notatniki oraz poszczególne sekcje (bez stron).
  • Dla każdego notatnika i sekcji, użytkownik może dodać, usunąć lub skonfigurować akcje powiadomienia o zmianach (powiadomienia email i/lub Slack). Jeśli powiadomienie jest definiowane na poziomie całego notatnika, dotyczy ono wszystkich sekcji z danego notatnika.
  • W przypadku dodawania powiadomień email do obserwowanego obiektu, użytkownik powinien móc określić adresy email użytkowników, do których ma trafić informacja o zmianach.
  • W przypadku dodawania powiadomień w komunikatorze Slack, użytkownik powinien móc zdefiniować kanał na którym pojawi się stosowna wiadomość.
  • Powiadomienia o zmianach powinny przychodzić do użytkowników możliwie jak najszybciej.
  • Instalacja powinna być przebiegać automatycznie (w miarę możliwości).

Założenia techniczne

  • Do komunikacji z zewnętrznymi serwisami zostanie wykorzystane dedykowane RESTful API:
  • Cały system będzie składał się z trzech komponentów:
    • Aplikacja webowa stanowiąca interfejs użytkownika.
    • Aplikacja konsolowa działająca w tle, jako zaplanowane zadanie Harmonogramu Windows (Windows Scheduler) lub jako usługa (Windows Service).
    • Instalator.
  • Dane konfiguracyjne oraz data ostatniej modyfikacji notatnika/sekcji będą przechowywane w bazie danych.

Potencjalne problemy

  • W przypadku powiadomień email, użytkownik najprawdopodobniej będzie musiał sam wpisać adresy email, ponieważ wszystko wskazuje na to, że OneNote API nie pozwala na pobranie informacji o osobach, którym dany notes udostępniono.
  • Należy ustalić, z jaką największą częstotliwością można odpytywać usługę OneNote API, tak żeby klient nie został zablokowany.
  • Należy zweryfikować, czy zadanie sprawdzające status zmian w notatnikach OneNote i wysyłające powiadomienia, może być wykonywane co minutę. Windows Scheduler nie pozwala na ustawienie odstępu czasowego mniejszego niż 1 minuta, więc jeśli zadanie będzie musiało być wykonywane częściej, należy je uruchomić jako usługę Windows (Windows Service).

Wybrane narzędzia

  • Nancy – lekki framework do budowy aplikacji webowej.
  • xUnit – framework do tworzenia i uruchamiania automatycznych testów jednostkowych oraz integracyjnych.
  • Dapper – lekki ORM.
  • Topshelf – framework ułatwiający tworzenie usług Windows. Tylko w przypadku, gdy Windows Scheduler nie sprosta zadaniu.
  • .NET 4.5:
    • System.Net.HttpClient – do stworzenia klientów OneNote API oraz Slack API.
    • System.Net.Mail – do wysyłania powiadomień email.
  • SQL Server 2014 Express – serwer bazodanowy.

Tak wstępnie prezentuje się plan dotyczący tworzenia aplikacji OneNoteNotifier. Tak jak zostało wspomniane na wstępie, niektóre elementy tego planu mogą ulec zmianie. O wszystkich zmianach będę informował na bieżąco. Nadszedł więc czas, żeby wziąć się za konkretną robotę.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *