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...
Siedzę w temacie analizy pamięci w .NET już jakiś czas. Zaczęło się od potrzeby, kilka lat temu - produkcyjne systemy miały jakiś wyciek i trzeba było namierzyć dziada. Złapałem bakcyla. Potem jeszcze wiele razy miałem okazję 'dłubać w dumpach'. Używałem już chyba wszystkich dostępnych na rynku narzędzi, wielokrotnie. Widziałem jak niektóre zmieniały się wraz z kolejnymi wersjami. Choć i tak 80% spraw rozwiązywałem ostatecznie w WinDbg. Narzędzi mamy więc naprawdę dużo i fajnych. Wymieniając choćby .NET Memory Profiler, ANTS Memory Profiler, jetBrains dotMemory.
Więcej...