W poprzedniej części opisałem wymagania wobec projektu MemoryVisualizer. Teraz pora przejść do konkretów, czyli technologii. Dla przypomnienia, piszę narzędzie, które pozwoli za pomocą jakiegoś języka zapytań wizualizować pamięć procesu .NETowego - czy to z memory dumpa, czy poprzez podpięty debugger. Wizualizacja ma być ładna - by posłużyć kiedyś do celów ilustracyjnych. Oraz szybka - by docelowo analizować gigabajtowe procesy.
Będzie to oczywiście program dekstopowy, bo nie wyobrażam sobie aplikacji webowej, której uploaduje się gigabajtowe dumpy*. Szkic interfejsu wyobrażam sobie następująco:
Jak widać nie ma tu rocket science. Zresztą, ponieważ najważniejszy jest graf, niewykluczone, że ostatecznie interfejs uproszczę jeszcze bardziej. Obecnie Zapisane widoki zajmują trochę za dużo miejsca. BTW. wizualizacja nie ma sensu - zarówno język zapytań jak i wyniki będą wyglądać inaczej.
Wiedząc mniej więcej do czego dążę, wybrałem stos technologiczny jak poniżej. Oczywiście, całość porusza się w świecie .NET, bo nie widzę tu potrzeby zmiany technologii na siłę, a w zakresie desktopu .NET akurat sporo oferuje. Schodzić do poziomu WinAPI mi się nie uśmiecha, bo wydajność .NET mi wystarczy. Alternatywą mogłaby być jakaś międzyplatformowa technologia jak Qt/C++ lub Java, ale co za dużo to niezdrowo - ramę projektu muszę napisać w technologii, którą dobrze znam. Jednak by projekt był ciekawy, porywam się też na obszary, których dobrze nie znam. Ważne by rozsądnie to zbalansować.
GUI
Jeśli chodzi o GUI w .NET, obecnie wciąż rządzi WPF i właśnie na niego się zdecyduję. Oczywiście mógłbym użyć Win Formsów, ale po co? WPF oferuje naprawdę fajne możliwości więc opisywanie jego użycia może też być ciekawe dla Czytelników. Poza tym WPF-a znam, więc nie tworzę niepotrzebnego ryzyka.
Jeśli WPF, to zdecydowanie warto pójść w stronę, ku której został zaprojektowany - deklaratywnego bindowania danych. Zatem posłużę się wzorcem MVVM, który ma tu świetne moim zdaniem zastosowanie. To też może być ciekawe, bo realnych przypadków użycia tego wzorca nie jest znów tak wiele. Pewnie, dlatego że zanim się w całej mocy spopularyzował, wszyscy oszaleli na punkcie Weba. Jaki framework do MVVM jeszcze nie zdecydowałem, ale pójdę raczej w kierunku czegoś lekkiego, jak MVVM Light. Nie potrzebuję do tej aplikacji niewiadomo jakich featerów a użycie lekkiego frameworka pozwoli ukazać zalety MVVM w całej okazałości, nie przykrytej toną dodatkowych komponentów.
Logika
Wszystko co poniżej GUI napisane będzie w... F#. Modele danych, grafów obiektów itd. wydają się być dobrym miejscem, by rozpocząć naukę tego języka. Bo zbieram się do tego od lat, więc w końcu pora zacząć. Lubię języki funkcyjne z czasów studenckich i dobre opanowanie F# to jedno z moich ulubionych małych marzeń. Nie jestem pewny, jak skończy się temat implementacji języka zapytań, ale jeśli trzeba będzie go napisać samemu, funkcyjny F# również może się tu świetnie wpasować. Osobiście jestem podekscytowany zbliżającą się nauką F#.
Analiza pamięci
Tutaj samo mięcho - trzeba będzie ubrudzić łapki w trzewiach CLR. Merytorycznie to trzon projektu. Technologicznie, do analizy posłużę się prawdopodobnie świetnym CLRMD, jednak czy tylko nim i w jakim stopniu, pewności nie mam. Na pewno przeznaczę osobny wpis na wytłumaczenie jak i czemu możemy analizować pamięć .NET.
Język zapytań
Tutaj prawdziwe wyzwanie. Język zapytań muszę wymyśleć lub użyć jakiegoś istniejącego. Potem zaimplementować interpreter/parser albo użyć istniejącego. Dane o pamięci procesu są z mojego punktu widzenia danymi typu grafowego: obiekty mają do siebie referencje, mogą być również cykliczne. Adres obiektu jest jego ważnym atrybutem, ale nie zmienia grafowego modelu danych. Jeżeli zaś grafowe bazy danych, to kusi użycie neo4j - choć pojęcia nie mam jeszcze, czy to faktycznie sensowe. Natomiast na pewno sensowne wydaje mi się użycia języka zapytań używanego przez neo4j o nazwie Cypher. Albo jakiejś jego modyfikacji. Więcej szczegółów na pewno w niejednym poście, już niedługo.
Wszystkie powyższe założenia, plany i szkice mogą ulec zmianie, bo wpisy powstają wraz z rozwojem projektu. Niewykluczone więc, że jakąś funkcjonalność porzucę a inną dodam. Wszystko, jak to się mówi, "wyjdzie w praniu".
* jednak nie wykluczam napisania kiedyś lekkiego, webowego analizatora dumpów kilkusetmegowych. Co bogatemu szkodzi...
Post ten jest częścią serii wpisów dotyczących realizacji projektu MemoryVisualizer w ramach konkursu "Daj się poznać".