Posts

Leiningen je buildovací a projektový nástroj pro Clojure, který se velmi silně inspiroval Javovským Mavenem. Jeho podtitulem je "automating Clojure projects without setting your hair on fire".

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ů.