Přeskočit na hlavní obsah
  1. Tags/

Knihy

2020


2019


2017


Kniha Clojure Applied

·3 min
Kniha Clojure Applied je občas na internetu doporučovaná jako "druhá" kniha o Clojure, kterou byste si měli přečíst. Osobně bych řekl, že spíš než "druhou", bych ji doporučil jako "třetí".

Kniha Living Clojure

·3 min
Vrátil jsem se po čase ke Clojure a věrný svému přístupu jsem sáhnul po knize. Living Clojure od Carin Meier je dobrá kniha pro (věčné) Clojure začátečníky.

2014


Třetí rok s Kindlem

·5 min
Je to už třetí rok, co čítávám odborné knihy výhradně na Kindlu. Letos se docela urodilo - celkem jsem přečetl 20 knih, z toho třetinu o leadershipu.

2013


Zdravý programátor

·4 min
Pryč jsou doby, kdy stačilo, aby byl programátor pragmatický. Dnes musí být ještě navíc zdravý. Programátoři totiž často vedou dosti nezdravý způsob života. Recenze knihy, která radí ke svému (programátorskému) zdraví přistupovat agilně.

Joel test, má ještě smysl?

·6 min
Jako vývojáři jste se možná už někde setkali s Joelovým testem. Když jsem na něj cca před osmi lety narazil, bylo to pro mne jako zjevení. A pracoval jsem ve společnosti, jejíž skóre v tomto testu bylo... ehm, nula.

Oracle SOA certifikace

·3 min
Půlrok se sešel s půlrokem a já jsem si vystřihnul další certifikaci. Tentokrát jsem chtěl něco, čím bych zakončil své roční působení na projektu a důstojně :-) tak završil trnitý proces získávání znalostí o nové technologii: Oracle SOA Suite.

Okolnosti tomu chtěly, že jsem se zrovna trefil do přelomu, kdy Oracle jednu  SOA certifikaci nahrazuje jinou. Aktuální certifikace, která je k dispozici od letošního ledna, se jmenuje  Oracle SOA Suite 11g Certified Implementation Specialist. Já, protože jsem se ke zkoušce přihlásil již dříve, jsem nyní obdržel certifikaci Oracle Service Oriented Architecture Infrastructure Implementation Certified Expert. Uff! To je titul :-/

Každopádně, co je nám po jménu? Podstatné je, jestli se obě zkoušky od sebe nějak obsahově liší. Liší? Ano, ale pouze drobně - v nové certifikaci přibylo pouze něco málo o governance, deploymentu a monitoringu, ale gró zůstává stejné: jednotlivé komponentní technogie (viz Exam Topics).

Jak dlouho jsem se na certifikaci připravoval? Přípravě přímo na zkoušku jsem věnoval cca 3 týdny - přečetl jsem si guide (viz dále) a prošel testovací otázky. Ale obecně jsem k certifikaci studijně směřoval téměř celý rok. Za jeden z podstatných zdrojů vědomostí totiž považuji přímou zkušenost s technologií - 7 měsíců intenzivního "programování".

Kniha

Vývoj samotný z učedníka mistra neudělá. Primárním zdrojem informací jsou pro mne knihy, takže od nich jsem začal: hned z počátku práce na projektu jsem si koupil knihu Oracle SOA Suite 11g Handbook.

Jde o 800stránkový opus a pokud to někdo myslí se SOA Suitou vážně, tak rozhodně tuto knihu doporučuji - obsahuje vyčerpávající sumu témat (daleko přesahující rozsah zkoušky), které umožní pochopit principy, které za SOA Suitou stojí a provede návrhem, vývojem, testováním a provozem jednotlivých komponent a technologií. Ještě jednou: vysoce doporučuji!

Školení

Školení obvykle v portfoliu přípravných zdrojů nemám, tentokrát se mi ovšem naskytla příležitost, tak jsem ji využil a absolvoval školení hned tři:
  • Oracle SOA Suite 11g Implementation Bootcamp
  • Oracle Service Bus 11g
  • Oracle BPM Suite 11g Implementation Bootcamp
Školení nebyla špatná. Probíhala formou labů, takže si člověk mohl věci prakticky vyzkoušet. Tematicky školení zkoušku více méně pokrývala (s výjimkou BPM, který v certifikaci není) a umožnila mi trochu jiný pohled na věc, než byl třeba v knize, nebo jsem sám získal praxí. Z pohledu certifikace nejsou školení nutností, ale příjemným bonusem - stejné informace se dají získat i jinde a levněji :-)

Certifikační guide

Krátce před zkouškou jsem pořídil knihu Oracle SOA Infrastructure Implementation Certification Handbook, což je certifikační guide zaměřený na původní zkoušku (1Z0-451). Co se týká obsahu, kniha je slušným, velmi lehkým úvodem do SOA Suite. Jako studijní materiál je nedostačující. Co je na ní cenné, je sada testovacích otázek a odpovědí ke každému tématu, plus závěrečný test (také s řešením).

Závěr

Pokud vezmu v potaz svoji celoroční "přípravu", tak pro mne certifikace splnila (opět) svůj hlavní účel - motivační prostředek pro sebevzdělávání. Tak jako u jiných zkoušek i nyní mě certifikace přinutila podívat se do hloubky i na témata, která nutně (projektově) nepotřebuju a umožnila mi tak lépe pochopit celý kontext dané technologie.

Kecám, nepřinutila - já to dělám rád ;-)

Související články

Druhý rok s Kindlem

·4 min
Tak jsem strávil druhý rok s Kindlem. Jaké odborné knihy mojí čtečkou protekly? Bylo jich méně, než loni, ale to nevadí - důležité je nepřestávat číst.

Dead Letter Channel nebo Invalid Message Channel? Toť otázka

·3 min
Řešil jsem teď zajímavou filozofickou otázku. Potřeboval jsem v rámci integrace někam odkládat JMS zprávy, které se nepodařilo aplikačně zpracovat. Rozhodl jsem se je odkládat do speciální fronty, kterou jsem nazval Dead Letter Queue. Což je termín, který se používá na platformě WebSphere MQ. Naopak moje platforma je SOA Suite, která žádný podobný termín nemá (a řekl bych, že nejen termín, ale ani koncept).

Své řešení jsem hrdě (a úspěšně) představil v týmu a argumentačně ho podpořil tvrzením, že jde o vzor z Enterprise Integration Patterns (EIP). Tyto patterny jsou shrnuty v knížce, kterou vřele doporučuji - zcela jednoznačně jde o bibli messagingu.

Už je to nějaký čas, co jsem knížku četl a jelikož jsem si matně pamatoval, že ve skutečnosti jsou tam dva takové podobné vzory, znovu jsem si dané kapitoly pročetl. Co kdyby se vynořila nějaká zvídavá otázka :-) Po (znovu)přečtení jsem uvažoval, kterému vzoru se moje řešení více podobá - Dead Letter Channel nebo Invalid Message Channel? Ještě než se k těmto vzorům dostanu, předestřu, jak vypadá moje řešení.


Aniž bych zabíhal do přílišných podrobností. JMS listener vyčte zprávu z JMS fronty Input Queue a pošle ji ke zpracování do orchestrační/business logiky. Zde proběhnou validace zprávy, plus nějaká omáčka a pak jsou v rámci orchestrace volaný 3-4 externí služby (z diagramu vypuštěno). Pokud je během orchestrace vyhozena SOAP fault, zapíše se iniciální zpráva do JMS fronty Dead Letter Queue. Zároveň se do hlavičky zprávy přidá "uživatelská hlavičková vlastnost" (custom header property), kam se zapíše, ze které fronty byla zpráva původně vyčtena.

Nyní k oběma vzorům. První odstavec je definice vzoru a následuje signifikantní text, který jsem si podtrhl na  Kindlu. A obrázek :-)

Dead Letter Channel


"When a messaging system determines that it cannot or should not deliver a message, it may elect to move the message to a Dead Letter Channel."

"Typically, each machine the messaging system is installed on has its own local Dead Letter Channel so that whatever machine a message dies on, it can be moved from one local queue to another without any networking uncertainties. ... When the messaging system moves the message, it may also record the original channel on which the message was supposed to be delivered."

"Determining if a message should be moved to the Dead Letter Channel is an evaluation of the messages's header performed by the messaging system."

Vzor Dead Letter Channel (zdroj EIP)

Invalid Message Channel

"The receiver should move the improper message to an Invalid Message Channel, a special channel for messages that could not be processed by their receivers."

"An Invalid Message Channel is like an error log for messaging. When Something goes wrong in an application, it's a good idea to log the error. When something goes wrong processing a message, it's a good idea to put the message on the channel for invalid messages."

"If an error occurs while processing the message, the message is invalid and should be moved to the Invalid Message Channel. If it occurs while the application processes the data from the message, that is an application error that has nothing to do with messaging."

Vzor Invalid Message Channel (zdroj EIP)

Co to teda je?

Moje řešení má znaky obou výše uvedených vzorů, ale zároveň se jim i vymyká. Což není nic divného - moje platforma není messagingová, JMS fronty používá pouze jako rozhraní kvůli decouplingu.

Co si o tom myslíte vy? Jak byste nazvali takovou "odkládací" frontu? Nebo existuje nějaký vzor, který toto řešení/problém pokrývá lépe? Budu rád, když se v diskuzi podělíte.

Související články