Ww.CodeSculptor

Moze jest tu cos fajnego

2008-11-21T10:18:00Z

W nawiązaniu do postu Jakuba, podejmując tę zabawe, chciałem oznajmić że:

Może coś napisze dziś, a może jutro, a może później. Nie żeby to pewnie kogoś zainteresowało, ale "kolorytu"^*) doda

;-)

^*) To sympatyczne określenie zaczerpnięte od Michała Grzegorzewskiego. Michał! dołącz się do kolorowania... Więc chodź pomaluj nasz świat/Na żółto i na niebiesko...

Zadanie - Komunikacja klient-serwer

2008-10-27T08:21:00Z

Arek próbuje zacząć bardziej praktyczne podejście do tematów omawianych na wg.net. Jako ze pomysł mi się podoba, to może teraz ja opisze pewien problem na który się natknąłem.

Problem

Mamy układ klient-serwer z komunikacja po TCP/IP. Czyli serwer otwiera gniazdko (Socket lub TcpListener), klient łączy się, następuje wymiana wiadomości i klient się rozłącza. A teraz więcej szczegółów.

Wiadomość to poprawny dokument XML, można założyć na potrzeby tego przykładu ze to tylko znaki ASCII wiec mapowanie wiadomość ciąg bajtów jest trywialne.
Wymiana wiadomości przebiega tak ze klient wysyła wiadomość do serwera i zaczyna słuchać odpowiedzi. Potem wysyła kolejna wiadomość i nasłuchuje odpowiedzi.
Serwer robi to samo tylko symetrycznie. Najpierw przyjmuje połączenie, potem wczytuje wiadomość od klienta.
Generuje odpowiedz i ja wysyła. Potem znowu nasłuchuje wiadomości od klienta lub końca połączenia.
Serwer oczekuje przy odbiorze tylko bajów wiadomości i sam wysyła tylko bajty wiadomości-odpowiedzi.

Zadanie

Jak wydajnie/sprytnie/prosto zaimplementować cześć kliencka? Chodzi o takie rozwiązaniem, które niekoniecznie będzie jak najbardziej niskopoziomowe, lecz proste i łatwo utrzymywane. Można użyć Socket czy TcpClient. Niech w tym rozwiązaniu szybkość wymiany informacji raczej będzie limitowana ograniczeniami fizycznymi sieci niż jakimś skomplikowanym przetwarzaniem informacji z sieci przez klienta.

Uwagi

Implementacja serwera jest stała i nie można jej zmieniać.
Przykładowa implementacja serwera może być taka ze generuje losowa wiadomość jako odpowiedz o długości od 200 B do 8 kB.
Należy oczekiwać ze czasami (powiedzmy 10%) sytuacji będą opóźnienia na sieci kilkunastu/kilkudziesięciu milisekundowe, czasami parę sekund.
Pytania proszę zadawać w komentarzach.

Podręczne szyfrowanie danych w .NET

2008-10-21T14:47:00Z

Ten tekst powstał w nawiązaniu do artykułu Michała Grzegorzewskiego [Zabawy z LSA - wydłubywanie haseł usług] oraz Jego nawoływaniu do napisania czegoś o ProtectedData i ProtectedMemory.

ProtectedData

Wyobraźmy sobie scenariusz gdzie posiadamy ekran logowania wraz z opcją zapamiętania hasła użytkownika. Opcja zapamiętywania służy temu głównie, aby użytkownikowi opcjonalnie sugerować jego hasło gdy działa głównie na jednej stacji roboczej. Zazwyczaj przecież jest tak, że pracujemy w domu czy pracy na jednej maszynie która jest nawet przypisana do nas jako część stanowiska pracy.

Akt 1

Przykład ten ilustruje projekt ZineNet.DataProtection.Act1. Podczas uruchamiania aplikacji użytkownik wpisuje nazwę użytkownika oraz hasło i zaznacza/odznacza opcję "zapamiętaj hasło". Hasło zapisywane jest w jeden z typowych sposobów dla aplikacji .NET, czyli ustawieniach użytkownika Properties/Settings.settings. Przy kolejnej autentykacji hasło jest już wpisane i tylko użytkownik wpisuje nazwę i wciska "Enter". Co za user experience! Przecież nikt nie lubi zapamiętywać haseł!

Zajrzyjmy teraz co stało się z zapamiętaną wartością hasła. Plik konfiguracji uzytkownika możemy w naszym przypadku znaleźć w katalogu profilu użytkownika, coś mniej więcej:
Local Settings\Application Data\ZineNet\ZineNet.DataProtection.cos_tam\1.0.1.0\user.config. Zaglądamy do środka i tu rozczarowujący widok. Hasło przechowywane jest w czystej postaci, jak go użytkownik stworzył.

Akt 2

Taki sposób to dość marne zabezpieczenie, więc postaramy się teraz to naprawić. Najpierw zmieniamy typ zapamiętywanego hasła z System.String na System.Byte[] (i najlepiej nazwę wpisu ustawień użytkownika na wypadek kolizji i problemów z wersjonowaniem naszej aplikacji). W kolejnym kroku zamiast zapisywać hasło w czystej postaci jak poniżej:

if (_rememberPassword) { Properties.Settings.Default.Logon_Password = password; Properties.Settings.Default.Save(); }

Zapiszemy ją jako zaszyfrowany ciąg bajtów. Szyfrowanie możemy uzyskać za pomocą metody "ProtectedData.Protect(...)". Klasa ProtectedData ta faktycznie opakowuje funkcje systemowe DPAPI: CryptProtectData i CryptUnprotectData. Metoda Protect przyjmuje 3 parametry i zwraca ciąg bajtów, którym jest zaszyfrowany ciąg bajtów wejściowych.

Pierwszym parametrem jest "userData". Jest to ciąg bajtów dowolnej długości, który należy zaszyfrować.

Drugim parametrem jest "optionalEntropy". Jest to kolejny ciąg bajtów (może być innego rozmiaru niż userData) który zawiera losowe wartości wzmacniające szyfrowane dane. Idea jest taka sama jak z szyfrowaniem haseł i tak zwanym "ziarnem" (http://en.wikipedia.org/wiki/Salt_(cryptography)).

Trzeci parametr "scope" definiuje na jakim poziomie dane powinny być zabezpieczone. Możemy wybrać opcję szyfrowania w ramach konta użytkownika (wtedy tylko w kontekście tego samego użytkownika będzie można te dane odszyfrować) lub w ramach całej maszyny.

Poziom szyfrowania "maszyna" może być użyteczny na przykład to przechowywania haseł do serwera bazy danych, jeśli ten sam serwer jest używany przez wielu użytkowników z tej samej maszyny. Po prostu zaszyfrowane dane będzie mógł odszyfrować każdy, kto zaloguje się poprawnie do komputera.

W naszym przypadku pomijam opcjonalna wartość entropii i ustawiam poziom "użytkownika". Dzięki temu na tej samej maszynie różne osoby (konta) będą mogły używać naszej aplikacji nie przeszkadzając sobie.

Drugim krokiem jest zmiana uzyskiwania hasła już zapisanego dla kolejnych uruchomień aplikacji. Zamiast prostego:

_password = Properties.Settings.Default.Logon_Password ?? "";

Musimy użyć metody "ProtectedData.Unprotect(...)" w następujący sposób:

var encPassword = Properties.Settings.Default.Logon_PasswordEnc; if (encPassword != null) { _password = Encoding.Unicode.GetString(ProtectedData.Unprotect(encPassword, null, DataProtectionScope.CurrentUser)); } else { _password = ""; }

Metoda Unprotect przyjmuje 3 parametry jak metoda Protect, z tym wyjątkiem że pierwszy parametr jest zaszyfrowanym ciągiem bajtów uzyskanym z wcześniejszego użycia metody Protect. Jeśli używamy opcjonalnej entropii, to musimy jako drugi parametr przekazać tą samą wartość której użyliśmy przy metodzie Protect. Poniższy pseudo kod ilustruje wymaganą zależność:

var data = ...
var entropy = ...
var scope = ...

var enc = Protect(data, entropy, scope
var data2 = Unprotect(enc, entropy, scope)

assert(data == data2)

Zaglądamy ponownie do pliku user.config tym razem w katalogu Local Settings\Application Data\ZineNet\ZineNet.DataProtection.cos_tam\1.0.2.0\user.config i widzimy tym razem coś o wiele porządniejszego:

<configuration>
...
<userSettings>
    <ZineNet.DataProtection.Act2.Properties.Settings>
      <setting name="Logon_PasswordEnc" serializeAs="Xml">
        <value>
          <base64Binary>AQAAANCMnd8BFdERjHoAwE...</base64Binary>
        </value>
      </setting>
    </ZineNet.DataProtection.Act2.Properties.Settings>
</userSettings>
</configuration>

Gotową aplikację, a dokładniej jej projekt można znaleźć w załączonych plikach do artykułu pod nazwą ZineNet.DataProtection.Act2

ProtectedMemory

Podobne działanie jak ProtectedData mają metody klasy ProtectedMemory. Są trzy zasadnicze różnice.

Pierwszą jest to że metody ProtectedMemory opakowują metody DPAPI CryptProtectMemory i CryptUnprotectMemory i jako takie nie przyjmują już opcjonalnej wartości entropii.

Drugą różnicą jest inny typ enumeracji dla parametru scope. Możemy wybrać opcję szyfrowania wewnątrz procesową, między procesową oraz w ramach kontekstu użytkownika.

Trzecią różnicą jest to, że możemy szyfrować i deszyfrować w ramach jednego uruchomienia maszyny. Restart komputera wymazuje informacje o tym jak zdeszyfrować poprzednio szyfrowane dane. Typowym zastosowaniem jest szyfrowanie tych danych, które są ścisłe sesyjne, czy muszą istnieć tylko podczas działania aplikacji i nie są nigdzie zapisywane.

Zagadka 1 - Jak to jest możliwe?

2008-09-08T10:05:00Z

Przegladajac poranna dawke postow na blogach (nieodlaczny Google Reader), natknalem sie na ciekawy i zaskakujacy fragmetn kodu. Zaczalem doglebniej przegladac siec i swoje zasoby dyskowe i moje zaskoczenie roslo jeszcze bardziej. Dosc gadaniny zapraszam do rozwiazania zagadki (raczej nie przewiduje nagrod). Niestety ta zagadka ma jeden feler (ktory sam nie znosze) - dobra odpowiedzia jest ta ktora mam na mysli. Czyli jest to raczej proba zainteresowania ciekawym zjawiskiem jezyke C# niz prawdziwa zagadka.

Ponizej jest fragment kody C#. Z pewnego typu wycialem kod konstruktora i pola. Pytanie: Jak to jest mozliwe?

public static readonly Aaa Empty; public Aaa(int x, int y) { this = Empty; }

"Jak" znaczy wskazac odpowiedni fragment specyfikacji języka C#.

EDIT: Poprawna odpowiedz dal "apl". Gratulacje!

public struct MyStruct { public static readonly MyStruct Empty; private int _x; public MyStruct(bool notUsed) { this = Empty; } }

Warto w tym momencie przytoczyc fragment dokumentacji C# 3 dotyczacy slowa kluczowego this w kontekscie klasy i struktury:

Klasa:

"When this is used in a primary-expression within an instance constructor of a class , it is classified as a value. The type of the value is the instance type (§10.3.1) of the class within which the usage occurs, and the value is a reference to the object being constructed."

Struktura:

"When this is used in a primary-expression within an instance constructor of a struct, it is classified as a variable. The type of the variable is the instance type (§10.3.1) of the struct within which the usage occurs, and the variable represents the struct being constructed. The this variable of an instance constructor of a struct behaves exactly the same as an out parameter of the struct type—in particular, this means that the variable must be definitely assigned in every execution path of the instance constructor."

Z pierwszego zdania w obu tekstach widac ze sa traktowane inaczej w klasie i strukturze. Dodatkowo z tego co z rozumialme z reszty wyjasnienia dla struktury, to "value" nalezy traktowac jak parameter out (nalezy zainicjalizowac out-parametr przed opuszczeniem metody), czyli cos w rodzaju:

public struct MyStruct { public MyStruct(out MyStruct this) { ... } }

Lecz porownujac prawdziwy parametr "out" i ten pseudo, wychodza na jaw znaczace roznice:

public struct MyStruct { private int _x; public MyStruct(/* out int this, */ int x) { this._x = x; } } public class MyClass { private int _x; public void MyClassMethod(out MyClass @this, int x) { @this._x = x; } }

W drugim przypadku dostaniemy blad kompilacji "error CS0269: Use of unassigned out parameter 'this'" dla linii "@this._x = x;".

Podgladajac kod IL wygenerowany dla roznych przypadkow, dochodze do wniosku, ze konstrukcja "this =" sluzy poprostu za inicjalizator struktury zap omoca wartosci po prawej stronie znaku rownosci konstrukcji "this =". Inicjalizator w sensie "memcpy" - czyli tak jak dziala przypisanie struktur jezyka C# - kopiujac wartosca nie przypisujac referencje.

Podsumowujac, przegladajac blogi i czytajac kod (w tym przypadku MEF Preview 2), czasami mozna czegos nowego sie nauczyc ( a dokumentacje C# poprawic ;-) ).

BTW: Wyglada jak by w .NET 4, proste pojemniki na dane (takie jak opisywalem w jednym z tekstow) beda dostepne "z pudelka"!

[Ww.Misc] Resharper 4.1 i dalej

2008-08-29T10:18:00Z

Zapewne dzis (2008-08-29) lub najdalej w poniedzialek wyjdzie wersja 4.1 (4.0.1) swietnego narzedzia Resharper. Nie jest to oficjalna wiadomosc, jako ze nie ma tego do sciagniecia czy na oficjalnych blogach, lecz bugi dla wersji 4.1 zostaly oznaczone jako "Release Date: 29 Aug 08" (http://www.jetbrains.net/jira/browse/RSRP/fixforversion/11620), od dluzszego casu coraz rzadziej sa publikowne nowe buildy no i mozna zauwazyc ze 4.5 pojawilo sie w ichniej "bugzilli". Ponizej pare luznych uawg, mysli na temat R#.

Narzedzie

Ogolnie jest to najlepsze narzedzie wspierajace VS z jakim moglem pracowac. Naprawde w codzeinnej pracy pomaga mi znacznie. Do mniej "slodkich" uwag dodalbym wysokie wymagania pamieciowe i sporo trzeba poswiecic na konfiguracje aby uzywanie R# bylo intuicyjne (co nie znaczy nie mozliwe). Cos za cos - ja nadal uwazam ze wady sa calkowiecie zrekompensowane przez zalety tego narzedzia

Support

Tu, juz nie jest tak rozowo. Jedynym widocznym plusem jest automatyczne raportowanie bledow po wystapienu. W czasach wersji 1.x czy 2 druzyna R# byla bardziej sklonna uznawac zgloszone uwagi/problemy jako bugi. Niestety podzcas ostatnich wersji, pod uwage brane sa uwagi krytyczne (wykladanie VS, czy blokowanie VS), pozostale zazwyczaj koncza w szufladce "w nastepnej wersji" albo "won't fix".

Release

Wersja 4.x produkowana byla naprawde dlugo! Prezkroczono obiecywane terminy 2-3 krotnie. Instalowalem "Nightly Builds" w miare regularnie (pewnie tak >80% opublikowanych buildow zainstalowalem) i w miare regularnie przegladalem stan "buzgilli" tego projektu. Zauwazylem jedna ciekawa rzecz. A mianowicie przed opublikowaniem wersji 4.0 mieli kilka(nascie) blockerow i kilkadzeisiat criticali (chyba bylo kolo 80 albo odrobine ponad 100 - dokladnie nie pamietam), lecz mimo to produkt wypuscili! Zapewne niezadoloenie w "comunity" z niewypuszczanie RTM mialo swoj udzial w szybkiej publikacji, lecz chyba troche zbyt pochopnie. Zadziwiajaca rzecz stala sie pare dni po publikacji - bugi zostaly przerzucone do wersji 4.0.1 (chyba to sie nazywalo jeszcze wersja 4.0.1, bo ostatnio ma to nazwe 4.1). Wywnioskowac z tego mozna ze wersja 4.0 byla uznana arbitralnie (aby zatkac usta niezadolonym) a prace trwaly nadal.

Zadziwiajaca sytuacje obserwuje ponownie. Pojawi sie wersja 4.1 i juz bugi sa przerzucane do 4.5 lub dalej. W tej chwili zdecydowana wiekszosc bugow przerzucili do 4.5. Chyba maja skrypt jakis w stylu "Dodaj nowa wersje i przerzuc wszystkie zgnilki.cmd" ;-)

Szczotka + Zmiotka

Nie podoba mi sie sytuacje, gdzie w wersji X zgloszony jest problem (nie jeden i nie dwa!) klasyfikowany jako powazny i nic sie z nim nie dzieje przez kolejnych kilka wersji. Sukcesywnie jest przerzucany z wersji do wersji. Uwazam ze powinni sie zdecydowac na "won't fix" (bo taka maja wizje produktu), badz rozwiazac go bez nieskonczonego przesuwania. A'propo takiego zwodzenia, przypomina mi sie sytuacja gdzie kupilem licencje na ktoras wersji, powodowany tym ze rozwiazany zostanie pewien powazny dla mnie problem. mial byc rozwiazany tuz po pierwszym oficjalnym release i nawet tak byl oznaczony w "bugzilli". Niestaty pomimo tego oznaczenia i zapewnien ze strony "kogos w supporcie", to sie nie stalo. Krotko mowiac zostalem oszukany. Jakos mam wrazenie ze podobnie dzieje sie teraz z tym przesuwaniem bugow z wersji na wersje...

Wersja 4.5

Pomimo tych wszelkich "dziwactw" teamu R#, ciekaw jestem jakie nowosci zaproponuja w nowej, ulamkowej wersji. Trudno cos zgadywac, jako ze aktualnie jest dosc pelnym produktem. Moze ktos z Was ma jakis pomys/przepowiednie?

...

Pomimo ze nie podoba mi sie sposob dzialania Supportu R#, na pewno nastepna wersje bede uzywal, lecz przy kolejnym uaktualnieniu dobrze sie zastanowie. Kto wie, moze jakies nowe narzedzie sie pojawi...

[Ww.Note] Male przyspieszacze czasu

2008-08-22T11:14:00Z

Chcialbym sie podzielic malymi fragmentami kodu, bedacymi przspieszaczami czasu. Podobny tekst opublikowal Maciej Aniserowicz. Przykłady dotycza generowania obiektow string z roznego rodzaju powtorzeniami oraz prawie powtorzeniami.

1. Wygenerowanie tekstu ze zbioru napisow poprzedzielanych jakims delimiterem.

{ var arr = new[] { "ala", "ma", "kota" }; var s = String.Join(" ", arr); // s == "ala ma kota" } { var arr = new[] { "'a'", "'b'", "'c'" }; var s = "Foo(" + String.Join(", ", arr) + ")"; // s == "Foo('a', 'b', 'c')" } { var arr = new[] { "arg1", "arg2", "arg3" }; var s = "Foo(" + String.Join(", ", arr) + ")"; // s == "Foo(arg1, arg2, arg3)" }

Metoda String.Join spelnia znakomicie swoja role.

2. Wygenerowanie tekstu gdzie mamy sekwencje takich samych wartosci, poprzedzielanych jakims inneym tekstem (przecinek, tabulator, nowa linia)

var s = String.Join("; ", Enumerable.Repeat(DateTime.Today.ToString("yyyy-MM-dd"), 5).ToArray()); // s == "2008-08-22; 2008-08-22; 2008-08-22; 2008-08-22; 2008-08-22"

Ponownie metoda String.Join, lecz tym razem tablice generujemy pomocnicza konstrukcja Enumerable.Repeat

3. Wygenerowanie tekstu gdzie mamy sekwencje wartosci, poprzedzielanych jakims inneym tekstem

var s = "Foo(" + String.Join(", ", Enumerable.Range(1, 4).Select(i => "arg" + i).ToArray()) + ")"; // s == "Foo(arg1, arg2, arg3, arg4)"

Ponownie metoda String.Join, lecz tym razem tablice generujemy pomocnicza konstrukcja Enumerable.Range razem z Select.

W starych czasach (pewnie w okolicach zdobywania Berlina) stosowalem StringBuildera i flagi LUB generowalem tablice za pomoca for i uzywalem String.Join. Oczywiscie nie zawsze takie konstrukcje sie nadaja, zwlaszcza ze w niektorych przypadkach performance (CPU, memory) moze cierpiec. Ale jesli uzywamy tego z umiarem czy w szablonach T4 (stad wzial sie pomysl na ten tekst), to jest wedlug mnie jak najbardziej na miejscu.

[Ww.VS] Szablony tekstowe w VS2008

2008-07-21T19:43:00Z

Od chwili pojawienia się DSL Tools dla Visual Studio, dostępne były szablony tekstowe T4. Pisał o nich Arek w drugim Zine. Wraz z Visual Studio 2008, bez instalowania SDK czy DSL Tools, szablony T4 są dostepne "z pudełka". Zreszta ostatni wpis na blogu Arka (ten w ktorym używa takich skomplikowanych zwrotów jak refaktoryzacja czy metoda zwrotna kojarząca mi się z kolejami).

Jak najszybciej użyć T4?

Poprostu należy dodać plik o rozszerzeniu tt do projektu i VS2008 automatycznie podłączy CustomTool "TextTemplatingFileGenerator" i wygeneruje podłączony plik cs.

Wystarczy teraz w pliku napisać cos takiego:

namespace MyApp { class Class1 { <# foreach (string name in new string[] { "Aaa", "Bbb", "Ccc" }) { #> string <#= name #> { get; set; } <# } #> } }

Aby otrzymać taki wynik:

namespace MyApp { class Class1 { string Aaa { get; set; } string Bbb { get; set; } string Ccc { get; set; } } }

Parę uwag przy dodawaniu szablonów T4

Za pierwszym razem możemy dostać ostrzerzenie "Security Warning" informujące o niebezpieczeństwie zniszczenia komputera pewnie razem z księżycem. Najlepiej potwierdzić za pomocą OK, zaznaczając wczesniej CheckBox "Do not show this message again".
Plik tekstowy bez dyrektyw szablonu (znaczników na początku pliku <#@ i #>) czy znaczników renderowania, również jest poprawnym szablonem, który generuje tekst identyczny z zawartościa szablonu
Wygodnie jest dodac nowy szablon za pomocą opcji "Add>New Item...", wybrać dowolny tekstowy plik jak Class czy Code File zmieniając rozszerzenie pliku na ".tt" zamiast ".cs"
Standardowo plik generowany pod szablonem ma rozszerzenie ".cs" (to w przypadku projektów C#, zapewne w przypadku projektów VB będzie to ".vb" - nie sprawdzałem). Wiąże się to również z tym że zachowanie pliku w projekcie będzie takie jak typowego pliku o tym rozszerzeniu - w przypadku plików ".cs" "Build Action" będzie ustawiony na "Compile".
Jesli wybierzemy inny plik (na przykład XML File), to standardowo dostaniemy wygenerowany plik ".cs". Generowane rozszerzenie można zmienić dodając dyrektywę output na przykład tak: <#@ output extension="xml" #> - koniecznie na początku pliku!
Jesli plik szablonu o rozszerzeniu ".tt" skopiowany do schowka (na przykład z pulpitu, czy Exploratora Windows) wkleimy do projektu, to również poprawnie zarejestruje nam sie szablon.
Jesli istniejącemu plikowi (na przykład ".cs") zmienimy rozszerzenie na ".tt", to znowu otrzymamy działający plik szablonu. Jedyna niedogodnościa może być to że wygenerowany plik pod szablonem będzie miał w nazwie suffix "1" (lub inna cyfrę). Można tego uniknąć stosując inną metodę, lub ręcznie edytując plik projektu ".csproj" (Unload Project a potem Edit) i usuwając element "LastGenOutput" z elementu odpowiadającego szablonowi. Po ponownym załadowaniu należy usunąć poprzednio wgenerowany plik i wymusić generację ponownie (opcja Run Custom Tool).

Mały bonus

W archiwum ZIP, znajdują się 4 pliki szablonów. Wystarczy je rozpakować, skopiować i wkleić do projektu, aby otrzymać parę klas "utilsowych".

Guard i GuardDebug - to klasy podobne do Assert, lecz posiadające API bazujące na xUnit.

Entries - to zbiór prostych klas-pojemników, do zastosowań wewnątrz implementacyjnych (nie zalecane "wystawianie" tych typów w publicznym API).

Przykładowe użycie:

Guard.NotNull(param1, "Param1 cannot be null."); GuardDebug.NotNullOrEmpty(name, "Entity name cannot be empty."); var e = new Entry<int, int, int>(1, 2, 3); Guard.InRange(e.Value2, e.Value1, e.Value3, "Entry constraint not satisfied."); var map = new Dictionary<string, Entry<string, int, int>>();

Jeśli macie jakieś uwagi zapraszam do komentowania lub kontaktu mailowego.

Oczywiscie standardowy disclaimer ze nei odpowiadam za problemy, wybuchy etc.

[Ww.Text] CustomConfig2 - czyli jak zrobic aby sie nie narobic

2008-06-12T08:56:00Z

Wczoraj przeczytaLem post Darka omawiający hierarchiczne pliki konfiguracyjne. Podczas czytania naszły mnie 3 mysli.

Kropkowana notacja przypomina mi Javowe properties (czy to jescze tak sie nazywa?). Mialem z tym doczynnienia daawno temu jak jeszcze cos robilem przy Java. Srednio mi sie to posdobalo i do dzis uwazam ze reprezentacja hierarchii wartosci za pomoca notacji kropkowej a nie skorzystanie z gotowego, znanego, popularnego, sprawdzonego rozwiazania nie jest najszczesliwszym rozwiazaniem (do typowych zastosowan, jako ze na pewno znajda sie zastosowanie gdzie take java-ini-like rozwiazanie sprawdzi sie duzo lepiej niz XML).
Po moich ostatnich "zawodowych" walkach z przetwarzaniem plikow tekstowych i problemami stron kodowych, unicode, kompatybilnosci wstecz i wprzod (na szczescie bez kompatybilnosci gora-dol czy prawo-lewo ;-) ) ustawiem regionalnych, jezyka systemu i non-win systemow - cisnienie mi skoczylo na mysl o sledzeniu problemow i ich rozwiazywaniu. Po pierwszym tekscie nie widac na razie jak tego typu problemy moga byc rozwiazane. Prawdopodobnie dlatego ze Darek nie wymaga podobnej funkcjonalnosci od tego rozwiazania i jemu to wystarcza to jest calkowicie w porzadku.
Pozazdroscilem checi pisania, testowania, dokumentowania, wdrazania tego rozwiazania w zespole, jakoze jestem leniwa osoba. Z tego tez powodu powstal ten blog, poniewaz postanowilem zrobic podobna funkcjonalnosc korzystajac z wbudowanej funkcjonalnosci w .NET Frameworka.

Configuration w .NET Frameworku wspiera chyba od poczatku hierarchiczne pliki konfiguracyjne. Przeciez po instalacji mamy machine.config i "app.config". Ten drugi moze zmienic "odziedziczone" wlasnosci z machine.config lub dodac nowe a nawet usunac - oczywiscie wszystko "lokalnie" w ramach aplikacji. Wiec wykorzystajmy ta infrastrukture do "naszych" celow - czyli rozwiazania ktore posiada glowny plik konfiguracyjny oraz opcjonalne per user nadpisane ustawienia.

Nie stadardowy plik konfiguracyjny

Najpierw pokaze jak zaladowac konfiguracje z prawie dowolnego pliku. korzystajac z metody ConfigurationManager.OpenExeConfiguration(string exePath) mozemy zaladowac plik konfiguracyjny dla wskazanego pliku "exe" (a tak naprawde dowolnego pliku) gdzie plik konfiguracyjny to exePath z dodanym sufiksem ".config".

const string cfg = @"<?xml version='1.0' encoding='utf-8' ?> <configuration> <configSections> <section name='mySection' type='ZineNet.CustomCfg2.MySection, ZineNet.CustomCfg2'/> </configSections> <mySection> <myProperties> <add name='p1' value='v1' /> <add name='p2' value='v2' /> <add name='p4' value='v4' /> </myProperties> </mySection> </configuration>"; File.WriteAllText(@"CfgDir\Demo1.tmp", ""); File.WriteAllText(@"CfgDir\Demo1.tmp.config", cfg, Encoding.UTF8); var exeCfg = ConfigurationManager.OpenExeConfiguration(Path.GetFullPath(@"CfgDir\Demo1.tmp")); var myCfg = (MySection)exeCfg.GetSection("mySection"); foreach (MyPropertyElement p in myCfg.MyProperties) { Console.WriteLine("{0}:{1}", p.Name, p.Value); }

W tym przykladzie tworze plik na dysku, gdze zapisuje przykladowa konfiguracje. Nastepnie otwieram plik konfiguracyjny wskazujac na tymczasowy/sztuczny plik CfgDir\Demo1.tmp. Metoda OpenExeConfiguration sprawdza istnienie pliku przekazanego w argumencie exePath, pomimo iz z niech nie korzysta. Dlatego wytwarzam rowniez pusty plik o takiej nazwie.

Dowolne hierarchiczne pliki konfiguracyjne

Teraz przyklad blizszy temu co zaprezentowal Darek w swoim tekscie. Utworze 2 pliki konfiguracyjne, zaladuje oba uzyskujac ten sam typ sekcji konfiguracyjnej jak w przykladzie pierwszym.

const string cfg = @"<?xml version='1.0' encoding='utf-8' ?> <configuration> <configSections> <section name='mySection' type='ZineNet.CustomCfg2.MySection, ZineNet.CustomCfg2' allowExeDefinition='MachineToRoamingUser'/> </configSections> <mySection> <myProperties> <add name='p1' value='v1' /> <add name='p2' value='v2' /> <add name='p4' value='v4' /> </myProperties> </mySection> </configuration>"; const string cfgLocal = @"<?xml version='1.0' encoding='utf-8' ?> <configuration> <mySection> <myProperties> <remove name='p2' /> <add name='p5' value='v5' /> </myProperties> </mySection> </configuration>"; File.WriteAllText(@"CfgDir\Demo2.config", cfg, Encoding.UTF8); File.WriteAllText(@"CfgDir\Demo2.Local.config", cfgLocal, Encoding.UTF8); var exeCfg = ConfigurationManager.OpenMappedExeConfiguration( new ExeConfigurationFileMap { ExeConfigFilename = Path.GetFullPath(@"CfgDir\Demo2.config"), RoamingUserConfigFilename = Path.GetFullPath(@"CfgDir\Demo2.Local.config") }, ConfigurationUserLevel.PerUserRoaming ); var myCfg = (MySection)exeCfg.GetSection("mySection"); foreach (MyPropertyElement p in myCfg.MyProperties) { Console.WriteLine("{0}:{1}", p.Name, p.Value); }

Tym razem uzywam innej metody OpenMappedExeConfiguration gdzie przekazuje obkekt ExeConfigurationFileMap. Obiekt file map zawiera sciezki do konkretnych plikow konfiguracyjnych a nie zaleznych plikow "exe". Za pomoca drugiego argumentu ConfigurationUserLevel specyfikujemy ktore pliki musza byc zaladowane, a ktore zignorowane, jako ze w typie ExeConfigurationFileMap mozeny wyspecyfikowac 4 pliki konfiguracyjne roznego poziomu. Musimy zezwolic na ta operacje przy definicji sekcji w "pierwszym" pliku konfiguracyjnym za pomoca atrybutu "allowExeDefinition".

Jeszcze wiecej funkcjonalnosci we wlasnych plikach

Powyzszy przyklad dostarcza z grubsza funkcjonalnosci zaprezentowanej przez Darka. Lecz mozemy skorzystac bez zmiany kodu przetwarzajacego, z pozostalej funkcjonalnosci. Dla przykladu pokaze mozliwosc blokowania redefiniowania fragmentow konfiguracji.

const string cfg = @"<?xml version='1.0' encoding='utf-8' ?> <configuration> <configSections> <section name='mySection' type='ZineNet.CustomCfg2.MySection, ZineNet.CustomCfg2' allowExeDefinition='MachineToRoamingUser'/> </configSections> <mySection> <myProperties> <add name='p1' value='v1' /> <add name='p2' value='v2' lockItem='true' /> <add name='p4' value='v4' /> </myProperties> </mySection> </configuration>"; const string cfgLocal = @"<?xml version='1.0' encoding='utf-8' ?> <configuration> <mySection> <myProperties> <remove name='p2' /> </myProperties> </mySection> </configuration>"; File.WriteAllText(@"CfgDir\Demo3.config", cfg, Encoding.UTF8); File.WriteAllText(@"CfgDir\Demo3.Local.config", cfgLocal, Encoding.UTF8); var exeCfg = ConfigurationManager.OpenMappedExeConfiguration( new ExeConfigurationFileMap { ExeConfigFilename = Path.GetFullPath(@"CfgDir\Demo3.config"), RoamingUserConfigFilename = Path.GetFullPath(@"CfgDir\Demo3.Local.config") }, ConfigurationUserLevel.PerUserRoaming ); var myCfg = (MySection)exeCfg.GetSection("mySection"); foreach (MyPropertyElement p in myCfg.MyProperties) { Console.WriteLine("{0}:{1}", p.Name, p.Value); }

Ustawiajac atrybut lockItem='true' na jednej z wlasnych wlasciwosci, nie pozwalamy na redefiniowanie go w "potomnym" pliku konfiguracyjnym. Podczas uruchamiania przykladu trzeciego dostaniemy wyjatek o podobnej tresci: "The attribute 'p2' has been locked in a higher level configuration. (K:\ZineNet\ZineNet.CustomCfg2\bin\Debug\CfgDir\Demo3.Local.config line 5)".

Inne uwagi

Zamiast hierarchii zagniezdzania elementow, mozna ja "rozplaszczyc" i zastosowac notacje kropkowa podobnie jak to uczynil Darek. Poprostu trzeba nadpisac w definicji sekcji sposob deserializacji/serializacji
Podejscie z zagniezdzaniem elementow XML zamiast notacji kropkowej wymusza na nas stworzenie odpowiednich klas konfiguracji. Zyskujemy na tym walidacje pliku konfiguracyjnegom lecz tracimy na tym ze mamy dodatkowa prace rzemieslnicza zwiazana z ich napisaniem.

[WG.net] Wzorzec Model View Controller (MVC)

2008-02-16T14:29:00Z

Prezentacja z XX spotkania grupy WG.net (XI PGU SqlSever) omawiająca wzorzec MVC.

Scenariusz problemu - Edycja danych

Jednym z najczęstszych przypadków tworzenia aplikacji jest umożliwienie użytkownikowi interakcji z danymi - formatkowy edytor danych. Zakres wymaganej funkcjonalności obejmuje bardzo często następujące wymagania:

Zapytanie do bazy - wszystkie / tylko wybrane
Przepisanie danych do kontrolek - problemy z DBNull, null, etc
Obsługa słowników
Obsługa akcji Edit/Add/Remove/BrowseDictionary
Sprawdzenie poprawności
INSERT/UPDATE/DELETE do bazy

Implementacja całości wymagań w jednym pliku asp/php/form etc powoduje nieczytelność kodu. Przeglądanie, a co ważniejsze koszt utrzymywania kodu rośnie coraz szybciej wraz ze wzrostem dodatkowej funkcjonalności.

Rozwiązanie - wzorzec MVC

Rozwiązaniem problemu jest zastosowanie wzorca Model View Controller (MVC). Polega to na podzieleniu wymaganej funkcjonalności/odpowiedzialności na 3 komponenty:

Model – przetwarzane dane
View – prezentacja danych
Controller – sterowanie przepływem danych – logika aplikacji

Dokładny podział odpowiedzialności jest zależny od konkretnego wariantu wzorca czy implementacji. Dla przykładu rozważmy odpowiedzialność "sprawdzenie poprawności danych". Można włączyć ją do modelu gdy nie jest ona trywialna, a powiązana ściśle z modelem. Walidację można włączyć do widoku, gdzie poszczególne kontrolki mogą ją wykonywać. W przypadku skomplikowanego sprawdzania odpowiedzialność może przejąć kontroler.

Warianty

Wzorzec MVC posiada wiele wariantów, dostosowywanych do konkretnych technologii, metodyk programowania czy właściwości języka. Zanim zacznie się tworzenie własnej implementacji, warto przejrzeć najpopularniejsze Frameworki MVC przeznaczone dla swojej platformy programistycznej. Zazwyczaj takie gotowce zawierają dodatkową funkcjonalność jak pojemniki IoC, definiowanie przepływem logiki aplikacji, ułatwienia typowych operacji programisty, etc.

[Prezentacja 20080214_XX_WG_WzorzecMVC.zip] oraz [Ww.WgNet.MvcCalc.zip]

[Ww.Web] SilverLight, SilverDark, Konkrety

2008-01-24T13:30:00Z

Poniżej parę konkretnych uwag do SilverLighta (SL), aby poprzednie narzekanie na SL nie było gołosłowne. Nie są to wszystkie moje uwago do SL, ale wydaje mi się wystarczająca ilość aby uzasadnić mój punkt widzenia z poprzedniego postu.

1. Środowiska programisty/projektanta/tego-co-robi-SL-aplikację

Spróbowałem pracować z Blendem oraz VS 2008. Niestety, kontrolki z Toolkita nie pokazują się w designerze i w dodatku z jakiegoś magicznego powodu po uruchomieniu wyglądają dziwnie (niektóre elementy są powyciągane, a niektóre mają dobre rozmiary). Zrezygnowałem z Blenda i zacząłem używać VS2008. Ręczna praca z XAMLem oraz kodem "pode spodem" przyniosła efekty - na statycznych plikach z tekstem do wyświetlenia działało dobrze! Niestety próba udynamicznienia aplikacji spowodowała stratę około 2 godzin (jeden wieczór zmarnowany), ponieważ w wersji 1.1 Downloader uruchomiony lokalnie (nie przez serwer Web) nie pozwala "ściągnąć" plików leżących po sąsiedzku ze strona HTML aplikacji SL. Błąd wyświetlany jest baaardzo ogólny i nie wiadomo czy przypadkiem to początkujący SLowiec nie popełnił błędu. Informację o tym znalazłem na forum dyskusyjnym.

2. Debugowanie aplikacji

Chciałem mieć 3 projekty: w pierwszym logika konwersji, w drugim kontrolki związane z SL, a w trzecim prosta aplikacja w ASP.NET zajmująca się publikowaniem Package pod wirtualnymi adresami URL. Tak naprawdę projekt SL i ASP.NET powinny być razem, jako że występują w tym samym Web Site. Niestety nie udało mi się dodać projektu z kontrolkami Toolkita do aplikacji ASP.NET. Wyjściem okazało się dołączenie projektu Toolkita do projektu SL, ręczne włożenie projektu SL do katalogu z projektem ASP.NET i zmiany w pliku solution. Aby debugować jednocześnie ASP.NET i SL należy ustawić oba projekty jako startowe. Dostajemy przy starcie 2 przeglądarki - jedna od ASP.NET (localhost), a druga do SL (local file system) i musimy ręcznie przeklejać i koordynować obie przeglądarki.

3. Uboga podstawowa funkcjonalność

Jak pisałem w poprzednim poście, są tylko naprawdę podstawowe kontrolki. API SL pod .NET jest bardzo zubożone - brak przeładowań metod dla typowych operacji, wygląda jak jakiś wrapper na coś z zupełnie innej bajki. Taka klasa Downloader - koszmarne API, wszystko "lata" jako tekst. XamlReader - tylko metoda Load z parametrem string reprezentującym tekst do sparsowania - nie można przekazać strumienia danych. XamlReader zachowuje się dodatkowo nie przewidywalnie - ten sam tekst przekazany do metody Load czasami przetwarza się poprawnie a czasami zgłasza błąd (Wygląda jak by po przetworzeniu określonej ilości znaków? elementów? zgłaszał błąd - problem z wewnętrznym buforem?).

4. Brak kontrolki TextBox

To tak ważna kontrolka, że brak jej jest jakimś nieporozumieniem lub pomyłką. Resztę na ten temat pominę milczeniem.

5. Brak funkcjonalności layoutowania kontrolek

Pozycjonowanie absolutne, a layoutowanie ręczne w kodzie. W przypadku zegarka to może i zda egzamin jak ma się kilka elementów bez interakcji użytkownika. Ale zastanówcie się ile trzeba spędzić czasu aby zrobic Grida ze stylami, szablonami? Dyskwalifikacja produktu.

6. Brak bindowania danych

Ręczne "wpisywanie danych" w kontrolkę (TextBlock/Glyphs). Takie "tricki" można było robić już w HTMLu i PHP/ASP. Po co do tego wracać? Dyskwalifikacja produktu.

7. Możliwości SL, a WPF

Gdzieś wyczytałem (jak zwykle nie pamiętam gdzie), że SL daje programiście duże możliwości, ponieważ jeśli ktoś chce to może zaimplementować na nim funkcjonalność WPF, a z tego wniosek, że to jest technologia porównywalna z WPF. Zgodzę się że technicznie jest możliwe przenieść sporą część funkcjonalności (nie napisze całość jako że nie znam tak dokładnie WPF), ale jakim kosztem czasowym?

Czasy gdy kilka lat temu walczyło się z materią, pisząc w HTML/JavaScript elementy z "dużych, okienkowych aplikacji" dla mnie przynajmniej już minęły. Nie cieszy mnie już sama możliwość zrobienia Czegoś bez względu na koszt czasowy. Odnosząc to do praktycznego zastosowania, jak widzę sposoby pracy i efekty SL:

a. SL jest przeznaczony dla aplikacji bazujących na HTML i przeglądarce. Aktualnie jest sens użycia tego jeśli klient zażyczył sobie JAWNIE aplikacji "webowej" z wodotryskami. Tak naprawdę jeśli klient chce intranetową, "bogatą" (bogatą w sensie UX/UI) aplikację są inne technologie zapewniające to, bez potrzeby debugowania JavaScript i udawania ze HTML jest prawie jak aplikacja okienkowa. Nie będę rozpisywał się o tym "prawie".

b. Jeśli już trzeba użyć HTML, to wtedy SL można użyć do prostych rzeczy, jak "flashowe" menu, ładne wykresy z odrobiną interakcji.

c. SL używamy do rzeczy prostych, ponieważ napisanie złożonej aplikacji (nawet formatowy edytor danych) wymaga naprawdę duuużo roboczo-godzin lub zasobów pieniężnych (na jedno wychodzi) . A to ze względu na potrzebę napisania tych kontrolek od początku, bądź kupna od jakiejś firmy. Z pobieżnego przeglądu dostępnych kontrolek jeszcze im daleko z funkcjonalnością choćby do podstawowych kontrolek WPFa.

[Ww.Web] SilverDark

2008-01-24T12:29:00Z

Postanowiłem wziąć udział w konkursie Silverlighta (SL). Długo szukałem tematu. Po akademicku zacząłem w ostatniej chwili (czytaj: 2 dni temu). Poległem.

Czas pre-SL

WPFem zainteresowałem się gdzieś w początkach jego powstawania. Czekałem z zapoznaniem się z WPF tak naprawdę do czasu którejś z wersji Beta. Ciężka to była nauka, porównywalna chyba do nauki Flash 4. Do chwili obecnej napisałem 2-3 aplikacje, które są większe niż HelloWorld. Zderzyłem się z paroma problemami, zmieniłem sposób myślenia/oczekiwania co do pewnych komponentów WPF. Aktualnie uznaję WPF za dobrą alternatywę dla WinForms - może nie dla każdego zastosowania, lecz dla zdecydowanej ich większości. Potem pojawiły się informacje o WPF/E. Z nazwy oczekiwałem, iż będzie to taki WPF, ale na inne platformy.

"Lights, Camera, Action!"

Z oglądania kodu SL na blogach i w przykładach, wszystko wygląda fajnie, prosto i ładnie. Przykładowe aplikacje pokazują co można z tym zrobić. Myślałem, że zbieżność WPFa i SL będzie duża (w końcu pierwsza nazwa to WPF/E), i że za pomocą części wspólnej można tworzyć aplikacje WPF dobrze przenaszalne do SL. Och! Jaki ja bylem naiwny.

"Shileds up, weapons online"

Pojawia sie konkurs SL. Jest powód aby zapoznać się technologią. Najpierw wybór jaką aplikacje napiszę. Powstało wiele pomysłów: przeglądarka dokumentów (konwersja z DOCX,HTML,CHM,ect ->FlowDocument->XPS), dashboard z kilkoma elementami, smart tagi do HTMLa, itp. Zdecydowanym się w końcu na pierwszy pomysł - XPS reader. Pierwsze testy wykazały ze wystarczy z FixedPage wyrzucić kilka atrybutów i elementów i pozostanie część kompatybilna z XAMLem SL (okazało się że podobne podejście zastosował niejaki Delay). Potem zaczęły się kłopoty... Na przykład: jednym z ostatnich problemów jest niepoprawne parsowanie tekstu XAML. To znaczy ten sam tekst raz jest dobrze parsowany, a następnym razem zgłaszany jest wyjątek XamlParseException - co do znaku, co do bajtu ten sam tekst raz jest przetwarzany a raz nie.

Nastały mroczne czasy

Z końcu zrezygnowałem z udziału w konkursie. Na samą myśl o SL w tej chwili przychodzą mi na myśl w większości niecenzuralne określenia. Gdzieś, ktoś, kiedyś napisał ze SL to jeden ze sposobów na tworzenie aplikacji RIA - niestety według mnie w obecnym stanie wytworzenie nie trywialnej aplikacji wymaga samozaparcia i dużej ilości czasu.

Troche marudzenia

Dla osób które "programowały w HTMLu" budując za pomocą HTML/JavaScript niestandardowe elementy UI, spojrzenie na SL może wydawać się ożywczym zbawieniem! Większa szybkość, możliwości czy ujednolicenie API (żadnych CrossBrowser trików!) przyciąga. Ale na tym poziomie podobną funkcjonalność oferuje Flash (chyba? Niestety przestałem interesować się tą technologią gdzieś w okolicach wersji 6 lub 7). Zaletą SL wobec Flash jest prawdopodobnie brak naleciałości z poprzednich wersji jako ze jest to pierwsza wersja.

Z drugiej strony dla osoby która poznała najpierw WPF, a teraz próbuje użyć SL to coś z pogranicza koszmaru i komedii. Koszmarem jest samo programowanie, szukanie dokumentacji, debugowanie aplikacji i dochodzenie, czy problem leży po stronie programisty czy błędu w SL. Komedią jest literka R ze skrótu (RIA) - w wersji "z pudełka" mamy dostęp do 5 głównych kontrolek/elementów: Canvas, Image, TextBlock, Glyphs i Shape (wraz z pochodnymi). W Toolkicie są dodatkowe kontrolki, które niestety się "rozjeżdżają", mają nieintuicyjne API, ale przynajmniej są. Zgadam się, że do zrobienia sprawnie "aplikacji" zegarek, odtwarzacz filmików bądź "flashowe menu" w zupełności wystarczy. Aby zrobić cos bardziej użytecznego/zaawansowanego, trzeba włożyć w to dużo pracy.

Po tym pierwszym spotkaniu SL odkładam na półkę z rzeczami nie używanymi. Zresztą sam MS widzi potrzebę re ewaluacji tego produktu jako że 1.1 jest zawieszony i będzie kontynuowany jako 2.0 z poszerzonym zakresem funkcjonalności. Może wrócę do tego produktu, ale nie wcześniej niż udokumentowana, późna wersja Beta.