Tym razem post nieco innego typu. Chciał bym przedstawić świetne narzędzie dostępne dla VS 2008 oraz VS 2010 (niestety tylko w odpowiednich wersjach). Do VS 2008 trzeba doinstalować dodatek GDR R2 (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=bb3ad767-5f69-4db9-b1c9-8f55759846ed&displaylang=en)

Każdy, kto współpracuje z wieloma osobami nad projektem, który korzysta z obszernej, często zmieniającej się bazy danych, staną nie raz przed problemem scalania zmian. Często różne osoby tworzą swoje kopie takiej bazy, tworzą nową funkcjonalność nanosząc zmiany i.... mają problem jak to potem połączyć.

Na ratunek przychodzi Schema Comparer

Umożliwia on porównanie 2 wersji bazy danych. Co więcej, możliwe jest porównywanie również bazy danych stojącej na serwerze, ze schematem zapisanym w solucji i np. umieszczonym na jakimś serwerze kontroli wersji (np. TFS ;)).
Przykładowy wynik porównania:

Doszedłem do wniosku, że najwygodniej używa mi się formy nazewnictwa zgodnej z szablonem:
-3-4 literki poprzedzające typ komponentu
-nazwa ;)

Czyli przykładowo przycisk do zapisu nazwę:
btnSave
a kontrolkę typu TextBox na datę:
txtDate

Dlaczego tak jest mi najwygodniej? Ponieważ przy ogromnej ilości formatek/stron i komponentów na nich, często zapominam nazwy poszczególnych elementów. Zwykle jednak pamiętam ich typ. Dzięki temu szukając pola tekstowego wpisuję txt a podpowiadanie składni umożliwia mi bardzo szybkie odszukanie tego co jest mi potrzebne.

Nie stosuję tej metodyki do nazywania zwykłych zmiennych w stylu:
int iNumber
ponieważ często nie pamiętam typów zmiennych. Bardzo często najpierw wpisuję nazwę i dopiero wtedy patrzę jakiego zmienna jest typu. Do tego zmiennych posiadających zakres całej klasy mam zwykle mniej niż elementów interfejsu a ich typ bardzo często jest typem złożonym. Nie wydaje mi się, aby taki sposób ich nazywania pomógł mi w znaczący sposób, jak to ma miejsce w przypadku GUI. 

Ta rada przyda się każdemu kto nie jest doświadczonym programistą, jeżeli chodzi o systemy korzystające z serwerów baz danych.
Czego rzecz się tyczy? Dat. A konkretnie godzin, albo może nawet minut.
Wiele razy widziałem aplikacje, w których na przykład mieliśmy kod procedury składowanej pobierającej dane:
... @date DATETIME --parametr procedury ... SELECT * FROM Tabela WHERE DataWstawienia < @date ...

oraz przykładowo procedura wstawiająca dane:
... INSERT INTO Tabela(..., DataWstawienia) VALUES(..., GETDATE()) ...

Z pozoru wszystko jest ok prawda? Problem zaczyna się kiedy spełnione są dwa warunki:
1) zależy nam na dokładności
2) baza danych jest na innym serwerze niż nasza aplikacja

Gdzie problem?
Procedura pobierająca dane przyjmuje datę jako parametr, zaś wstawiająca pobiera ją funkcją GETDATE(). Co zaś się stanie, jeżeli oba komputery (serwer bazy danych i aplikacji) nie mają zsynchronizowanych zegarków? Klapa. Okaże się, że czasem niektóre dane będą błędnie wybierane z uwagi na różnice pomiędzy zegarami.

Postanowiłem założyć blog w celu spisywania własnych "dobrych praktyk" programistycznych. Zamierzam wypełnić go (hah dobrze by było WYPEŁNIĆ) krótkimi wpisami zawierającymi moje spostrzeżenia uzyskane na przestrzeni lat programowania. Czyli jak warto programować aby potem nie płakać. Ja czasem "płakałem" i dzięki temu nauczyłem się jak robić nie należy.

Obecnie pracuję jako programista. Miałem styczność z kodem wielu osób. Widziałem jak kod "produkowany" przez te osoby zmieniał się na przestrzeni zdobywanego doświadczenia. Być może ten blog komuś pomoże dowiedzieć się czegoś ciekawego. A być może nie :)....