Jak już nie raz wspominałem, chciałbym by sercem MemoryVisualizera był język zapytań oparty o Cypher, a właściwie leżąca pod spodem baza grafowa Neo4j. Ma mi to zapewnić dużą ekspresyjność zapytań oraz (mam nadzieję) dużą szybkość działania. Tutaj pojawia się pewien drobny temat do przemyślenia. Neo4j napisany jest w Javie i szczęściarze piszący w tym języku mogą załączyć ten silnik jako część swojej aplikacji. Niestety w aplikacji .NETowej o takim self-hostowaniu nie może być mowy. Portu Neo4j na .NET nie ma, choć pojawiły się i takie pomysły, np. w formie Neo4Net. Ciekawa dyskusja na ten temat odbyła się na grupie lists.neo4j.org. Więcej...
W poprzedniej części wątku WPFowego projektu MemoryVisualizer skupiłem się na przypomnieniu, czym jest i jak implementować komendę (interfejs ICommand) w C#. Dla przypomnienia, napisałem ogólne rozwiązanie, któremu podaje się odpowiednie metody, dzięki czemu jest całkowicie reużywalne:
public class CommandHandler : ICommand
{
private Action action;
private Func<bool> canExecute;
public CommandHandler(Action action, Func<bool> canExecute)
{
this.action = action;
this.canExecute = canExecute;
}
public event EventHandler CanExecuteChanged;
public bool CanExecute(object parameter)
{
return canExecute();
}
public void Execute(object parameter)
{
action();
}
}
Muszę to przełożyć na F#, żeby używać komend w MemoryVisualizerze. Więcej...
Memory Visualizer wymaga udostępnienia języka zapytań odnośnie obiektów i struktur w pamięci. Jak pisałem w części Cypher, co to jest?! , język ten nazywam MQL - Memory Query Language. W istocie jest to jednak po prostu Cypher, który rozszerzę o elementy kontrolujące sposób wyświetlania.
Aby sobie przypomnieć, co chcę osiągnąć, wróćmy do przykładowego rysunku z opisu projektu:
Więcej...
Opis projektu MemoryVisualizera toczy się w kilku wątkach. Jednym z nich jest moja przygoda z F# w kontekście WPF. Po pierwszej części, w której w ogólności opisywałem jak możemy “pożenić” WPF z F#, pora kolejne kroki. Ale wcześniej potrzebne nam będzie krótkie przypomnienie z WPF w C#. Rzecz się tyczy użycia komend, do wykonywania akcji. Oraz nieśmiertelnego OnPropertyChanged do notyfikowania interfejsu o zmianie – ale o tym w kolejnej części.Więcej...
Obiekty w pamięci tworzą całkiem rozbudowany graf. Mają pomiędzy sobą referencje, są też poukładane w segmenty w ramach pamięci procesu, które to możemy potraktować również jako kolejny węzeł w grafie. W tym sensie segment może być rodzicem wielu obiektów, które zawiera itd. W każdym bądź razie, tak jak już było obiecane, pora zastanowić się nad językiem zapytań do owych grafów. Choć padały inne propozycje (m.in. użycie SPARQL), ja jednak pozostaję pod nieustającym wrażeniem prostoty i przejrzystości języka Cypher, używanego w grafowej bazie danych Neo4j. Więcej...
To będzie tutorialowy wpis dla początkujących, ale mam nadzieję, że komuś się przyda. Mimo że nie dotyczy wprost projektu MemoryVisualizera, od początku istnienia konkursu obiecywałem sobie przygotować taki mini poradnik nt. jak rozpocząć nowy projekt na GitHub. Cel - tworzymy nowe repozytorium na GitHubie, commitujemy pierwsze zmiany, tworzymy brancha na jakiś feature. Potem go mergujemy. Przy okazji nauczymy się trochę używania gita i może jakiś innych, fajnych narzędzi. Ze względu na długość, poradnik podzielony jest na kilka części. W tej stworzymy repozytorium i zaczniemy je lokalnie modyfikować. Więcej...
Kilka godzin pracy z F# w Visual Studio i kilka niespodzianek już za mną. Zainstalowanie Visual F# Tools (pozwalające tworzyć projekty F# w Visual Studio) jak się okazuje to był dopiero początek. Więcej...
Wstępniak: Uczę się używać F# wraz z postami o tym projekcie. Nie wszystko więc pewnie od razu będzie idealne. Za to w zamian cenne może być to, że dzielę się uwagami, spostrzeżeniami i zaskoczeniami w ramach tego procesu.
Po trzech pierwszych, wprowadzających postach pora wreszcie przejść do konkretów - kodu! MemoryVisualizer ma być aplikacją desktopową, napisaną w WPF. Nie mam jeszcze ani jednej linijki kodu, zacznę zatem od pustej aplikacji z jakiegoś szablonu. Gdybym zdecydował się na C#, sprawa byłaby prosta - startuję z pustego szablonu WPF Desktop Application i już. Mamy tam z pudełka obsługę XAML, code behind, designer itd. Jednak jak najwięcej chcę napisać w F#, zatem rodzi się pytanie - czy i jak zintegrować WPF z F#? Więcej...
Po części opisującej projekt MemoryVisualizera oraz jego techniczne aspekty, pora na opis metodyki prac, jaką chciałbym zastosować. Aczkolwiek nie będzie to długi opis bo...
MVP, MVP, MVP!
Właściwie główną koncepcją, której chcę się trzymać, to podejście MVP - Minimal Viable Product. Świetnie się sprawdziło ostatnio, gdy z chłopakami tworzyliśmy cfp.help. Jestem głęboko przekonany, że to jedyne słuszne podejście do tworzenia swoich pet projectów. O co chodzi? W skrócie - piszemy jak najmniej, byle działało. Nie brniemy w tygodniowe wybieranie idealnej biblioteki, idealnej architektury, idealnej nazwy i idealnego wszystkiego innego. Piszemy szybko działający prototyp i później go rozwijamy. Daje to bardzo ważną rzecz - statysfakcję. Dość szybko zobaczymy, że "coś mamy". Potem na naszych oczach możemy to "coś" ulepszać, co również motywuje. Więcej...
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.
Więcej...