Jakiś czas temu mój kolega wymyślił sobie, że fajnie by było mieć w komputerze różnego rodzaju pokrętła, dodatkowe przyciski i takie tam bajery. Że w założeniu na przykład jak ma uruchomionego Photoshopa to on jakimś fizycznym suwakiem sobie majta i mu się tam rozjaśnia, ściemnia czy co tam się w grafice robi. I kupił sobie tanią konsolę DJ-ską. A ja powiedziałem, że spoko, że na pewno da się zrobić, aby to można było oprogramować. I tak narodził się DjToKey. Aplikacja pozwala na przypisanie do każdego przycisku/pokrętła/suwaka dowolnego skryptu w JavaScript, który ma możliwość symulacji klawiatury i myszy. Więc ogólnie można sobie oskryptować dowolne (prawie) akcje.
Pierwsza wersja pojawiła się w maju zeszłego roku, a dzisiaj opublikowałem totalnie zmienioną wersję 0.4.
Screen:
Przykład działania: https://onedrive.live.com/redir?resid=499fa777f29b2f50!130833&authkey=!AEGjOSoizRXp1YU&ithint=video%2cmp4
Repozytorium: https://github.com/ktos/DjToKey
C# + WPF, ClearScript do obsługi JavaScriptu, midi-dot-net do obsługi MIDI, MahApps.Metro do wyglądu, podejście Git Flow plus GitVersion i MSBuildTasks do zapewnienia SemVer, AppVeyor do ciągłej integracji. No i MEF do pluginów. No i Newtonsoft.Json do JSON-a, którego jest tutaj sporo (definicje urządzeń, zapis skryptów użytkownika).
Bo to nie jest takie proste! Ponieważ w pewnym momencie stwierdziłem, że było by fajnie, gdyby dało się te skrypty rozwijać w taki sposób, że dorzucam .dll i mam w moich skryptach nowy obiekt z którego sobie mogę skorzystać. Więc narodziła się koncepcja pluginów dostarczających typy oraz obiekty skryptom. Używam MEF w taki sposób, że typy umieszczone wewnątrz głównego assembly też są ładowane przez MEF (na przykład) i w zasadzie można by je wyjąć poza i nic by się nie zmieniło.
A potem wyszło na to, że obsługa tylko urządzeń MIDI to słaba sprawa, było by lepiej, jakby mógł obsługiwać cokolwiek. Więc pluginy mają teraz również możliwość dostarczania "obsługiwaczy" dla różnych typów urządzeń. Obecnie są dwa - MIDI oraz Mock. Mock to fikcyjne urządzenie istniejące tylko w trybie Debug do testów. Docelowo chciałbym dodać obsługę czegoś jeszcze.
Pluginy muszą referencjonować PluginsContracts.
A potem stwierdziłem, że dobrze by było jakby istniały jakieś pliki, które dostarczają obrazek kontrolera i dostępne w nim przyciski. I jeden taki plik mógłby dostarczać wiele kontrolerów przecież. I tak narodziły się pliki DTKPKG oraz przestrzeń nazw Packaging. Paczki zgodne z OPC (niczym pliki DOCX) mogą przechowywać obrazki i definicje wielu urządzeń. Tutaj jest to jeszcze trochę rozbabrane i nie do końca działa tak, jak bym chciał. Docelowo DTKPKG mają też opakowywać pluginy, zamiast użytkownika wrzucającego pliki do /plugins.
Używam podejścia mniej więcej Git Flow - cała praca na branchu devel, potem branch release przed przejściem na kolejną wersję, potem merge do mastera, tam tagowanie. Każda zmiana mastera wypchnięta do GitHuba powoduje uruchomienie nowego builda na AppVeyorze, który buduje solucję, tworzy ZIP-a i wrzuca go na GH, gdzie ja go ręcznie mogę już opisać. Używam SemVer, i tam jeszcze jest trochę magii w postaci MSBuildTasks oraz GitVersion (w mojej własnej odmianie), które automatycznie generują AssemblyInfo.cs na podstawie historii Gita.
Teraz złe rzeczy:
- tak, wiem, że są wady w UI. Tak, okno kodu da się edytować bez zaznaczonej kontrolki i pewnie się coś wykrzacza po drodze. UI wymaga doszlifowania;
- tak, nie ma testów. Problemem jest to, że w większości ten kod wymaga fizycznego urządzenia podłączonego i działającego i sens mają głównie testy integracyjne, ale faktycznie, warto by je zrobić;
- tak, MVVM jest kulawy. Trzeba by jakoś poprawić,
- tak, pierwsze ~30 commitów było po polsku, ups.,
- tak, program jest naprawdę rozwijany w konwencji 2 dni pracy - 2 miesiące przerwy...
Sam kod wydaje mi się, że jest w miarę OK, oprócz paru szczegółów o których wiem, ale fajnie by było, jakbyście spojrzeli i ocenili co tam się dzieje. Możliwe, że jest trochę przesadzony w niektórych miejscach.