[memo] hibernate's import.sql

There is a neat, heavily undocumented feature oh Hibernate - import.sql.

If Hibernate creates DB schema from scratch - "hibernate.hbm2ddl.auto" is set to either "create" or "create-drop", it will load "import.sql" file located in the root classpath. If Spring Boot is used, the property controlling the behaviour is "spring.jpa.hibernate.ddl-auto".

But why would anyone like to import some static data in a webapp? Well, for prototyping purposes for example. Or for "static" webapp mocking some external resources for integration testing. 

Continuous Integration for (non)hipsters

Continuous Integration? Soooo ooold, so ninetees. Not hot anymore, not trendy. Currently even Continuous Delivery sounds like something regular, typical, borig. Everybody does CI... or do they?

In order to answer this question, let's refer to the excellent article, published by Martin Fowler here. Headline states:

Continuous Integration is a software development practice where members of a team integrate their work frequently (...). Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

That's it.
Code (yes, this includes tests!)
Commit.
Pull/push (integrate).
Let something (a CI server for instance) run tests and confirm that everything is in order

Four easy steps. However, the devil is in the detail.

First of all, the steps should be executed at least once a day, preferably multiple times a day by each team member. This way, any integration issues will be discovered on the spot. If your team has a habit of keeping private branches for a long time, without source integration and pushes (triggering a full CI build), well, you're not doing CI! If you use feature branches, which are a good thing, keep them public, so that CI server can watch them during development time.

Second of all, tests are the cornerstone of CI. Usually not all tests are run during build - in order to make it faster, only quick, small unit ones. If project build isn't fast, developers won't build before pushing changes (we're all always super busy, aren't we?). Therefore all expensive tests - especially integration ones - should be left for CI server. It's a general rule for a bigger builds. This way if an issue fits into this 1% not covered by unit tests, it should be found by the end of the day. By the way it's really a good habit to have a blame mails enabled in the CI server. The name is a bit misleading - it's not about the blame, it's all about fixing broken build (or bad tests!) as soon as possible.

All of what was above can be found in the aforementioned Martin Fowler's article - in a more elaborate way. Yes, it's a quite old one, but still very, very relevant.

Hazelcast - CLI access

Ever wondered how to quickly take a peek into your Hazelcast structures, for example on a UAT / CIT environment? Look no further! :-) I've recently had a similar task. Debugging an issue on a test environment I reckoned it might be caused by a faulty data in the Hazelcast cluster. Fortunately we can use what comes with a Java application using Hazelcast (in a client mode) - class ClientTestApp.

First of all we're going to need two Hazelcast JARs (here - version 3.2.5):

• hazelcast-client-3.2.5.jar
• hazelcast-3.2.5.jar

Both JARs should be copied into empty directory, let's call it "lib" for this demo purposes. Next, a shell script used to run the test app needs to be created:


In order to have the client connect with your cluster, a configuration needs to be provided as well. The file needs to be named hazelcast-client.xml and reside in the same directory as the run.sh script. Sample content looks as follows:

After running the client, you should get a Hazelcast console able to query / manage the cluster. Full manual of the CLI is here: http://docs.hazelcast.org/docs/2.3/manual/html/ch17s09.html

Enjoy querying your data! 

GeeCon part two

A little late (almost two weeks!) but finally completed. Second day of GeeCon (https://www.geecon.org/). How was it? Continue reading to find out.

Improving Java EE with reactive - Ondrej Mihalyi

The presenter started with an outlook of what "reactive" in terms of a web application really means. The idea he focused on was that in order to improve the latency, execution of a request should not block - never, even on I/O. Also, in order to utilise the resources (CPU) as efficiently as possible, there should be ideally as many threads running as there are cores in the system. In a typical, J2EE based application, there goals are impossible to achieve, as each request is served completely by a separate thread which blocks if there is eg a dependent service or a DB call. There are however libraries that can help to make such application more "reactive". In his demo application ("cargo"), Ondrej showed how to use built-in Java 8 CompletableFuture or external RxJava (https://github.com/ReactiveX/RxJava) observables in order to avoid blocking the execution thread. He also mentioned (although he was short on time) that the UI part should be improved as well by using technologies like WebSockets or CDI events.
Whole presentation was quite good content-wise. It was nice to learn how a performance can be improved in an existing application by refactoring it to use some "reactive" stuff. The presenter could improve a bit on a technical side. Keeping an eye on the clock and minimising "live coding" favouring ready, refactored examples would make whole presentation better from reception point of view.

Reactive Spring - Josh Long 

START. DOT SPRING. DOT IO. I could write that this was the second "reactive" presentation, taking on the topic from new Spring library perspective. But no, this was not an ordinary presentation. This was a show. A Josh show. The topic itseflf is very interesting and the Spring implementations are interesting (and impressive) as well. Reactive versions of repositories (Mongo DB implementation here), Reactive Streams (Subscriber, Publisher, Processor) and Reactor (Flux, Mono) concepts, Web Sockets or Server Sent Events for publishing. They even have (in the upcoming release) a reactive, non-blocking security! I had however a strong impression that Josh would be able to make an interesting and involving presentation on any topic... even PHP ;-) Besides strong interest in the Spring reactive what took out of the presentation is - START. DOT SPRING. DOT IO! :-D

Microservices - stages of maturity - Jarosław Pałka / Jakub Marchwicki

The multi-threaded presentation run on two cores in parallel ;-) It was a mixed one - a bit about the main topic (microservices), a bit about a working in a tech organisation. The microservices-oriented part dealt a bit with such principles as being event-driven (publish, publish, publish!) and asynchronous, even in terms of application logging. Also, the Customer Driven Contracts for better APIs were mentioned. The message from the presenters here was that many of the microservices world ideas can be applied to the world of monoliths. The organisation-oriented part was, from my point of view, much more interesting. Jarek and Jakub said many things that may seem obvious, but need to be stated aloud from time to time, just to remind everyone about them. Amon others, the words of wisdom I remembered from the presentation were:
- legacy products - usually nobody to work with these, but usually these are the ones that bring MONEY!
- 3rd Newtonian law of management - if you push people, they will push back even harder
- ignoring the infrastructure is a wide road to failure
- developers should be assigned responsibilities, not roles
- during development focus should be on building a resilient system, not a perfect one
- in general, it's better to fix what's failing than on blaming others (famous "witch hunt")
- never ever do any manual changes on production - if you need to, your product is crap ;-)
Overall, I liked the presentation, especially that my work experience results in similar conclusions as voiced by Jarek and Jakub.

Consumer-Driven Contracts to enable API evolution - Marcin Grzejszczak

Consumer-Driven Contracts is the pattern to enable service evolution, as described by Martin Fowler (https://martinfowler.com/articles/consumerDrivenContracts.html). In his presentation Marcin focused on how CDC can be enabled for a web application using Spring project called Spring Cloud Contract (http://cloud.spring.io/spring-cloud-contract/spring-cloud-contract.html). The idea behind is quite simple - allow writing Contract on an API using a statically typed Groovy DSL, that can be later on automagically converted into stubs used for (client) intergration testing (in a most hyped microservices architecture ;) ). As an added bonus, the same tool will generate (server) acceptance tests out of the same Contracts.
To make long story short - easier decoupling of services for testing and less boilerplate code provided by one nice tool. I like that! :-)

To sum up - this year's edition of GeeCon was both entertaining and educational. I learned few new things, I met some friends from good old days, I ate some cookies. One of the most important aspects for me was an opportunity to see how different things are done in different companies. Having a broader overview is never a bad thing!

Testing with... Oracle XE

This is rather "infrastructure" than "testing" post.
Sometimes it happens that developer needs to tie his business logic with fixed database provider, just to obtain required functionality. In my case it was Oracle >= 10g and functionality was regular expression support (REGEX_LIKE, REGEXP_INSTR, REGEXP_SUBSTR, REGEX_REPLACE functions). Hence testing code has to refrain from using quick, agile DB backends (as HSQL) and setup something more heavyweight.
Those who happened to install/configure full-blown Oracle know how hard can this be. Fortunately Oracle came up with solution by releasing Oracle XE database. In Linux with dpkg installation is as easy as:

• get DEB package
  
• run dpkg -i package
  
• /etc/init.d/oracle-xe configure
  

And that's it! We have fully-functional Oracle DB in our own host :) Web UI, typically available under http://127.0.0.1:8100/apex/f let user log in as SYS and manage database just as using sqlplus.
There is however one caveat - when connecting via JDBC, user will very probably get stranfge exceptions with error code ORA-12519, meaning "TNS:no appropriate service handler found". Typical SQL exception is:

oracle xe Io exception:
Connection refused
(DESCRIPTION=(TMP=)(VSNNUM=169869568)(ERR=12519)
(ERROR_STACK=(ERROR=(CODE=12519)(EMFI=4))))

This is caused by a bug in how Oracle XE handles monitoring processes, Fix is pretty straightforward:

• execute: ALTER SYSTEM SET PROCESSES=150 SCOPE=SPFILE;
  
• stop db: /etc/init.d/oracle-xe stop
  
• start it again: /etc/init.d/oracle-xe start
  

Voila! Enjoy your integration testing with brand-new Oracle Express Edition.

Groovy!

Most of java devs have already heard about (not-so-new) JDK based dynamic language - Groovy. It's first announcement didn't make an impression on me, as it seemed to me as "one among many". I became interested in it only after presentation on GeeCON (site).
Especially I asked myself - maybe it can prove useful for testing ? Many agilers know that one of biggest obstacles in implementing TDD in company is that no one really wants to write tests - as it takes precious time. Groovy posses some interesting features which can make testing simpler - and faster! In my opinion, following ones are noteworthy:

• closures - passing block of logic code to always-required try catch finally (try-catch) block in IO operations is quite convenient (of course closures are far more potent); also "it" keyword for first argument to shorten closure declaration is one neat trick
  
• "spread dot" operator - no more for-each loops only to obtain one property value from a collection!
  
• safe navigation operator "?." (aka Elvis :) ), shortening few access lines into one
  
• additional helper methods, as findAll(), every(), any(), collect()
  

What I really like in Groovy testing idea is that it shortens TDD development time without sacrificing quality of the final product. Typically, overusing Groovy's shortening syntax in production code would be like shooting self in foot, as it would make code more error-prone and less maintainable. But this can't be applied to test code, as it serves different purpose and in fact could be, let's say, lesser quality that production one.
For those interested I really recommend short presentation about Groovy from GeeCON by Vaclav Pech. You can find it here

Automate your GUI for free! With Marathon

Some time ago I was struggling with automation of GUI testing. Problem wasn't typical. Regular flow involved loading our (web) service into external (Java) tool emulating real mobile device, browsing fixed set of pages and taking screenshots. Next those screens were examined for rendering defects.

Obviously, this was great target for automation. This seemed as a hard task, as external testing tool didn't have any API or interface to connect my custom code. As a surprise, I found great (and LGPL) tool - Marathon (http://www.marathontesting.com).

First of all, Marathon supports recording scripts (clicked in app GUI!) that could be saved and replayed. Of course this feature isn't perfect, as Java GUIs tends to use multiple frameworks and custom Swing components. But this can be easily fixed with Jython - main language of Marathon scripts. Integrating Java and Python, it enables user to write custom Java code executed within tested application's Virtual Machine. Wow! This gives developer almost unlimited possibilities. Injecting AWT events, emulating mouse clicks and activating isolated Swing components is easy and straight-forward. Still, without application's sources determining applicable components can be difficult. Thankfully, Marathon offers drop-in console that can be used to freeze application and review it's component tree.

To recap, usage of Marathon helped me reduce time necessary for taking service screenshots by 80%. Also, tool proved to be very potent - from automating GUI to testing Swing applications. As every free tool, it has some issues, but advantages of speeding up tedious tasks are very rewarding.

Simple & fast DB testing

Yes, you're right. This short post is about HSQL - powerful yet surprisingly simple to use, pure-Java RDBMS.
Developing db-related functionalities in Java has never been easier. Using Hibernate's features as on-the-fly schema generation developer can easily stick to changing requirements. But what about testing? Transferring data to and from DB could take considerable amount of time and usage of one, shared, remote db can change test conditions and therefore make results unpredictable.
Solution is straight forward - configure own, isolated DB for all the testing! In Java world there could be only one answer - Hypersonic SQL (HSQL). In simplest example, one could use embedded HSQL running in-memory database.
Only two things are needed to enjoy separated DB test environment:

• add HSQL to the test class path - using Maven2 it's as simple as adding dependency to project's POM:
  

  
        <dependency>
          <groupid>hsqldb</groupid>
          <artifactid>hsqldb</artifactid>
          <version>1.8.0.7</version>
          <scope>test</scope>
        </dependency>
  

  
  
• configure and start org.hsqldb.Server class.

The latter can be done by writing simple wrapping class:

public class HsqlBootstrap
  extends Thread{

  private Server server;
 
  public HsqlBootstrap() {
    super();
    server = new Server();
    server.setNoSystemExit(true);
  
    server.setDatabasePath(0, "mem");
    server.setDatabaseName(0, "testDb");
  }
 
  public void run() {
   
    server.start();
  }

  public void stopServer() {
    server.stop();
  }
}

There is of course need for configuring Hibernate to use our new, freshly created DB. Adequate properties could be found on various Hibernate-related sites and include using jdbc:hsqldb:mem:testDb connection string ;-)