RSS feedy jsou dnes jiz pomerne rozsirene. Server ktery nema oranzovou ikonku XML pro me neexistuje 😉

Nastesti nejen blogy, ale i velke mnozstvi zpravodajskych serveru a online magazinu tuto moznost pristupu podporuje. Ja jsem „RSSka“ objevil asi tak pred rokem a pul. A musim rict ze jsem si opravdu oblibil cteni webu timhle zpusobem. Prijde mi to mnohem efektivnejsi a prijemnejsi zpusob nez prochazeni webu browserem „naslepo“. Taky jsem na nekolik webu zanevrel jen proto, ze tuto moznost nepodporovaly zatimco jejich konkurence ano.

Od pocatku jsem vystridal nekolik RSS ctecek. Na radu kolegy jsem zacal s Feedreaderem. Ten mel jednu velkou vadu – pokud se neukoncil korektne (treba kdyz se zaviral pomalu pri soucasnem shutdownu Windows), prisel jsem nekolikrat o seznamy vsech RSS zdroju ktere jsem mel subscribed nebo o oznaceni neprectenych zprav.

Po jednom takovem padu jsem se nastval a nainstaloval RSS Reader. S RSS Readerem jsem byl spokojeny az na jednu malickost. Nektere RSS feedy nechtel odebirat a zobrazoval pouze obecnou chybovou hlasku, z ktere nebylo vubec nic jasne. Feedreader ani ostatni ale zadny takovy problem nehlasily.

Moji posledni volbou je Jetbrains Omea Reader. Pouzivam ho vic nez ctvrt roku a jsem s nim (zatim) maximalne spokojeny. Jetbrains je pro Java developery v podstate kultovni firma, diky jejich IDE Intellij Idea, ktere zhmotnuje firemni slogan „Develop with pleasure„. O Idee se nechci moc rozepisovat, nebot to by dalo na nekolik dalsich postu.

Omea Reader umozuje sledovat a cist RSS/Atom feedy, newsgroupy a organizovat Favorites zalozky prohlizece. Vse v jednom. Specialne pro feedy prinasi system pohledu. Preddefinovane pohledy jako napriklad: „Today“, „Yesterday“, „This Week“ umoznuji prohrabavat se informacemi ne podle toho „odkud“ pochazeji ale kdy byly publikovane. System pohledu je ale rozsiritelny, takze si muzete vytvaret dalsi pohledy pomoci „pravidel“. Uzitecna vec.

Mrknete na obrazek, je to lepsi nez se tady dlouze rozepisovat.

A co je dulezite: Casove neomezenou licenci na Omea Reader lze ziskat do konce brezna zdarma. Tak si pospeste 🙂

PS: Jak ctete RSS feedy a blogy vy? Jestli mate nejaky tip, napiste ho do commentu…

Pres vanoce jsem cast volneho casu venoval cteni a prave docitam dobrou knizku Refactoring: Improving the Design of Existing Code od Martina Fowlera (Fowler je mimo jine autorem UML Distilled, super knizky o UML, ktera se mi dostala do ruky pred par lety).

Knizka pojednava o refactoringu, neboli upravach existujiciho kodu za ucelem zvyseni jeho kvality aniz by tim vsak utrpelo jeho vnejsi chovani. Je pekne strukturovana: tzn. zacina tim proc je refactoring uzitecny, jak ho praktikovat, co je k nemu potreba. Dulezite jsou ale dve casti knihy – seznam tzv. bad smells a seznam jednotlivych refactoringu, ktere tyto zapachy odstranuji. Vsechno je doplnene srozumitelnyma prikladama v Jave.

Jak jsem si tak procital jednotlive bad smelly, vybavovaly se mi casto i classy, na kterych bych jednotlive zapachy 🙂 dobre ilustroval 🙂

Pokud zrovna nemate tuto knizku po ruce, doporucuju se podivat do helpu ke svym IDE. Idea, Eclipse i JBuilder refactoring uz dnes podporuji a velmi ho zjednodusily – vetsinou na pouhou klavesovou zkratku (kdyz vite co oznacit ;-)). Pro Ideu existuje pekny tutorial ktery ukazuje refactoring pomoci tohoto IDE.

Koho zajima refactoring vic, muze se mrknout na web ktery shromazduje veskere materialy na dane tema: www.refactoring.com. A kdo chce, muze se subscribnout na RSS feed ktery informuje o novinkach na webu.

Tabulka SmellsToRefactorings ukazuje seznam nejcastejsich bad smellu a zaroven prinasi rady jak se jich pomoci refactoringu zbavit.

No a nakonec abecedni seznam refactoringu s jejich popisy.

I would like to point out few problems which I’ve experienced during my experiments with WseWsdl2.exe tool. I am using WseWsdl2.exe from Microsoft Web Services Enhancements 2.0 SP2. The WseWsdl2.exe is WSDL to SoapClient Tool. It should replace current .NET Wsdl.exe tool. What I find quite disappointing are the error messages produced by this tool. WSDLs we use in our project are compilable without any problems with Wsdl.exe but WseWsdl2.exe complains. What is worse, that the error messages are very unclear. Documentation didn’t help us, neither the Google search. We had to take our WSDLs and remove element after element to find out what’s wrong with them. Here are the findings, maybe it will help someone having similar troubles. This is the reason for this post.

First problems occur when the WSDL definition contains more than one message part in the (SOAP) message. But the error message says this:



An error occurred processing this WSDL. More information:

System.Exception: Invalid WSDL file from SoapService

at ClientGen.ClientGen.GetBindingType(…)

at ClientGen.ClientGen.WriteCSOperationBinding(…)

at ClientGen.ClientGen.WriteOperationBinding(…)

at ClientGen.ClientGen.WriteClass(…)

at ClientGen.ClientGen.GenerateCode(…)

at ClientGen.ClientGen.GenerateCode(…)

at ClientGen.Class1.Main(String[] arguments)



I know that WSDLs describing messages with more than one message part (referring element) in SOAP body should not be used. It is stated in the WS-I Basic Profile 1.1. We can change the WSDL to wrapped-literal, no problem. But the tool should not produce this general error!

The second problem I would like to point occurs when the WSDL contains unsupported extension element. We are using custom extesion elements within the soap:binding. The extension element present in our WSDL is not marked with wsdl:required="true". So it should be silently ignored if the consumer does not understand him or cannot process him (as stated in the WS-I Basic Profile 1.1, which also clarifies and tights up the rules from the WSDL specification). WseWsdl2.exe does not ignore them – but fails:



An error occurred processing this WSDL. More information:

System.InvalidCastException: Specified cast is not valid.

at ClientGen.ClientGen.WriteCSOperationBinding(…)

at ClientGen.ClientGen.WriteOperationBinding(…)

at ClientGen.ClientGen.WriteClass(…)

at ClientGen.ClientGen.GenerateCode(…)

at ClientGen.ClientGen.GenerateCode(…)

at ClientGen.Class1.Main(String[] arguments)



Again, the error message is very, very unclear! For me it seems that the level of WSDL specifications support is much lower than it was in previous version. Without any warning in the documentation. Or Am I missing something?

Zakladam blog, proc ne… Blog ma spousta lidi.

Nebude monotematickej, nebude vaznej, nebude ucelovej,

nebude spisovnej. Jakej bude? To se uvidi…Tak zatim.