Najlepsze zakładki internetowe - część II
W poprzedniej części przyjrzałem się wszystkim serwisom polskojęzycznym, które są na liście dodajdo.com. W tej części przyjrzę się bliżej serwisom, które przeszły testy. Jest ich niewiele, więc dodałem parę obrazków i zobaczymy co z tego wyjdzie. Sprawdziłem czy strony mają informacje kontaktowe. Jeżeli miały - wysłałem mejla, żeby dowiedzieć się jakie mają plany na przyszłość. Dostałem odpowiedzi, które zacytuję (niestety dopiero w trzeciej części poradnika). Za brak odpowiedzi i za brak blogów dałem punkty ujemne. W ten sposób określiłem, które serwisy się rozwijają, a które zostały prawdopodobnie porzucone przez twórców. Takie serwisy zwykłem nazywać internetowymi wrakami. Zachęcam do dalszej lektury
8 rad jak wybrać dobrą nazwę domeny
Dzisiaj chciałbym poświęcić trochę czasu na temat zasad dobierania dobrej nazwy domeny. Materiały, z który skorzystałem są wylistowane na samym dole tego wpisu. Jest to zestawienie tych reguł i kilku własnych wniosków z polskiego Internetu. Te spostrzeżenia mogą przydać się autorom startupów, normalnych stron internetowych jak i blogów. No to zaczynamy.
Najlepsze zakładki internetowe - część I
W tym poście zrecenzuję wszystkie zakładki internetowe dostępne standardowo w dodajdo.com. Dodajdo.com to serwis, który umożliwia umieszczenie na stronie albo blogu takiego przycisku jak pod każdym postem na moim blogu. Każdy może sobie więc niby łatwo dodać ciekawą rzecz do swojego konta zakładek. Konto zakładek to konto na serwisie zakładek, gdzie trzyma się linki do ciekawych rzeczy w Internecie. W odróżnieniu od zakładek zapisywanych w przeglądarce, zakładki internetowe są dostępne z każdego miejsca gdzie masz Internet. Oprócz tego możesz dzielić się swoimi zakładkami z innymi ludźmi i tagować je, przez co łatwiej znajdziesz niby je z powrotem.
Chciałem przy okazji napisać, że tak, mogłem dać lepsze i większe zdjęcie Princess Lei tutaj.
Jak założyć bloga cz. 1
Jest to pierwsza część poradnika jak prowadzić profesjonalny blog. W tej części przeczytasz o tym jak wybrać dobrą domenę, dlaczego odradzam korzystanie z hostingu blogów, po co korzystać z RSS i jak czerpać inspirację do pisania, oraz jakie są zasady blogowania. Zapraszam do lektury.
Jak być zdrowym programistą
Jeszcze jeden wpis na dzisiaj. Tym razem Derek pisze o tym jak być zdrowszym programistą (informatykiem) w 7 prostych krokach:
1. Ergonomiczne miejsce pracy
2. Używaj ergonomicznej myszki i klawiatury
3. Patrz za swój monitor (w dal, odpręż oczy)
4. Utrzymuj poprawną postawę ciała
5. Pij wodę albo napoje
6. Rób regularne przerwy w pracy
7. Uprawiaj jakiś sport, rób poranne i wieczorne ćwiczenia
W skrócie tak by to wyglądało ale zachęcam do przeczytania całego posta Dereka, który przypomina o tym o czym łatwo w pracy programisty zapomnieć: czym więcej siedzisz w miejscu, tym masz gorszą formę zdrowotną.
Ściągnij VS 2010 i .NET Framework 4.0 CTP
Właśnie zauważyłem że Nick spostrzegł że można ze stron Microsoftu ściągnąć CTP VS 2010 i .NET Framework 4.0. Już nie mogę doczekać się kiedy się ściągnie i zaraz będę pisał co tam nowego.
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.
Microsoft naprawił buga!
W trakcie używania DataSet designera natrafiłem na pewnego buga, który istniał od wersji 2005 Visual Studio. Wygląda on w ten sposób, że dodając do tabeli kolumnę z ustawionym Expression nie można rekonfigurować ponownie DataSeta.
5 zasad użytkowości (ang. usability)
Użytkowość, czyli po angielsku usability. W tym wpisie przedstawię krótko 5 zasad użyteczności, których przestrzeganie może ulepszyć Twoją stronę internetową. Spróbuję w tym zestawieniu nawiązać też trochę do aplikacji, ponieważ zasady te można przenieść na projektowanie programów komputerowych.
Jeżeli uznasz poniższe obrazki za przydatne na swojej stronie, skorzystaj z nich, ale nie zapomnij dodać linku zwrotnego do Polishwords (ps. nie hotlinkuj - serwer by tego nie wytrzymał!)
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ść >>
« Starsze posty
WordPress, Pool Theme - Borja Fernandez - mod
Nakarm RSS
Najświeższe komentarze