Aplikacyjne Alternatywy
Natknąłem sie na fajna stronę: AlternativeTo – być może sie komuś się przyda, bo mi na pewno. Idea serwisu jest prosta, umożliwia wyszukiwanie aplikacji o podobnym zastosowaniu. Przykładowo szukamy aplikacji funkcjonalności podobnej do Adobe Photoshopa, oto co otrzymamy:
Niby podobne funkcje oferują, że tak je nazwę ‘agregatory’ oprogramowania jak tucows czy nasz rodzimy dobreprogramy.pl. Jednak AlternativeTo przejrzystością i prostotą bije je na głowę.
ALT .NET
Właśnie zauważyłem, że całkiem niedawno, bo w Grudniu ubiegłego roku, powstała w Dublinie grupa ALT .NET. Jest to pierwsza tego typu inicjatywa w Irlandii. Spotkania tego typu są świetną okazja do poszerzenia swoich wiadomości jak również spotkania ludzi o podobnych zainteresowaniach. Dla tych, co nie wiedzą, czym jest ALT .NET krótkie wyjaśnienie ze strony społeczności:
We are a self-organizing, ad-hoc community of developers bound by a desire to improve ourselves, challenge assumptions, and help each other pursue excellence in the practice of software development.
Źródło: http://altdotnet.org/
Kolejny tydzień
Kolejny (drugi już) tydzień w nowej pracy. Emocje związane ze zmiana otoczenia powoli opadają i nachodzą mnie pierwsze refleksje. Przede wszystkim różnica jest jest ogromna wcześniej pracowałem dla malej firmy wprowadzającej innowacyjne rozwiązania korzystając z najnowszych narzędzi dostępnych na rynku. Teraz dla odmiany wylądowałem w jednym z działających w Irlandii banków. Ot, taki skok od wytartych jenas’ów i nieoficjalnego podkoszulka do koszuli z kołnierzykiem i krawata. Zafundowano mi również mała techniczna podroż do przeszłości wracam do Visual Studio 2005. Po roku pracy z VS 2008 miałem przed tym pewne obawy, jednak jakoś strasznie tego nie odczuwam, prawdopodobnie dzięki Reshaper’owi. Bardziej denerwuje mnie brak np. LINQ, gdyż zmuszony jestem pracować na wersji 3.0 .Net Frameworka. Niesamowite, jak szybko sie człowiek przyzwyczaja do takich drobnych udogodnień. W sumie i tak ponoć jestem szczęściarzem, gdyż projekt nad którym rozpoczynamy prace uchodzi za niezwykle nowatorski – .NET 3.0, Windows Workflow i WCF. Jak dla banku to ogromny skok, z .NET 1.1 czy VB6. Pożyjemy zobaczymy, jak na razie czeka mnie nauka logiki biznesowej i pisanie specyfikacji technicznej, może najciekawsze zadanie ale ale cóż poradzić taka specyfikacja pracy. Jedno co mnie poraża to bezwładność całej machiny, na wszystko trzeba czekać dzień, dwa lub więcej. Administratorzy to juz chyba największe lenie 
wczoraj mi sie taki przypałętał aby nadać mi wymagane uprawnienia – wszystko było by ok gdyby nie to, ze zgłosiłem zapotrzebowanie równo tydzień wcześniej. W takim tempie na zmianę literówki w moim adresie email przyjdzie mi chyba poczekać pół roku jak nie więcej
Zmiany…
Trochę ostatnio ucichłem! Wiem przyznaję się bez bicia. Powodów jest kilka – moje lenistwo, brak weny i ogólne zmęczenie to jedno. Taki swoisty syndrom wypalenia zawodowego. Dlatego zrobiłem sobie taki troszkę dłuższy, bo prawie dwu miesięczny – off od pracy, komputera programowania.
Jest jeszcze inny powód – zmieniam firmę. Lubiłem poprzednie miejsce, dobrze się mi tam pracowało, miałem dobry kontakt z współpracownikami i przełożonymi. Jednak wszystko, co dobre, kiedyś się kończy.
Znalazłem już sobie nową firmę, właśnie przeglądałem kontrakt, zaczynam w przyszłym tygodniu. Z tego, co mi wiadomo – rusza jakiś nowy projekt technologia – ASP.NET 2.0, Visual Studio 2005, SQL Server 2005. Mały downgrade, nie będzie LINQ, które zdążyłem naprawdę polubić, nie będzie też urządzeń mobilnych. Ale to świadomy wybór.
Pracowałem z urządzeniami przez ostatnie 3 lata i nauczyłem się sporo, widziałem zmiany, jakie nastąpiły w podejściu do programowania urządzeń mobilnych jak i narzędzi to umożliwiających. Wiem, że wcale nie tak łatwo napisać dobrą mobilną aplikację – ograniczeń jest wiele procesor, pamięć, bateria, narzędzia etc. Ale to się zmienia – z każdą nową wersją .NET CF, z każdą nową wersją systemu – jest prościej, bardziej kompatybilnie z pełną wersją Frameworka. Urządzenia też są coraz potężniejsze, posiadają coraz szybsze procesory, coraz więcej pamięci – obecnie ich raptowny rozwój jest ograniczony pojemnością baterii i szybkością, z jaką producenci, opróżniają swoje magazyny, z aktualnie wyprodukowanych modeli. Specjalizacja jest dobra, ale tylko, jeśli jest potrzebna, a z moich obserwacji wnioskuję, że za jakieś dwa-trzy lata będziemy mieli urządzenia mobilne, na których bez wysiłku będzie działać pełna wersja.NET Framework’a . I specjalizacja zaniknie.
Czyli – pro aktywnie, mając na względzie, swoją karierę zawodową – szukam innych ciekawych obszarów, w których mogę wykorzystać swoje umiejętności programistyczne. Od jakiegoś czasu obserwuję obszar ASP.NET i tego, co się z nim dzieje. Jeśli ktoś śledzi mojego bloga, zauważył pewnie, moją pewną niechęć do technologii webowych (przynajmniej tych Microsoft’owych) – wynika to może z poprzednich doświadczeń i braku odpowiednich wzorców. Swego czasu mało, kto wiedział o wzorcach z rodziny MVP a jeszcze mniej osób stosowało i miało ugruntowaną praktykę ich wykorzystania. W większości małych-średnich projektów programista pisał kod i zajmował się designem, a projekt i kod zwykle wyglądał jak – steaming pile of shit (jak to obrazowo powiadają Irlandczycy). Nikła struktura, mało czytelne, byle działało – typowy spagetti-code. Takie były, przynajmniej, moje odczucia. Nic tylko uciekać – tak też zrobiłem, ale przyglądałem się jego rozwojowi gdzieś z oddali, czasem chwilę popracowałem z jednym czy drugim projektem ASP.NET nic wielkiego, ale obserwowałem. I pojawiły się znaki, najpierw pojawiło się coś takiego jak WCSF, później spotkałem się z czymś jak język Ruby i ostatnio ASP.NET MVC. Koniec wolnej amerykanki, strukturyzacja etc., Czyli wracam i się nawracam na web – zobaczymy co z tego wyjdzie. 
Jest jeszcze inny może nieco mniej znaczący powód – programowanie mobilne – ciągle jest taką nieco odrębną sztuką. Ilość dodatkowych bibliotek, framework’ów jest bardziej niż ograniczona. I jest się trochę jakby po za nawiasem, głównego nurtu społeczności programistycznej. Zabawa z Linq 2 Sql, Entity Frameworks, NHibrenate, Windsor Container, Rhino, Dynamic Proxy etc. jest po prostu niepraktyczna bądź w ogóle niemożliwa. A bez poznawania nowych bibliotek, framework’ów nie ma szans na rozwój zawodowy – nic tak nie pogłębia naszej wiedzy jak właśnie – analiza i wykorzystanie kodu napisanego przez innych. I trzeba z tego korzystać, szczególnie, że nam za to płacą…
Dynamic Proxy
Jednym z popularnych wzorców projektowych jest wzorzec Proxy. W skrócie, obiekt pełniący rolę proxy, implementuje interfejsy i zarządza, zgodnie z jakąś logiką, wywołaniami metod jakiejś innej klasy. Przykładowo, załóżmy, że mamy następujące klasy:
Kod:
public interface IMessageSender
{
void Send(string message);
void Send();
} public class SimpleSender : IMessageSender
{
public virtual void Send(string message)
{
Console.WriteLine("Send() - with praram: " + message);
}
public virtual void Send()
{
Console.WriteLine("Send() - no praram");
}
}
public class Sender : IMessageSender
{
private readonly IMessageSender _sender;
public Sender(IMessageSender sender)
{
_sender = sender;
}
public void Send(string message)
{
// tutaj implementujemy dodatkową logikę sterującą wysyłaniem wiadomości
Console.WriteLine("Send action controlled by Sender object.");
_sender.Send(message);
}
public void Send()
{
// tutaj implementujemy dodatkową logikę sterującą wysyłaniem wiadomości
Console.WriteLine("Send action controlled by Sender object.");
_sender.Send();
}
}
W powyższym przykładzie Sender jest klasą proxy dla klasy SimpleSender. Obie klasy implementują interfejs IMessageSender, przy czym tylko klasa SimpleSender ‘wie’ jak wysłać wiadomość. Obiekt proxy (Sender) implementuje dodatkową logikę sterującą wywołaniem poszczególnych metod klasy SimpleSender. Przykładowe wywołanie metody Send():
Sender proxy = new Sender(new SimpleSender());
proxy.Send();
Istnieje możliwość automatycznego generowania klas proxy w trakcie działania aplikacji – zwana Dynamic Proxy. Przy korzystaniu z tej techniki zwykle korzysta się z dodatkowych bibliotek jak Castle DynamicProxy czy LinFu.DynamicProxy. W poniższym przykładzie wykorzystałem tą ostatnią bibliotekę:
using LinFu.DynamicProxy;
public interface IMessageSender
{
void Send(string message);
void Send();
}
public class SimpleSender : IMessageSender
{
public virtual void Send(string message)
{
Console.WriteLine("Send() - with praram: " + message);
}
public virtual void Send()
{
Console.WriteLine("Send() - no praram");
}
}
public class MessageSenderInterceptor : IInvokeWrapper
{
private readonly IMessageSender _sender;
public MessageSenderInterceptor(IMessageSender sender)
{
_sender = sender;
}
public void BeforeInvoke(InvocationInfo info)
{
Console.WriteLine("We are about to call method: " + info.TargetMethod);
}
public object DoInvoke(InvocationInfo info)
{
return info.TargetMethod.Invoke(_sender, info.Arguments);
}
public void AfterInvoke(InvocationInfo info, object returnValue)
{
}
}
IMessageSender i SimpleSender są dokładnie takie same jak w poprzednim przykładzie, nowością jest klasa MessageSenderInterceptor implementująca interfejs IInvokeWrapper. Jak widać z implementacji definiuje on metody określające co się stanie przed, w trakcie i po tym jak w kodzie wywołamy metody zawarte w naszym bazowym interfejsie IMessageSender. Na koniec, sposób wywołanie metody Send():
var proxy = new ProxyFactory();
var senderInterceptor = new MessageSenderInterceptor(new SimpleSender());
var finalSender = proxy.CreateProxy<IMessageSender>(senderInterceptor);
finalSender.Send("Hello World!");
Wszystko prosto ładnie, tylko nasuwa się pytanie po co? Po co dodawać dodatkowe referencje do nowych bibliotek, po co korzystać z ProxyFactory i innych interfejsów, skoro można napisać to wszystko prosto samemu?
Fakt jeśli mamy jedną, dwie klasy implementujące interfejs IMessageSender których zachowanie chcielibyśmy w jakiś sposób zmodyfikować – to jasne, nie ma sensu bawić się w Dynamic Proxy.
Jeżeli natomiast klas tych jest więcej Dynamic Proxy zaoszczędzi nam sporo fatygi w implementowaniu obiektów proxy dla poszczególnych klas implementujących IMessageSender, nie mówiąc już o mniejszej ilości klas do przetestowania. Co więcej zastosowanie dowolnego Dependency Injection Framework pozwoli nam uczynić Dynamic Proxy niewidoczne dla programisty korzystającego z naszego kodu.
.NET CF – uwagi o pamięci/szybkości działania
Microsoft ma swoje ‘best practices’ i ja mam swoje Generalnie to co przedstawię poniżej to taki własny, nieuporządkowany, ‘core dump’ różnych informacji, wygrzebanych gdzieś po zakamarkach różnych dokumentacji i poradników. Wskazówki, głównie, dotyczą problemów z pamięcią i szybkością działania aplikacji pracujących pod kontrolą .NET Compact Frameworka i systemów Windows Mobile.
- Im większy rozmiar pliku *.exe tym wolniej aplikacja będzie się ładować. Gdzieś tam wyczytałem, że szybkość ładowania w przybliżeniu wynosi 1Mb na 1s. Samemu nie mierzyłem, wierzę na słowo. Główną przyczyną spowolnienia jest kontrola uprawnień. Aby zmniejszyć rozmiar możemy nie podpisywać naszego assembly, klucz publiczny swoje zajmuje (oczywiście nie zawsze może to być możliwe). Po drugie warto zrezygnować z umieszczania zasobów wewnątrz naszej aplikacji (embedded resources) i ładować je w miarę potrzeb w trakcie działania aplikacji.
- Właściwości (properties) klas są traktowane, przez kompilator, jako odwołania do metod. Czasem więc lepiej skorzystać z publicznego pola, szczególnie w obiektach intensywnie wykorzystywanych w wszelkiego rodzaju pętlach. Z podobnych względów dobrze jest, do minimum, ograniczyć zastosowania takich słów kluczowych jak abstract czy virtual. Pamiętajmy jednak, że data binding czy LINQ operują jedynie na właściwościach.
- Koszty wywoływania metod:
- wywołanie metody z instancji klasy to w przybliżeniu 2-3x koszt wywołania funkcji z .NET CF (ciekawe czemu taka różnica?)
- wywołanie metody wirtualnej to ok. 1.4x wywołania metody z instancji klasy zarządzanej
- wywołanie metody przy pomocy mechanizmu P/Invoke to ok. 5x kosztu wywołania metody z instancji klasy zarządzanej.
- Pętla foreach wywołuje metody wirtualne na kolekcji – szybciej będzie jak skorzystamy z pętli for.
- Po zakończeniu pracy z kolekcją zadbajmy o jawne usunięcie jej elementów – zmniejszymy tym samym pracę jaką będzie musiał wykonać garbage collector.
- Minimalizujemy ilość tworzonych śmieci. Pracując z łańcuchami znaków pamiętajmy o klasie StringBuilder.
- Starajmy się zminimalizować operacje boxing/unboxing.
- Nigdy nie korzystamy z operacji GC.Collect() – osobiście jeszcze nigdy nie spotkałem sytuacji wymagającej jej zastosowania. Zwykle kiedy chcemy ją wywołać jest już za późno i niepotrzebnie spowalniamy działanie naszej aplikacji. Garbage Collector aby wykonać swoje zadanie musi zatrzymać wszystkie wątki. .NET Compact Framework automatycznie wywołuje GC.Collect(); zanim wyrzuci OutOfMemoryException.
- Obsługa wyjątków nie stanowi większego obciążenia, chyba, że sami rzucamy wyjątki (throw). Nigdy nie korzystamy z wyjątków do kontroli pracy aplikacji. Chwytamy tylko te wyjątki którym możemy zaradzić, całą resztę obsługujemy w zdarzeniu UnhandledException.
- Ograniczamy korzystanie z mechanizmu refleksji. O ile wykorzystanie typeof(…) nie stanowi większego problemu, to dostęp do pamięci przy urzyciu Type.InvokeMember() jest już od 10 do 100 razy wolniejsze od wywołania zwykłej metody.
- Pamiętajmy o nadpisaniu metod ToString(), GetHashCode(), Equals() – domyślne implementacje wykorzystują refleksję.
- Praca z xml’em wymaga użycia refleksji.
- Korzystanie z web services oznacza korzystanie xml’a – dobrze jest przechować referencję w pamięci i nie tworzyć ją za każdym razem gdy korzystamy z usługi.
- Korzystając z statycznych form dobrze jest je utworzyć w tle np. przy starcie aplikacji, a dane przekazywać tuż przed ich wyświetleniem.
- Jeśli generujemy zawartość formy w trakcie działania aplikacji pamiętajmy o korzystaniu z metod SuspendLayout/ResumeLayout.
- Pamiętajmy operatorze -= przy pracy z wyjątkami, nie wiem jak z aktualną wersją .NET Compact Framework ale w starszych wersjach pozostawienie przypisanego zdarzenia, prowadziło do wycieków pamięci w trakcie zamykania formy.
- Motoda Dispose() jest po to aby z niej korzystać po zakończeniu pracy z obiektem. Bardzo częstym problemem jest nie wywoływanie jej dla obiektu SqlCeCommand. Koszt wywołania operacji z bazą danych SQL Compact Edition w głównej mierze zależy od ilości danych a nie rodzaju zapytania. Im więcej danych tym więcej natywnych zasobów zajmuje obiekt SqlCeCommand ich nie zwolnienie prowadzi do wycieków pamięci. Pamiętajmy, klauzula using(…) jest naszym przyjacielem.
- Korzystamy z obiektów SqlCeDataReader bądź w bardziej wymagających wypadkach SqlCeResultSet. Zapominamy o takich obiektach jak DataSet czy DataTable. Jedynym wyjątkiem jaki w tym momencie przychodzi mi na myśl jest zastosowanie Microsoft Synchronization Services for ADO.NET (przynajmniej, na tyle ich jeszcze nie poznałem aby stwierdzić czy nie da się inaczej).
- SqlCeConnection – dyskusji o tym czy powinno się korzystać z jednego połączenia czy wielu, podczas pracy z aplikacją mobilną, toczyło się wiele. Generalnie jeśli naszym problemem jest szybkość aplikacji korzystamy tylko z jednego, cały czas, otwartego połączenia. Natomiast borykając się z brakiem pamięci, dobrze jest otwierać, zamykać i niszczyć połączenie w miarę potrzeb, gdyż alokuje ono pewną ilość zasobów natywnych.
- Każda aplikacja pracująca w systemie Windows Mobile 6 ma do dyspozycji 32Mb przestrzeni adresowej i musi się w niej nasza aplikacja łącznie z bibliotekami .NET CF.
- Każda dodatkowa biblioteka dołączona do naszej aplikacji, niezależnie od jej rozmiaru, zajmuje minimum 64Kb, więc jeśli korzystamy z dużej ilości małych plików dll (zwykle np. 10-20kb) może okazać się, że marnujemy dużą ilość przestrzeni adresowej.
Wiele z tych porad wydaje się całkiem oczywistych, niektóre jednak wydadzą się zapewne dziwne, wręcz przeczące zdrowemu rozsądkowi. Pamiętajmy, jednak , że piszę tutaj o nie tylko o okrojonej wersji .NET Framework’a ale również zmodyfikowanej do potrzeb i możliwości urządzeń mobilnych.
Zdarza się, że w niektórych prezentacjach/tutorialach (zwykle tych wprowadzających) autorzy piszą, że aplikacje mobilne pisze się tak samo jak aplikacje desktopowe. Jest to całkowicie, nieprawda, fakt .NET CF pozwala nam korzystać, w większości przypadków, z tych samych funkcji co desktopowy odpowiednik, jednak założenia i sposób implementacji, dobrej, aplikacji powinny być inne.
OpenNetCF dla Visual Studio 2008
Pojawiła się nowa wersja biblioteki OpenNetCF, rozszerzającej możliwości .NET Compact Framework. Nosi ona numerek 2.3 i oprócz zmian w samej bibliotece została ona przystosowana do pracy z Visual Studio 2008 (niestety nie w pełni). Zmianie uległo również nazewnictwo, obecnie mamy następujące wersje:
- Community Edition (darmowa)
- Standard Edition
- Professional Edition
Porównanie wersji można znaleźć tutaj, natomiast wersję Community można pobrać z tego adresu.
Mobile Architecture Pocket Guide
Microsoft w ramach ‘Patterns & Practices’ opublikował – ‘Mobile Architecture Pocket Guide’ – przegląd zalecanych praktyk i wskazówek przy projektowaniu aplikacji mobilnych. Przewodnik wcale nie nie wydaje się ‘pocket’ gdyż porusza wszystkie ważne tematy, od architektury aplikacji mobilnych poprzez poszczególne warstwy aplikacji (presentation, business, data access, service) po wskazówki dotyczące komunikacji ze światem zewnętrznym i schematy rozpowszechniania aplikacji.
