Antywzorce projektowe

Niektórzy nie lubią uczyć się przez antyprzykłady. Mnie się wydaje jednak, że dobry antyprzykład jest lepszy niż stado wątpliwej jakości poprawnych przykładów. Dlatego też z ciekawością poczytałem dzisiaj o antywzorcach projektowych programowania na Wikipedii. Poniżej cytuję antywzorce które interesują mnie szczególnie czyli związane z projektowaniem i programowaniem.

Z większością z nich się spotkałem, przy czym zadziwia to że sformułowane antywzorce są tak powszechne! Czyżby w programowaniu czaiła się skończona liczba pułapek?

Chciałbym żeby pojawiły się osoby które by przetłumaczyły do końca ten wpis na język polski (podczas edycji artykułu są dostępne angielskie odpowiedniki):

• Zmiana funkcjonalności, Inwersja abstrakcji (ang. Abstraction inversion): Nie udostępnianie użytkownikom zaimplementowanej funkcjonalności której potrzebują, przez co muszą ją zaimplementować ponownie używając funkcji wyższego poziomu.
• Niejednoznaczny punkt odniesienia (ang. Ambiguous viewpoint): Obiektowe modele systemu są prezentowane bez wskazania do czego się odnoszą (bez określenia w jakim kontekście są ukazane).
• Błotna bryła (ang. Big ball of mud): Dotyczy systemu o trudnej do wyodrębnienia i zrozumienia strukturze. Modyfikowanie takiego systemu jest ryzykowne, gdyż nie sposób jest przewidzieć skutków zmian, kod przypomina spagetti.
• Blob: zobacz Wszechmocny obiekt
• Petrochemia (ang. Gas factory): Zbyt skomplikowany, uciążliwie drobiazgowy projekt systemu lub funkcjonalność.
• Wadliwe wejście (ang. Input kludge): Zachodzi gdy system nie radzi sobie z poprawnymi i niepoprawnymi danymi na wejściu, gdyż ich obsługa nie jest wyspecyfikowana i błędnie zaimplementowana. Często jest tak, że programista nie jest w stanie wykryć takiego błędu, natomiast użytkownik wykrywa go z łatwością przy pierwszym uruchomieniu.
• Interfejs gigant (ang. Interface bloat): Tworzenie rozbudowanych i ciężkich interfejsów (w sensie diagramu klas) tak, że stają się one ciężkie do implementacji.
• Magiczny przycisk (ang. Magic pushbutton): Implementowanie zbyt ubogiego interfejsu użytkownika, bez pozwolenia mu na większą ingerencję w działanie programu. Zachodzi najczęściej wtedy, gdy programista najpierw wyklikuje interfejs użytkownika, a później go oprogramowuje. Zazwyczaj kod, który stoi za funkcjonalnością przycisku dotyczy tylko tego przycisku (np. jest napisany w funkcji onClick), jest bardzo rozbudowany i trudno go wykorzystać w innych miejscach intefejsu.
• Silnie zależne komponenty (ang. Re-Coupling): Wprowadzanie zbyt silnie powiązanych komponentów, klas w systemie.
• System, który gra i tańczy (ang Stovepipe system): Ciężko serwisowalny system zbudowany z komponentów niepowiązanych ze sobą (funkcjonalnie).
• System z wyścigami (Race hazard): System, w którym źle zorganizowano obsługę zdarzeń i jego działanie jest zależne od ich kolejności.
• BaseBean: Umieszczanie metod typu utility w klasie bazowej, a następnie tworzenie na jej podstawie klas pochodnych. Prawidłowo używanie metod utility powinno być obsłużone poprzez delegowanie. Użycie dziedziczenia powoduje, że klasy dziedziczące polegają na funkcjonalności klasy bazowej, co może utrudniać kontrolę kodu przez programistę. Klasy typu utility są za to stabilne i podobne do siebie w różnych projektach - można je wyodrębnić w reużywalną bibliotekę.
• Wołanie przodka (ang. CallSuper): W programowaniu obiektowym możliwe jest dziedziczenie właściwości i zachowania klas bazowych i przedefiniowywanie ich. Często metoda, która przedefiniowuje metodę bazową musi się i tak odwołać do metody bazowej w środku, aby skorzystać z jej funkcjonalności - dużo lepszym pomysłem w takim wypadku jest stworzenie czysto abstrakcyjnej metody w klasie bazowej.
• Empty subclass failure
• Boski obiekt (ang. God object) - Umieszczenie zbyt wielu funkcji w jednym komponencie (klasie). Obarczenie jej nadmierną odpowiedzialnością, co powoduje problemy w utrzymaniu jej kodu i wyodrębnieniu funkcjonalności.
• Object cesspool
• Poltergeists
• Jo-jo (ang. Yo-yo problem): Sytuacja, kiedy funkcjonalność jest rozłożona pomiędzy głęboką hierarchię dziedziczących się klas. Aby zrozumieć działanie programu programista musi przechodzić w tą i z powrotem pomiędzy definicjami klas. Większość praktyk programistycznych (w tym znany artykuł “Inheritance considered harmful“) zaleca stosowanie płytkiej hierarchii dziedziczenia.
• Anemiczny model dziedziny (ang. Anemic Domain Model): Antywzorzec opisany przez Martina Fowlera. W tym przypadku model dziedziny składa się z klas z atrybutami bez metod, nie jest więc obiektowy. Logika biznesowa przeniesiona jest do innych klas, które transformują klasy dziedziny zmieniając ich stan (stąd nazwa Fowlera: skrypty transakcyjne). Antywzorzec ten przedmiotem wielu dyskusji - znaczna część metodyk tworzenia oprogramowania w Javie (w tym EJB) operuje na takim modelu. Duża część projektantów przenosi też swoje przyzwyczajenia z modelowania baz danych modelując system w ten sposób.
• Sequential Coupling
• Singletonitis
• Accidental complexity
• Action at a distance
• Accumulate and fire
• Blind faith
• Boat anchor
• Busy spin
• Caching failure Pozostawienie ustawionej flagi istnienia błędu w systemie już po obsłużeniu błędnej sytuacji
• Checking type instead of interface
• Code momentum
• Coding by exception
• Double-checked locking
• Error hiding Przechwytywanie komunikatu o błędzie w celu ukrycia go przed użytkownikiem
• Expection Handling Używanie konstrukcji językowych służących do zarządzania błędami (wyjątkami) w celu implementacji właściwej logiki programu (np. zwracanie wyniku z funkcji poprzez wyrzucenie wyjątku)
• Hard code
• Lava flow Sytuacja, w której kod znajdujący się w fazie rozwoju zostaje włączony do produkcyjnej wersji systemu. Dzieje się tak np. w czasie zmian osobowych w zespole (nowa osoba nie jest świadoma tego, że przejmowany kod nie jest jeszcze ukończony). Ten wzorzec nazywa również sytuację, w której prototyp pewnej funkcjonalności (wytworzony np. w celu sprawdzenia technologii) zostaje włączony do systemu w wersji produkcyjnej. Kod ten jest niskiej jakości, nieprzemyślany, źle zaprojektowany. Jego usunięcie (zastąpienie) wymaga dużej pracy.
• Magic number Użycie w kodzie stałych o niewyjaśnionym sensie i pochodzeniu. Np nazwa stałej nie mówi nic o jej przeznaczeniu, komentarze również nie wyjaśniają sensu użycia danej stałej. W efekcie tego działania posiadamy w kodzie magiczną liczbę, której przeznaczenia nikt nie zna.
• Magic string
• Packratting
• Spaghetti code Kod, który na skutek używania złożonych struktur językowych (duże zagnieżdżenie instrukcji warunkowych, instrukcje goto itd) jest nieczytelny i trudny do modyfikacji.
• Superboolean logic
• Copypasteryzm (ang. Copy and paste programming) Zamiast tworzyć ogólne rozwiązania, kopiuje się (i modyfikuje) istniejący kod
• Programowanie poprzez generowanie permutacji (ang. programming by permutation) Próba rozwiązania problemu poprzez konsekwentne zmiany w kodzie (bez przemyślenia sprawy i zrozumienia problemu), do czasu aż program zadziała.
• De-factoring
• Złoty młotek (ang. golden hammer) Faworyzowanie jednej technologii w celu rozwiązania wszystkich problemów, również tych, dla których istnieją znacznie lepsze metody.
• Silver bullet
• Improbability factor
• Niedojrzała optymalizacja (ang. premature optimization) Optymalizacja na podstawie niedostatecznego zbioru danych
• Ponowne odkrywanie koła (ang Reinventing the wheel)
• Odkrywanie kwadratowego koła (ang. Reinventing the square wheel) Rozwiązywanie problemu w zły sposób, podczas gdy istnieją skuteczne i sprawdzone rozwiązania. Na przykład tworzenie własnego systemu bazodanowego, zamiast wykorzystania istniejących darmowych rozwiązań, z dużym prawdopodobieństwem lepszych niż sami jesteśmy w stanie stworzyć.
• Tester Driven Development

A teraz zadanie na koniec: przeczytaj tą listę i napisz w komentarzach z iloma z tych antywzorców miałeś do czynienia w trakcie swojej przygody z programowaniem

Pokolenie informatyczne

Całkiem niedawno odbyła się ankieta, która miała dać odpowiedź na pytanie czy Polishwords powinno przejść na model Open Source. Tzn. czy kod źródłowy strony w PHP nota bene nie powinien być upubliczniony. Taka myśl mnie naszła jakiś czas temu, po tym jak sobie uświadomiłem że większość dobrych programów jakie używam to OS np. php, mysql, open office itd. Czyli coś w tym udostępnianiu kodu jest. Moja obawa wiąże się z tym żeby ten kod nie wpadł w ręce script-kiddies, które by mogły np. użyć go żeby zaspamować jeszcze bardziej internet. No bo chyba każdy wie co się stało np. z qlweb, teraz z wordpress itd.

To są wątpliwości, które jeszcze nie zostały rozstrzygnięte. Ale pozwolę sobie przytoczyć parę komentarzy które pojawiło się z okazji tej ankiety w Internecie:

Michał na stronie thecamels napisał:

(…)nie wydaje mi się on zbyt dobry.

(…)
W przypadku 7thG publikacja kodu przyniosła więcej szkód niż pożytku. W przypadku Polishwords może być podobnie. Może zbyt surowo oceniam ten serwis, ale nie jest to jakaś kosmiczna technologia z którą chciałyby się zapoznać hordy programistów. Byłby to kolejny otwarty CMS napisany w PHP. Ile takich jest? Ktoś policzył?

Nie wiem czy ktoś policzył te wszystkie CMSy. Zresztą bardzo szybko wymierają, taki na przykład php-fusion, który by dawno pewnie padł gdyby nie ciekawe forki. Ale myślę że są fragmenty kodu, które by się przydały żeby wzmocnić to co jest. Bo wiadomo że łatwiej podpatrzeć coś i skopiować niż za każdym razem pisać to od nowa. A tak by była na to zgoda (jeżeli bym wybrał odpowiednią licencję). Z wyborem licencji to pewnie najwięcej problemów będzie.

val-gaav napisał:

Po tytule newsa to sądziłem, że nasza administracja zamierza przejsć na open source …. too good to be true :/

Ten komentarz zanotowałem z jakieś strony i rozbawił mnie przednio. Nie wiedziałem że ten news tak może się kojarzyć. Widocznie ludzie już podświadomie czekają aż nasza administracja “się otworzy”

No ale dość tego cytowania, niech przemówią wyniki ankiet, zaskakujące wyniki dodam.

Pierwsze pytanie dotyczyło tego czy strona powinna przejść na Open Source czy nie. Jak widać na wykresie większość osób odpowiedziała że tak. Czyli ogromna większość ankietowanych uznała że krok w kierunku Open Source będzie dobry. Ten wynik mnie zaskoczył z tego powodu, że spodziewałem się czegoś w stylu: 80:20. Taki wynik z jednej strony cieszy mnie, że idę w dobrym kierunku, ale z drugiej strony te proporcje są trochę… podejrzane.

W drugim pytaniu ankiety pytałem się jaką część strony najbardziej rozwijać. Zastanawiam się dlaczego akurat tak ukształtowały się wyniki.  Już wkrótce czyli pod koniec miesiąca zostanie ogłoszona 2 edycja konkursu. Zakulisowo dodam, że w tej edycji nagród jest o wiele wiele więcej a sam konkurs będzie zrobiony z jeszcze większym rozmachem! Wyniki potwierdziły że warto dalej rozwijać video tutoriale, że warto dostarczać jeszcze więcej wiadomości ze świata IT oraz informacji o narzędziach informatycznych programistycznych itd. No i myślę że to jest dobra wskazówka. Ale nie zmienia to faktu że inne działy strony też będą sukcesywnie rosły i może za jakiś czas ta sama ankieta da diametralnie inne wyniki

Trzecie pytanie pojawiło się w ankiecie, bo całkiem niedawno zaszło wiele dużych zmian w wystroju strony. W kolorystyce, logo się zmieniło, dział video tutoriale przeszedł parę metamorfoz. W związku z tym z niepewnością zdecydowałem się dodać jednak to pytanie. I dobrze wyszło, bo wyniki są pozytywne Ten niebieski mały słupek to liczba osób którym strona się nie podoba. Większość osób uznało (czerwony) że się podoba, dla trochę mniejszej liczby strona jest ok (zielony), a druga od prawej kolumna to osoby, którym wygląd jest obojętny. Widać że informatycy odpowiadali w tej ankiecie

Czwarte pytanie: skąd dowiedziałeś się o Polishwords. Odpowiedzi nie pozostawiają wątpliwości, że blogi informatyczne się rozwijają. Ciekawe jak na takie wiadomości zareagują reklamodawcy, którzy teraz raczej ignorują bloggerów. Dużo osób trafiło na stronę też za pomocą wyszukiwarek. Statystyki mówią że jest to tylko jedna wyszukiwarka. Czyżby hegemonia? Oprócz tego mniej więcej tyle samo osób dowiaduje się o stronie z gazet, na szkoleniach i od znajomych.  Nie pamiętam - to osoby, do których właściwie ta ankieta nie była przeznaczona. Trochę to zaburzyło wyniki pozostałych pytań, ale wiadomo, że nie można w 100% polegać na samych ankietach, tym bardziej internetowych.

Ostatnie już pytanie: ile masz lat? Chciałem się dowiedzieć w jakim wieku są osoby odwiedzające stronę. Czy są to osoby dopiero uczące się informatyki (licealiści, studenci), czy może osoby już po nauce, w trakcie pierwszych lat pracy zawodowej, czy może jeszcze osoby już z wieloletnim doświadczeniem. Okazało się ku mojemu zaskoczeniu, że grupa “mniej niż 30″ już jakby doganiała grupę (12,20). W obliczu polskiego Internetu zdominowanego przez dzieci i młodzież, taki profil odwiedzających bardzo mile mnie zaskoczył i cieszę się że mogę zaoferować na stronie coś dla tej grupy wiekowej. Grupy ustatkowanej zawodowo zapewne, o sprecyzowanych poglądach i wymagających.

Podsumowując: właściwie każdy wynik ankiety mnie dosyć mocno zaskoczył. Czyżby obraz polskiego internetu się zmieniał? Czyżby był to ten moment, kiedy nasz polski internet dojrzeje? Wygląda na to że niedługo ujawni się kto zauważy pierwszy ten trend i zaoferuje jakieś strony i możliwości dla tej grupy wiekowej. Odważę się powiedzieć że ta grupa jest jak dotychczas ignorowana przez branżę, przez marketing i przez reklamodawców. Oni na razie chętniej patrzą na to co by chcieli ludzie z wieku 15-22 lub coś w tych okolicach.

Jedną z dziedzin niedocenionych są nadal blogi. W dobie mediów, które ze swojej natury chyba, nie mogą być obiektywne, blogosfera jest miejscem gdzie pojawiają się poglądy i przemyślenia na temat tego co jest i będzie w IT, a czego nikt inny powiedzieć nie chce.

Dziękuję wszystkim, którzy uczestniczyli w ankiecie i partnerom, którzy pomogli w jej organizacji. Mam nadzieję że informacje z niej wynikające dadzą pożytek nie tylko stronie Polishwords ale też wszystkim, którzy takich informacji potrzebują.

Kiedy nie warto używać DataSet Designera

Każdy kto oglądał chociaż jedną prezentację na temat Visual Studio, wie jak efektowny jest DataSet Designer dołączony do tego narzędzia. Pozwala on na szybkie zmapowanie struktur bazy do struktur w kodzie przez co otrzymujemy silnie typowanego DataSeta. Dzięki temu można odwoływać się do elementów DataSeta “po kropce”, czyli np. DataSet.Tabela1.Wiersze[5].KolumnaA.

Jest to dosyć wygodne narzędzie i na początku wydaje się, że dzięki niemu będzie można podbić świat i okoliczne galaktyki. Jednak rzeczywistość wygląda tak, że to narzędzie może służyć do podbicia podwórka ew. osiedla albo miasta, ale już kraju to się tym nie podbije.

Kreator DataSeta jest przydatny jeżeli masz do napisania prostą aplikację. Powiedzmy 3-4 tabele i mało relacji, mało obliczeń. Przydatny jest także do programów dla nauki. Wtedy możesz szybko przygotować widoki na dane, ekrany edycyjne, szybko zrobić obliczenia statystyczne. Jednak jeżeli piszesz komercyjny program, który ma działać dobrze i chcesz zapewnić sobie spokój w nocy, po prostu zrezygnuj z kreatora DataSeta.

Oczywiście ten post nie ma na celu zniechęcać całkowicie do kreatora, ale dać szerszy obraz tego, jakie przygody czekają na podróżnika, który odwiedzi świat kreatora DataSeta.

Problemy przedstawione w tym poście dotyczą zarówno wersji Visual Studio 2005 jak i VS 2008, w której to nie zmieniło się dużo jeżeli chodzi o architekturę kodu generowanego przez kreator. A zaczniemy od niego. Cała zabawa w pisanie dobrego kreatora polega na tym, żeby kod przez niego wygenerowany był łatwo debuggowalny jeżeli coś pójdzie nie tak. W końcu błędów w zaprojektowaniu kreatora nie da się uniknąć. Chcemy mieć pewność, że jeżeli kreator zadziała nie tak, będziemy mogli ręcznie naprawić jego błędy.

Skąd błędy w kreatorze DataSeta

Tak jest w przypadku kreatora okien (designera okien), ale nie w przypadku kreatora DataSeta.  Kod generowany jest w sposób chaotyczny, a elementy, które powinny być ze sobą jasno powiązane, nie są. Spójrz na ten kawałek wygenerowanego kodu:

[global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
private void InitCommandCollection() {
this._commandCollection = new global::System.Data.SqlClient.SqlCommand[2];
this._commandCollection[0] = new global::System.Data.SqlClient.SqlCommand();
this._commandCollection[0].Connection = this.Connection;
this._commandCollection[0].CommandText = “SELECT ID, NAME from tabTabela”;
this._commandCollection[0].CommandType = global::System.Data.CommandType.Text;
this._commandCollection[1] = new global::System.Data.SqlClient.SqlCommand();
this._commandCollection[1].Connection = this.Connection;
this._commandCollection[1].CommandText = “SELECT ID, TELEFON from tabUser”;
this._commandCollection[1].CommandType = global::System.Data.CommandType.Text;
}

[global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
[global::System.ComponentModel.Design.HelpKeywordAttribute("vs.data.TableAdapter")]
[global::System.ComponentModel.DataObjectMethodAttribute(global::System.ComponentModel.DataObjectMethodType.Fill, true)]
public virtual int Fill(MyDataSet.MyDataTable dataTable) {
this.Adapter.SelectCommand = this.CommandCollection[0];
if ((this.ClearBeforeFill == true)) {
dataTable.Clear();
}
int returnValue = this.Adapter.Fill(dataTable);
return returnValue;
}
Co z tego przydługiego kodu wynika? Otóż to, że w kodzie wygenerowanym przez kreatora SqlCommand nie jest powiązane z metodami. Po prostu ktoś kto pisał tego kreatora, przyjął, że zapytania do bazy danych będą trzymane w  kolekcji _commandCollection, a w momencie wywołania konkretnej metody, odpowiednie zapytanie zostanie wstawione do SqlDataAdapter tego kreatora (czyli this.Adapter). W ten sposób nie można określić z jakiego zapytania korzysta na przykład metoda Fill, albo inna, własna, którą możesz przecież dodać z poziomu kreatora. Czyli reasumując: widzisz zapytanie w kreatorze, ale z poziomu kodu nie wiesz jakie zapytanie (PobierzUnikalneImiona, PobierzSumeVat itp.) korzysta z jakiego zapytania (’Select distinct First_Name’, “Select SUM(VAT)’).

Zazwyczaj wiedza ta nie jest potrzebna. Jednak sposób zaprojektowania tego rozwiązania jest przykładem wielu miejsc w kodzie generowanym przez kreatora gdzie trzeba wróżyć z fusów. Jest to o tyle ważne, że obsługa tego kodu działa w dwie strony: na podstawie tego co ustawiasz w kreatorze jest tworzony kod DataSeta, a z kodu DataSeta jest tworzone to co widzisz w kreatorze. A w tym miejscu twórca kreatora musi domyślać się jakie zapytanie jest powiązane z jaką metodą. Domyślanie się takich rzeczy jest niebezpieczne, bo może prowadzić do błędów i tak się właśnie dzieje czasem w kreatorze. Takie miejsca powodują, że czasem typowany DataSet po prostu się psuje. Dlatego proste poprawianie bugów w kodzie DataSeta tutaj nie wystarczy, trzeba by było zmienić sposób w jaki kreator serializuje ustawienia do kodu. Wtedy szanse na błędy podczas tego zamkniętego cyklu kod-kreator byłyby mniejsze.

Problem jest taki, że każdy taki błąd zniechęca użytkowników do używania kreatora i tak jest też w tym przypadku. Coś podobnego można było zaobserwować gdy rozwijał się rynek programów WYSIWYG do tworzenia stron internetowych. Po latach uciążliwości z FrontPage, który generował wielkie, nieoptymalne, nieczytelne i często wadliwe pliki HTML (wtedy jescze), pojawił się konkurencyjny program Dreamweaver, który generował piękny kod HTML. W miejscu gdzie była spacja była spacja a nie dziesiątki niepotrzebnych znaczników z których każdy zwiększał ryzyko tego, że strona nie będzie chodzić poprawnie nigdzie poza FrontPage. Dreamweaver pokazał, że można generować i interpretować przejrzysty kod i że to jest droga do osiągnięcia sukcesu z kreatorami. Szkoda, że w tym przypadku team Visual Studio nie uczy się z innych obszarów działalności swojej firmy.

O tym problemie pisałem już przeszło 2 miesiące temu na Connect i bez odzewu. Możliwe, że już wystarczająco dużo osób zniechęciło się do tego designera, żeby team VS planował go dalej rozwijać.

Jak zapobiec błędom

Tutaj pojawia się problem. Ponieważ jeżeli kreator DataSeta popełni błąd tak że nie będzie się uruchamiał znowu to jedyne co zostaje to otworzyć ręcznie kod i znaleźć błąd i go usunąć. Niestety w tym momencie twórcy DataSeta typowanego nie dają żadnej pomocy. Zakładają przy tym pewnie, że wygenerowany kod będzie działający w 100%. Niestety tak nie jest i czasem dzieje się tak, że za którymś razem kreator po prostu już się nie otworzy. Na przykład przez taki błąd:

Column requires a valid DataType.

Oprócz informacji o tym, że któraś kolumna nie ma poprawnego typu nic więcej się nie dowiemy. Podpięcie drugiego Visuala tutaj nic nie da. Tak samo Stack Trace, który wcale nie zaskakująco wygląda tak:

at System.Data.DataColumn.set_DataType(Type value)
at System.Data.XSDSchema.SetProperties(Object instance, XmlAttribute[] attrs)
at System.Data.XSDSchema.HandleElementColumn(XmlSchemaElement elem, DataTable table, Boolean isBase)
at System.Data.XSDSchema.HandleParticle(XmlSchemaParticle pt, DataTable table, ArrayList tableChildren, Boolean isBase)
at System.Data.XSDSchema.HandleComplexType(XmlSchemaComplexType ct, DataTable table, ArrayList tableChildren, Boolean isNillable)
at System.Data.XSDSchema.InstantiateTable(XmlSchemaElement node, XmlSchemaComplexType typeNode, Boolean isRef)

(dalsza część pominięta dla przejrzystości postu)

Nie pozostaje w tym momencie nic jak szukanie na oślep w kodzie wygenerowanym przez kreator. A wystarczyłoby dodać odpowiednią informację jakiej kolumny dotyczy błąd. Wtedy znalezienie problemu na własną rękę byłoby możliwe. No bo nie oszukujmy się, że przy zastosowanej architekturze kodu ręczne naprawy są nieuniknione.

Podsumowanie

Podsumowując staraj się używać kreatora DataSeta z głową i nie zawsze. Jest to wygodne narzędzie - owszem. Ale tylko do pewnego momentu. Zwłaszcza nie polecam korzystania z DataSeta bez robienia kopii zapasowych albo posiadania kontroli wersji. A jaka będzie przyszłość tego narzędzia? Czy będzie poprawiane? Nie sądzę i raczej myślę, że w końcu zostanie wprowadzony zamiennik, który będzie to wszystko realizwał zupełnie inaczej, bo na podstawie tego co jest nie da się dużo naprawić w zachowaniach kreatora DataSeta. Pozostaje mieć nadzieję, że team VS uczy się na błędach i nie popełni tych samych w przypadku kolejnych kreatorów, które są nieuniknione w środowiskach RAD.

Standardowe snipety w Visual Studio 2008

Snipety to kawałki kodu, które można wygenerować wpisując słowo kluczowe i naciskając dwa razy przycisk tabulatora [TAB]. Po wygenerowaniu kodu niektóre jego fragmenty są zielone, wpisanie w te pola wartości powoduje aktualizację innych pól kodu wygenerowanego za pomocą snipeta (patrz np. snippety właściwości).

Poniżej przedstawiam listę standardowych snipetów dostępnych w Visual Studio 2008 Express i kod jaki generują. Przeczytaj całość >>

Dzień programisty

Z okazji tego dnia zycze Wam wszystkiego najlepszego!

Jezeli nie wiesz jak obchodzic ten dzien, to prosze bardzo: mozna pisac w tym dniu smieszny kod, a po napisaniu juz naprawde dobrego kawalka smiesznego kodu zajac sie czyms innym: np. relaksujaca partia w ulubiona gre:

http://www.nationaltabletennis.com/buy/Indoor_Tennis_Tables/Prince_Match_Table
http://www.jiyuangroup.com/List.asp?Shop_ID=328
http://www.jiyuangroup.com/product.asp?Sort_ID=37

pozdrawiam!

Osoba znająca Windows Forms i angielski poszukiwana

Potrzebna jest taka osoba do tłumaczenia FAQ na język polski. Nie jest to jakaś ciężka praca, zazwyczaj wpis to 1-2 linijki tekstu i kod. Ale oczywiście zajmuje to trochę czasu. Ale nie ma nic za darmo…
Jakby ktoś był zainteresowany 15min/dzień zajęciem to zapraszam.

Outlook 2002 a UTF8

Okazuje się, że Outlook 2002 nie korzysta zawsze z kodowania UTF8. Jeżeli wyeksportujesz książkę adresową z tego programu do formatu “Windows - oddzielone przecinkiem” otrzymasz plik zakodowany w ANSII - czyli według staaarego kodowania znaków. Żeby odczytać taki plik trzeba wskazać odpowiednią stronę kodową czyli np. dla polskich znaków win-1250 a dla “duńskich” win-1252

Forum CodeGuru: todo

Przeglądając inny blog na CodeGuru znalazlem taki oto wpis, bardzo ciekawy z grudnia 2005. Szkoda ze sie nie zmienilo wiele od tego czasu:

http://codeguru.pl/blog-postdetails-9-26-58.aspx