react testing

I have to say that hardest part with react was to figure out testing. (testing components is easy with thousands examples). But how to test props, state vlaues, clicking events, helping functions,… There are many projects in github and almost all of them are without any tests.

I have put together small app, where you can find code with tests.

I have tested:
* components
* props values
* state values
* events on components like clicking,…
* functions

Frankly I haven’t seen any project where they would cover all of the above.

I am not gonna write step by step, just small info I am using Jest & Enzyme testing framework.

For details better check my code. Check for package.json for packages I am using and __tests__ folders for tests.

Here are:
* github link
* travis link
* link


node/react -> github -> travis -> sonar

When programming I like to keep my code as clean and automated as possible.

I like sonar (does analysis on your code and provide you output how many duplicate, code smells, unused variables,..)

I like node.js / react.js for its quick prototyping and agile and others advantages. So lastly I was looking if I can have setup where I could automate my infrastructure  code -> push to  VCS (github) -> CI (travis) -> code analysis (Sonar).

Here are steps what you need to do:

  • -> on project settings turn on “travis-ci” integration
    • -> project -> settings -> Integration & services -> Add Service -> Travis CI
  • -> make sure after code push code build is triggered
  • – get started
    • create token here (I used this token in travis – see above)
    • define your organisation here
  • project:

dist: trusty
sudo: required
organization: "czechsource"
- master
- develop
- oraclejdk8
- sonar-scanner
- '$HOME/.sonar/cache'
sonar.projectName=React.js blog

Make sure you define organization and token and use it in travis.

Github repo

travis info

sonarcloud info

Update: I am using git flow and find out that branches “develop” were not sent to sonar. Make sure you add them in .travis.yml as well as in files (marked them in bold)

Update2: there is another option using sonarqube-scanner-node project . (I am assuming your project is made by create-react-app by facebook)

  • yarn add sonarqube-scanner-node --dev
  • yarn test -- --coverage
  • package.json -> add in script section:  "sonarqube": "sonarqube-scanner-node"
  • from command line: yarn sonarqube -Dsonar.organization=chowanioksource -Dsonar.sources=src -Dsonar.projectKey=chowanioksource:reactBlog  -Dsonar.login=< token>


java 8 using jboss5

If you need to run your app on jboss5 and using jdk8  you will get error

3:53:10,693 ERROR [AbstractKernelController] Error installing to Instantiated: name=AttachmentStore state=Described
java.lang.IllegalArgumentException: Wrong arguments. new for target java.lang.reflect.Constructor expected=[] actual=[]
    at org.jboss.reflect.plugins.introspection.ReflectionUtils.handleErrors(
    at org.jboss.reflect.plugins.introspection.ReflectionUtils.newInstance(
    at org.jboss.reflect.plugins.introspection.ReflectConstructorInfoImpl.newInstance(


You need to modify “profile.xml” and add class=”” into paramater element

<bean name="AttachmentStore" class="org.jboss.system.server.profileservice.repository.AbstractAttachmentStore">
<parameter class="">
<inject bean="BootstrapProfileFactory" property="attachmentStoreRoot" />




Git house cleaning

I use *Git* for several years and there are tons of articles out there about how to create new branch, pull, fetch, merge, conflict resolve, etc…

I looked at how we are doing with branches on current project – holds over 1M of code lines and +10 years of its history – I was surprised that we had almost 2 000 branches (features, patches,….). We don’t follow the standard git flow (yeah I know we should, but some in our team thinks that for  current project it is better how we do it now).  So as you can see there are many branches which needs to be cleaned up and GIT helps a lot with that.

Some Git commands which are useful for cleanup:

Clean of local branches which has been deleted on remote server:

git fetch --prune

list of all branches (local & remote )

git branch --all

List branches which are merged to remote master:

git branch --all --merged origin/master

Result of above command can be deleted

Delete local branch:

git branch -d branch_name

Delete branch from remote “origin” :

git push origin --delete branch_name

Show list of branches which are not merged into remote master branch:

git branch --all --no-merged origin/master

Results from above command are not merged into master. You need to check whether those branches are new feature/patch branches (still in work in progress) or they were not merged because you feature/patch is not needed any more (absolete and can be deleted) or you simply forget to merged them into your master (which should not happen by using tools like “git flow”)

You can scripts to combine of commands together. Let’s say we want to see last commit day and author to find out whether branch is still under development or not.

for branch in `git branch -r --merged origin/master | egrep -v 'HEAD|master'`; do echo -e `git show --format="%ci %cr %an" $branch | head -n 1` \\t$branch; done | sort -r

Similarly you can create scripts, which deletes not used merged branches and many other things you need.

Running Docker on CentOS – accesing internet from docker

By default your docker can’t reach to internet only to get centOS.

running this command solves the problem:

sysctl net.ipv4.ip_forward=1

unable to find valid certification path to requested target

It is always preferred to use https instead of http (specially when using passwords and so on…)

We have switched our SonarQube (tool for Continuous Inspection of code quality) to use https for security reasons. Anyway I have noticed that Jenkins stop sending new quality codes to our sonar. When I have checked the logs I have seen this stacktrace:

Exception in thread "main" java.lang.IllegalStateException: Fail to request server version
	at org.sonar.runner.Bootstrapper.getServerVersion(
	at org.sonar.runner.Runner.checkSonarVersion(
	at org.sonar.runner.Runner.execute(
	at org.sonar.runner.Main.execute(
	at org.sonar.runner.Main.main(
Caused by: PKIX path building failed: unable to find valid certification path to requested target
	at org.sonar.runner.Bootstrapper.remoteContent(
	at org.sonar.runner.Bootstrapper.getServerVersion(
	... 4 more

So here you can see that Jenkins has problem to “handshake” ssl certificate.

follow these steps:


Search google – it originally was done in Sun, but you can find this program on google codes or somewhere else. You can even download binaries of this file.

Add Trusted Keystore

Run “” on server (where you run your https service). something like java InstallCert localhost:443 -> press “1”  when asked. It will add your “localhost” as a trusted keystore, and generate a file named “jssecacerts“.

[user@sonar ~]$ java InstallCert localhost:443
Loading KeyStore /usr/java/jdk1.6.0_37/jre/lib/security/cacerts...
Opening connection to localhost:443...
Starting SSL handshake..
Server sent 1 certificate(s):
1 Subject CN=Unknown, OU=Unknown, O=Vendavo, L=Unknown, ST=Czech republic, C=CZ
Enter certificate to add to trusted keystore or 'q' to quit: [1]
Added certificate to keystore 'jssecacerts' using alias 'localhost-1'

I have removed most of the parts but the main parts are here:

a) press 1 when assked – you agree to add certificate for this domain into keystore

b) it created jssecacerts file

Verify Trusted Keystore

Run same command again 🙂  (this is full export – removed hashed data)

[mchowaniok@sonar ~]$ java InstallCert
Loading KeyStore jssecacerts...
Opening connection to
Starting SSL handshake...
No errors, certificate is already trusted
Server sent 1 certificate(s):
1 Subject CN=Unknown, OU=Unknown, O=Vendavo, L=Unknown, ST=Czech republic, C=CZ
 Issuer CN=Unknown, OU=Unknown, O=Vendavo, L=Unknown, ST=Czech republic, C=CZ
Enter certificate to add to trusted keystore or 'q' to quit: [1]
KeyStore not changed

Copy jssecacerts

copy jssecacerts file into java/jre/lib/security folder (I had to done it under sudo )

[user@sonar ~]$ sudo cp jssecacerts /usr/java/default/jre/lib/security/


verify it 🙂   in my case, run Jenkins job and verify data are uploaded to Sonar.

What lessons to learn from Mount Blanc and diving as software architect

In my previous post about exceeding my limits I have mentioned 2 trips from several I did in 2013. I would like to share lessons I learnt specially for development. You will see that there is not much difference in mistakes in software development as well in mistakes in diving or reaching top of mountains.

Let’s share some problems we have encounter:

During descent from Mount Blanc we (group of 3 people) decided we are not going to be tight together anymore, as it give us more freedom and we don’t have wait on each other. On the way back one of my friend felt over the cliff and by miracle was lucky to not fall down in gulf. We can’t say same about his DLSr camera. We have lost our best pictures from ascent and top of Mount Blanc, anyway my friend is still with us enjoys life like never before.

During my so far most deep dive, we swum almost all time against current and we have spent more air than we thought. On the way up, we had to use  extra safety air bottles we left in case of emergency, because we run out of air in our bottles.

These things I don’t share with everyone usually, because instead of learning lessons from my mistakes it scares them to actually not do anything.

And how it connects with development ?

  • If possible do pair programming and TDD – best exercise can be learnt on coderetreat
  • Never ever in name of “freedom, not enough time, not enough budget,…” write code without tests –  tests are your safety “rope” which holds your code together and can saves you life
  • Always count on unexpected events  (have extra hours, budget, resource hidden which you can pull on when needed) – this is like having extra safety bottles with air in water
  • Did you notice that both situation happened after “reaching  goal”  on the way back ? – Finishing your software and putting into production is our main goal, but be ready to expect the “real” problems when real users starts using it
  • Good preparation is the key for success – be tough on yourself – think about the most worst cases and expect even worse situations

These are just few things – happy new year 2014 and be ready to exceed your limits in next coming year.