Posts

Při studiu na nedávnou Flexovou certifikaci jsem se musel poměrně hodně hluboko ponořit do Flexové dokumantace. A to jak do reference ActionScriptu, tak do konceptů a architektury samotného Flexu Using Flex. Důvod byl jednoduchý — nedostatek praxe jsem musel nahradit porozuměním.

Protože se mi architektura Flexu líbíla, rád bych se k němu vrátil a pro ten případ si tady chci zaarchivoval pár věcí, které mne zaujaly.

Bidirectional binding #

Pokud chci mít obousměrné datové propojení dvou komponent, mám k dispozici tři způsoby. Buď je vzájemně provázat jednosměrným bindingem:

Dneska jsem řešil (pro mne) zajímavý případ - potřeboval jsem v Oracle databázi postavit dotaz s následujícími parametry:

• zkontrolovat, že dva určité záznamy mají hodnotu DATE mezi 17:00 včerejšího dne a 7:00 dnešního dne,
• jako výstup dotazu mít hodnotu true nebo false (v Oraclu 1 a 0).

CREATE TABLE result_log (
    code VARCHAR2(20),
    logged DATE
  );

do které vložíme  dva záznamy odpovídající našemu intervalu (17:00-7:00):

INSERT INTO result_log VALUES
  ('codeA', TRUNC(sysdate - 1) + 22 / 24);
INSERT INTO result_log VALUES
  ('codeB', TRUNC(sysdate) + 5 / 24);

Výsledek by měl vypadat nějak takto:

SELECT code, TO_CHAR(logged,
                     'YYYY-MM-DD HH24:MM:SS')
             AS logged
  FROM result_log;

CODE                 LOGGED
-------------------- -------------------
codeA                2012-04-05 22:04:00
codeB                2012-04-06 05:04:00

Požadované záznamy (codeA, codeB) vybereme následujícím dotazem a zároveň je ohodnotíme, že jsou/nejsou z daného časového intervalu (1 = jsou, 0 = nejsou):

SELECT
  CASE
    WHEN (logged BETWEEN
        (TRUNC(sysdate - 1) + 17 / 24) AND
        (TRUNC(sysdate) + 7 / 24))
    THEN 1
    ELSE 0
  END AS eveluation
FROM result_log
WHERE code IN ('codeA', 'codeB');

EVELUATION
----------
         1
         1

Jelikož nad výsledky potřebujeme v podstatě provést logickou konjunkci (AND) můžeme k tomuto účelu použít funkci DECODE. Výsledný dotaz pak vypadá následovně:

SELECT DECODE(SUM(eveluation), COUNT(*), 1, 0)
  AS evaluation
FROM
  (SELECT
    CASE
      WHEN (logged BETWEEN
        (TRUNC(sysdate - 1) + 17 / 24) AND
        (TRUNC(sysdate) + 7 / 24))
      THEN 1
      ELSE 0
    END AS eveluation
  FROM result_log
  WHERE code IN ('codeA', 'codeB')
  );

EVALUATION
----------
         1

Elegantní na tomto řešení je, že stačí pouze přidat do klauzule WHERE další kód (codeC) a vše ostatní bez problémů dál funguje.

Poslední dobou jsem se zabýval integračním projektem, který používal komerční technologii od IBM - WebSphere Messaage Broker, který jako infrastrukturu využívá WebSphere MQ. Abych měl, jako solution architekt, k tomuto řešení nějakou alternativu, rozhodl jsem se nastudovat open source messagingovou platformu ActiveMQ od Apache Software Foundation (ASF).

ActiveMQ je messagingový server postavený nad specifikací Java Message Service (JMS), a který ve spojení i frameworkem Apache Camel implementuje Enterprise Integration Patterns (EIP). Obecné vlastnosti ActiveMQ se dají shrnout do následujících bodů:

• implementace JMS 1.1,
• integrace se Springem,
• integrace s (Java) aplikačními servery,
• vlastní protokol OpenWire pro high perfomance klienty v Javě, C, C++ a C#,
• embedded broker,
• broker clustering,
• REST API,
• AJAX API,
• ad.

Komunikační protokoly
Klienti se můžou k brokeru připojit pomocí různých protokolů, které jsou vystaveny pomocí tzv. transportních konektorů. Mmj. jsou k dispozici obligátní:

• TCP
• SSL
• HTTP(S)
• UDP

<transportConnectors>
    <transportConnector
        name="openwire"
        uri="tcp://localhost:61616?trace=true"/>
    <transportConnector
        name="ssl"
        uri="ssl://localhost:61617"/>
    <transportConnector
        name="vm"
        uri="vm://localhost"/>
</transportConnectors>

Message Storage
JMS specifikace definuje dva způsoby doručení zpráv (DeliveryMode) - perzistentní a neperzistentní. Pokud jsou zpráva, nebo producent nastavený jako perzistentní, musí JMS provider zajistit bezpečné uložení zpráv (aby např. přežily výpadek serveru). ActiveMQ nabízí pro uskladnění zpráv čtyři strategie:

• KahaDB message store. Rychlá a škálovatelná file-based perzistence s transakčním žurnálem a rychlým zotavením.
• AMQ message store. Předchůdce KahaDB, obdobné vlastnosti.
• JDBC message store. Perzistence zpráv do relační databáze.
• Memory message store. Všechny pezistentní zprávy jsou drženy v paměti, tj. nejsou perzistovány ve smyslu JMS specifikace.

Midje je úspěšná TDD knihovna pro Clojure unit testy. Jejím autorem je jeden ze signatářů Agile Manifesto, Brian Marick.

Všechno má svůj vývoj a tak jsem se rozhodl změnit jednak syntax highlighting a jednak způsob zápisu Clojure kódu. Obojí - samozřejmě - k lepšímu ;-)

Pokud se chceme k WebShere MQ (WMQ) připojit z Javy, máme k dispozici dvě možnosti - buď použít WMQ třídy pro Javu, nebo je možné komunikovat pomocí Java Message Service (JMS). Obě možnosti mají svoje pro a proti, takže krátké shrnutí v pár bodech:

• WMQ třídy pro Javu:
• zapouzdřují Message Queue Interface (MQI),
• poskytují plnou sadu funkčností WMQ,
• je to proprietární řešení, ale jednodušší k používání, než JMS.
• (WMQ třídy pro) JMS:
• Java “industry standard” pro messaging,
• je součástí Java EE specifikace (a tedy součástí většiny (Java) aplikačních serverů),
• umožňuje spravovat administrované objekty (connection factory, fronty ad.) v centrální repository.

package com.adastracorp.jprase.wmq.java;

import com.ibm.mq.MQMessage;
import com.ibm.mq.MQQueue;
import com.ibm.mq.MQQueueManager;
import com.ibm.mq.constants.CMQC;


public class JavaProvider {

    private static final String QM_NAME = “QM_JAVA”;
    private static final String HOSTNAME =
                                        “192.168.6.128”;
    private static final String CHANNEL =
                                        “JAVA.CHANNEL”;
    private static final int PORT = 5557;
    private static final String QUEUE = “JPRASE”;

    private static void init() {
        MQEnvironment.hostname = HOSTNAME;
        MQEnvironment.channel = CHANNEL;
        MQEnvironment.port = PORT;
    }

    public static void main(String[] args)
                                    throws Exception  {
        init();

        MQQueueManager queueManager =
                            new MQQueueManager(QM_NAME);
        MQQueue queue = queueManager
                        .accessQueue(QUEUE,
                                     CMQC.MQOO_OUTPUT |
                                     CMQC.MQOO_INQUIRE);

        MQMessage message = new MQMessage();
        message.writeUTF(“Hello, WMQ!");

        queue.put(message);

        queue.close();
        queueManager.disconnect();
    }
}

Chystám teď do firmy takovou kumulovanou prezentaci o Enterprise Integration Patterns (EIP), WebSphere MQ (WMQ) a WebSphere Message Brokeru (WMB), tak bych se chtěl postupně podělit o pár konceptů. První z nich je koncept remote messaging na WMQ.

Následující příklad předpokládá již hotovou instalaci WMQ a je zaměřen na komunikaci dvou instancí WMQ - jedna je na lokálním a jedna na vzdáleném prostředí. Pro vyzkoušení, nebo prezentaci je možné použít i jenom jedinou, lokální instanci. Nejdřív si na úvod definujeme základní komponenty, které bude potřeba vytvořit, a které spolu budou komunikovat:

Queue Manager
Správce front vlastní a spravuje fronty, kanály a další objekty. Je to první WMQ objekt, který je nutné na čisté instalaci vytvořit. Správce umožňuje další objekty vytvářet, konfigurovat, spouštět, vypínat atd. Pro přístup k frontám a zprávám poskytuje queue manager dvě rozhraní (API):

• Message Queue Interface (MQI) - proprietární rozhraní umožňující kompletní přístup k WMQ.
• Java Message Service (JMS) - Java specifikace pro asynchronní messaging.

Queue
Datová struktura pro ukládání zpráv. V našem příkladu budeme používat čtyři typy front:

• Local queue - lokální fronta pro ukládání zpráv.
• Remote queue - definice fronty, která je vlastněná jiným queue managerem.
• Transmission queue - (lokální fronta,) dočasné úložiště zpráv určených pro vzdáleného queue managera.
• Dead-letter queue - lokální fronta určená pro nedoručitelné zprávy.

Barevně jsou vyznačeny nově vytvářené objekty. V případě, že existuje pouze jedna (lokální) instance WMQ, je možné oba queue managery vytvořit lokálně. Obecný postup vytvoření objektů je následující:

1. Vytvoření queue managera.
2. Vytvoření dead-letter queue.
3. Vytvoření local (remote) queue.
4. Vytvoření transmission queue.
5. Vytvoření message channelu.
6. (Spuštění sender message channelu.)

Jelikož nejde o tutoriál, nebudu popisovat vytvoření jednotlivých objektů - to je dobře popsáno v dokumentaci. Pouze bych zde zmínil, že všechny uvedené objekty lze vytvořit dvěma způsoby - buď pomocí grafického rozhraní MQ Explorer (velice snadné), nebo pomocí MQ Script Commands (MQSC).

Výsledná architektura vypadá takto:


A k čemu je to vůbec dobré, posílat zprávu z jednoho queue managera na jiný? Jenom čistě pro posílání zpráv to samozřejmě smysl nemá - na to by stačily fronty definované v rámci jednoho queue managera, ke kterým by se připojovali komunikující konzumenti a provideři.

Smysl to začíná dávat v momentě, pokud potřebuje komunikovat více queue managarů, např. z důvodů high availability, škálovatelnosti apod.

Koupil jsem si Kindle a musím říct, že za ten rok jsem četl, jak urvaný ze řetězu... 17 odborných knih! 🤦‍♂️

Jsem spokojeným majitelem čtečky Kindle. Jedna z věcí, co se mi líbí je, že všechny knihy koupené na Amazonu se automaticky přidají do (amazoního) cloudu. Odtud jsou potom k dispozici např. přes výbornou čtečku v prohlížeči Kindle Cloud Reader. Co se mi naopak nelíbí je, že Kindle (zatím) oficiálně nepodporuje formát ePub (a ani neumožňuje v cloudu umístit knihy koupené jinde, než na Amazonu).

Protože pár knih v ePubu mám a musel bych používat nějakou softwarovou čtečku, uvítal jsem, že je k dispozici také cloudová alternativa. Známé nakladatelství technologických knih O'Reilly (to jsou ty bílé knížky se zvířátkama) rozjelo Bookworm - cloudovou platformu pro online čtení ePub knih.Vyzkoušel jsem, používám a jsem více méně spokojen. Není to sice tak komfortní jako Kindle Cloud Reader a formátování textu není úplně excelentní, ale právě vzhledem ke "cloudovosti" jsem ochotný tyhle nedostatky překousnout.

Bookworm umožňuje upload (a download) vlastních  ePub knih. U rozečtené knihy si pamatuje poslední otevřenou kapitolu. Uživatelské rozhraní trochu připomíná Adobe Reader - vlevo menu s kapitolama, vpravo obsah (kapitoly). Co zatím nefunguje, je vyhledávání v knížkách, ale to by snad mělo být brzo zprovozněno - v helpu už je to popsáno. Co chybí úplně je psaní poznámek a zvýrazňování textu - vlastnost, kterou poměrně hodně využívám u technických knih (a hádejte - Kindle to má).

Občas se vám stane, že jako team leader vyfasujete nepřátelský tým. Inspiraci jak řešit tuto těžkou situaci možná najdete v knize The Five Dysfunctions of a Team. Krátká recenze + pár citátů.

Jak se připravit na UML certifikaci OCUP Intermediate? SoftWare Samuraj sdílí svoje tipy a triky.