Zobrazují se příspěvky se štítkembest practice. Zobrazit všechny příspěvky
Zobrazují se příspěvky se štítkembest practice. Zobrazit všechny příspěvky

pondělí 25. září 2017

Sémantický identifikátor entity

Na projektech korporátních i startapových jsem se setkal vždy s tím, že si servisní třídy mezi sebou vyměnují identifikátory entit.

Často je to např. Long, pokud je datovým podkladem SQL databáze ale setkávám se i se Stringem, když je entita ze vzdáleného systému volaného přes MQ, WebServices, Rest apod.

Problém pak nastává v tom, že se tyto identifikátory často pletou.

Například

public void updateTransaction(Long transactionId, 
                              Long userId, 
                              Long operatorId, 
                              Long clientId) {
 // ... do some nasty business logic
}

Není jasné, jestli userId je identifikátor entity User - nejspíš ano. A co operatorId? Je to taky z entity User? Obzvláště, když žádná entita Operator v doménovém modelu není. 


Co kdyby rozhraní vypadalo takto
public void updateTransaction(TransactionId transactionId, 
                              UserId userId, 
                              UserId operatorId, 
                              ClientId clientId) {
 // ... do some nasty business logic
}

Takto už je sématický význam parametrů jasnější. Co ale ve skutečnosti obsahuje třída UserId?
public final class UserId {
  private final Long value;
 
  private UserId(Long value) {
    this.value = value;
  }
 
  public Long getValue() {
    return value;
  }
 
  public static UserId of(Long value) {
    if (value==null) throw new IllegalArgumentException("Parameter 'value' can't be null.");  
    return new UserId(value); 
  }
 
  public static UserId of(String value) {
    if (value==null) throw new IllegalArgumentException("Parameter 'value' can't be null.");  
    return new UserId(Long.valueOf(value)); 
  }
}


Instance je immutable a je tedy thread-safe. Zároveň hlídá, že hodnota value je ne-null-ová. Může obsahovat tolik factory metod kolik je potřeba - v tomto případě umí instanciovat z Long a ze String. 

Co když používám Hibernate? Jak to mám namapovat? Můžeme nentitu nechat tak jak je - anotovanou nad attributy - pak Hibernate mapuje hodnoty přímo na atributy bez použití set a get metod.
  
@Entity
@Table(name = "COOL_USER")
public class User {
  @Id
  @GeneratedValue
  @Column(name = "USER_ID")
  private Long id;

  @Column(name = "FIRST_NAME")
  private String firstName;
   
  @Column(name = "LAST_NAME")
  private String lastName;

  public UserId getId() {
    return UserId.of(id);
  }

  public void setId(UserId id) {
    this.id = id.getId();
   }
    
    // other set get methods for firstName and lastName

}

Čitelnost servisního kódy je mnohem lepší a navíd kompilátor za vás dělá kontrolu, jestli jste parametry nepopletli. 

Myslím si, že podobný přístup by se dal použít i na jiné jednoduché datové typy - např. AccountNumber, BirthNumber, DateOfBirth místo String, String, Date. 

pondělí 21. listopadu 2016

Peníze v Javě


Tentokrát bych chtěl rozebrat možnosti a moje zkušenosti, jak v kódu nakládat s penězi.

Datový typ - BigDecimal


Pro ukládání částky je rozhodně nutné používat datový typ BigDecimal  Jedině ten zaručuje, že nebude docházet k nečekanému zaokrouhlování za desetinou čárkou. BigDecimal snese v podstatě libovolnou přesnost a velikost čísla. Rozhodně nepoužívejte datové typy typu Float nebo Double.

Setkal jsem se i s aplikací, kde částky byly uchovávány jako celé číslo. Pro zobrazení se pak musela desetinná čárka uměle posouvat, tak aby dávala obsahově smysl. Fungovalo to dobře, ale myslím, že už je to přežité. Použil bych tento přístup jen v programovacím jazyku, který nemá BigDecimal alternativu.

Třída BigDecimal je immutable, takže se s instancemi ve vícevláknovém běhu pracuje bezpečně. Poskytuje všechny základní operace jako je sčítání, násobení a zaokrouhlování.

Identifikace měny


Peníze jsou ale ve skutečnosti dvojicí částky a měny.  Třídu, která by ale skládala dohromady částku a měnu přímo v JDK nemáme. Pokud máte částku a víte že jde o nějaké peníze, ale nevíte v jaké měně, tak je to docela problém.

public class Product {
    private final Long productId;
    private final String name;
    private final BigDecimal price; // What currency is it ?

    public Product(final Long productId, 
                   final String name, 
                   final BigDecimal price) {

        this.productId = productId;
        this.name = name;
        this.price = price;
    }
    // geters …
}

Třídu pro měnu máme v Javě už od verze 1.4 -  Currency. Rozšířit entitu o další atribut by neměl být problém.

public class Product {
    private final Long productId;
    private final String name;
    private final BigDecimal price;
    private final Currency currency;

    public Product(final Long productId, 
                   final String name, 
                   final BigDecimal price, 
                   final Currency currency) {

        this.productId = productId;
        this.name = name;
        this.price = price;
        this.currency = currency;
    }

    // geters …
}

Pokud v jedné entitě máte více cen - např. prodejní, nákupní, apod. Duplikují se vám dvojice částka a měna a poměrně snadno při použití může dojít k tomu, že částky a měny poplete. Musíte také ohlídat, aby byla vždy zadaná celá dvojice. Pokud dovolíte zadat částku bez měny, opět je to problém.

Joda Money

Problém neexistence třídy pro peníze vyřešil Stephen Colebourne, mimochodem autor populární knihovny JodaTime. Naimplementoval knihovnou pod názvem Joda-Money. Ta obsahuje třídu jak pro měnu - CurrencyUnit tak pro magickou dvojici částka, měna - a to hned ve dvou různých třídách Money a BigMoney. 

Money je třída, která agreguje  dvojici částka (jako BigDecimal) a měna (jako CurrencyUnit). Navíc hlídá počet desetinných míst pro danou měnu. Třída BigMoney poskytuje vše co Money, ale nehlídá počet míst za desetinou čárkou pro danou měnu. To se hodí, pokud vám částky přicházejí ze zdroje, který nemáte úplně pod kontrolou. Konverze mezi oběma typy je samozřejmě přímočará.  Obě třídy jsou immutable, takže opět bezpečné pro práci ve vícevláknovém prostředí. 

Upravený příklad vypadá takto.

public class Product {
    private final Long productId;
    private final String name;
    private final Money price;
    
    public Product(final Long productId, 
                   final String name, 
                   final Money price) {

        this.productId = productId;
        this.name = name;
        this.price = price;
    }

    // geters ... 
}

Závěr

Pokud pracujete v rámci programu s penězi, doporučuji určitě zahrnout do projektu o jednu závislost navíc a důsledně používat datový typ Money resp. BigMoney, místo dvou nezávislých atributů pro částku a pro měnu. Předcházíte tak riziku, že atributy prohodíte. Navíc je kód mírně přehlednější. Líbí se mi i že místo obecného typu pro číslo použit naprosto konkrétní pro peníze.


čtvrtek 18. srpna 2016

Mockování emailové komunikace v integračních testech

Na projektu JdemeNaTo jsme narazili na problém, jak v selenium integračních testech pracovat s emaily.

Testovaná aplikace posílá emaily přes SMTP protokol. Test je pak musí přečíst a zpracovat. Samozřejmě, že email jako takový se nesmí dostat ven z integračního prostředí.

Poměrně dlouhou dobu jsme používali jednoduché řešení Dumbster. To spočívalo v tom, že si test vytvořil při svém spuštění mock SMTP server na dohodnutém portu, a test si pak přímo přečetl příchozí mail. Po skončení testu se port zase uzavřel.

Toto řešení jsme museli ale opustit v době, kdy máme celé integrační prostředí postavené na dockeru. Testy pouštíme stále pomocí mavenu na TeamCity proti testovanému serveru hostovaném v docker kontejneru. Každý docker kontejner má svoji ip adresu a namá ponětí o tom, kdo ho volá.

Hledali jsme vhodnou náhradu za Dumbster a našli jsme překvapivě robustní implementaci v javě GreenMail, který je určený právě pro testovací účely. Sympatická je i velká variabilita nasazení - poskytují docker image, tak i standalone aplikaci či jako war do Tomcatu. Na straně posílání mailů jsme nemuseli udělat žádnou úpravu. Na straně čtení jsme si napsali jednoduchou rutinu založenou na POP3 protokolu.

Pokud hledáte řešení, jak mockovat email server v interačních testech, mohu GreenMail určitě doporučit.

středa 12. listopadu 2014

SQL Performance Explained

Na konci října jsem vyrazil na Geecon, který se poprvé konal v Praze. Na jedné z přednášek o SQL prezentátor Lukas Eder doporučoval knížku SQL Performance Explained.

Protože se po večerech a víkendech snažím o zrychlování našeho systému JdemeNaTo, tak jsem zainvestoval €10 a začetl se.

Knížka detailně popisuje, jak funguje index a jaké jsou běžné chyby při používání. Příklady autor ukazuje hlavně na Oracle, ale alternativy i na jiných - např. moje oblíbená PostgreSQL.

Moc se mi líbí stručný a výstižný jazyk. Každá věta nese informaci. Nikde žádná zbytečná výplň.

Nové poznatky jsem ihned začal úspěšně aplikovat na naší databázi, která už není úplně malá (řádově miliony řádků).

Rozhodně doporučuji k prostudování a dokonce zvažuji, připlatit si za vytištěnou verzi.

sobota 12. dubna 2014

Spring configuration files - best practice

I prefer to configure spring with xml files. The question is, how they should be named and where should be located.

The official spring documentation do not provide any recommendation. Here are some with I advocate.

Name consistency

Start all files with the same prefix applicationConfig*.xml

E.g. applicationConfig-security.xml, applicationConfig-hibernate.xml, applicationConfig-quartz.xml etc.

File Location

  • JAR -> src/main/resources/META-INF/spring
  • WAR -> src/main/webapp/WEB-INF/spring

Do not use version number in schema reference

Instead of

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tx="http://www.springframework.org/schema/tx"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
        http://www.springframework.org/schema/tx
        http://www.springframework.org/schema/tx/spring-tx-3.0.xsd">
  ...
</beans> 

Use this

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tx="http://www.springframework.org/schema/tx"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/tx
        http://www.springframework.org/schema/tx/spring-tx.xsd">
  ...
</beans> 

Why?

Spring automatically use highest version available from maven dependencies. Upgrade to newer version of spring is much more easy.

středa 25. prosince 2013

Logování

Na projektech, kterých se účastním, se ještě dnes setkávám kódem, který považuje logování pomocí System.out za výborný nápad. Proto bych v tomto článku chtěl rozebrat, co považuji konci roku 2013 za nejlepší logovací řešení.


Přehled

V javě máme několik možností, jak logovat:
  1. System.out respektive System.err,
  2. java.util.logging (JUL),
  3. Jakarta (Apache) commons logging (JCL),
  4. log4j,
  5. slf4j a
  6. logback.

System.out resp. System.err

Tuto variantu používám jen při zkoušení izolovaných věcí a záměrně odřezávám nepotřebné závislosti. Funguje na všech verzí javy.

Hlavní důvody, proč nepoužívat System.out
  • Nelze konfiguračně vypnout na různých prostředích což má za následek výkonostní a bezpečnostní problémy a
  • nelze konfiguračně nastavit úroveň zpráv.

Java Util Logging (JUL)

Tato možnost již máme v JRE myslím od verze 1.5. Kupodivu jsem ji  na komerčních projektech ani v open-source projektech nepotkal. Podle mě se neujala, protože přišla tak trochu s křížkem po funuse. 


log4j

Tuto možnost jsem používal na SE i EE projektech před pěti a více lety. Nenarážel jsem na limity tohoto řešení a byl jsem s ním byl spokojen. Možnosti konfigurovatelnosti ale daleko zaostávají za jeho nástupcem - logback.  


Jakarta Commons Logging (JCL)

Toto řešení mělo za cíl unifikovat rozhraní mezi různými logovacími frameworky. Samo o sobě logování neřeší, jen posílá zprávy do konkrétních implentací - log4i, JUL.  Rozhraní je skutečně jednoduché a můj oblíbený spring framework je tímto api prolezlý skrz naskrz. Toto řešení bohužel sebou nese některé problémy, kvůli kterým bych toto řešení nedoporučoval. 


slf4j

Tato knihovna řeší stejný problém jako JCL - tedy unifikace rozhraní nad různými logovacími API. Nové komerční projekty i řada open-source projektů dnes používá právě toto api. Dnes ho používám na několika komerčních i sranda projektech k plné spokojenosti. 


logback

Autorem je tvůrce log4j i slf4j - Ceki Gülcü.
Důvody, proč přejí z log4j na logback sám sepsal v článku Logback: Reasons to Switch 

Mě osobně nejvíce oslovily dvě vlastnosti:
  1. podmíněná konfigurace, kterou používám pro nastavení úrovně logování v závislosti na prostředí. 
  2. SiftingAppender, který umožňuje logovat dle dynamického parametru, např zalogovaného uživatele.

Závěr

  • Nepoužívejte System.out resp. System.err
  • Používejte slf4j spolu s logback.