New features in My Personal Kanban, Kanban Themes and new Card details dialog

I did spent some time adding new feature requested by my Wife. Links, in card details field, are now supported as real HTTP links, which could be opened. I did remodel slightly the Kanban Card dialog to support that.

The other new feature is the possibility of changing look of Kanban.  The feature comes with easy way of adding own styles.

You can get a copy of the software here:

The video bellow is a quick overview of the new features.

How to update My Personal Kanban with your own styles

  1. You need to create a css file with styles and copy it into: my-personal-kanban-folder/styles/themes/ folder.  Name doesn’t matter, however you will need to use this name in last step. The default-bright.css and default-dark.css can be used as a starting point for your own styles.
  2. Prepare image capture for the new style and place it in my-personal-kanban-folder/img/themes/ folder. It should be a jpg no bigger than 150px in width with the same name as the css file (you can see that there are default-bright.jpg and default-dark.jpg in that folder already).
  3. Last step is to open the themes.js file from my-personal-kanban-folder/scripts/ folder (it will have a funny name like 5ebce75f.themes.js ) and add entry for your new theme. Name is the property that will be displayed in the Drop down. css is the property that will be used to find the css and jpg file prepared in steps 1 and 2.

If you want me to make the style a permanent member of My Personal Kanban, just make a pull request on GitHub.


Automated software release in complex environments

Automating software release might seem like an impossible task in a complex environment. I would like to give you, my dear reader handy tips and tricks for achieving it.

breaking chain

Software journey

Either you know it or not, the piece of software that enables you to read this article went a long journey. It was invented, thought through, designed, developed, tested, fixed and then delivered to you. Software continues to evolve. New functionality is invented, designed, developed, tested, fixed and delivered to you again. This cycle happens over and over again. If it doesn’t the software is dead, and I wouldn’t use it if I were you J

Note the last cycle in the software journey: delivery. I like to call this process Software Release or Unleashing the Software. Release depends on many factors. One of them is software purpose. It is enough to make desktop application available (via web site download for example) so the user can get it and install it on a desktop. Web applications are delivered to a web server.

Release process

Software Release process could be simple or could be very complicated. Lets examine three examples:

  1. Desktop application release could involve copying (perhaps extracting) number of files into known location and perhaps making some changes to saved files (for example user files with configuration and settings in user directory).
  2. Web application release could involve pushing new version of the application to web servers, restarting them, migrating the data stored in database.
  3. Multi tiered enterprise applications could involve stopping a number of services, waiting for suitable services state (for example empty EMS service), migrating the data schemas (for example database migration), re-starting multiple applications, restoring application state, etc.

As you can see complexity of the process could be great. Some steps in the process could depend on another. Other steps could take great amount of time. Sometimes it is impossible to stop part of the application or a service for required release.

Whatever the problematic, time consuming and fragile steps of the release process are, you can be sure that sooner or later, someone will make a mistake during the release, causing downtime or even damage to a system.

That is why it is important to have automated release.

Automated release

My favorite form of automated release is One-Click-Deploy. A tool (script most likely) that will perform all the hard work, with a single user interaction.

Some of the benefits of release automation like this are:

  • Reduced mistakes when performing manual steps
  • No time wasted by a poor soul who have to go through manual process
  • Reusability and simplicity of using the same tool to release into different environments
  • A tool that verifies the release process itself (if something went wrong, it probably means that process needs updating)

Complex environments

Automating in complex environment is even more important then anywhere else. This is due to the fact that it is much simpler to make a mistake while releasing and cause problems. It also reduced the great amount of time consumed by manual steps.

It might be hard to automate release in complex systems. Consider the system I work on my current project.

Large distributed cache makes it difficult to stop the application, as data will be lost. EMS topics are read by database persistence application and fail-safe environment, so we need to wait for the topics to be read entirely. Once everything is stopped we need to roll the new code base to 20 – 40 physical hosts and apply all necessary configurations changes. Persistence layer needs to be migrated to represent Domain correctly. When we restart applications we need to reload it to the previous, valid state (load 300 GB worth of data into distributed cache). That is only a tip of the Iceberg that represents how difficult it could be to automate the release.

There are things that you can do or adopt on a project that would make it much easier for the automation to happen.

Tips and tricks

Tools and deployment environments

Use tools and deployment environments that have accessible API for management.

The environment or the containers that you deploy to should have open API for the management. If you are deploying into web server, you would like to be able to programmatically stop the server deploy new code, perform configuration changes, start it again and validate.

Most of the cloud services contain this kind of API. Typical Java Web containers are manageable via a public API.

If there is no public API but there is a web console for management it is possible to automate via typical Web Testing tool (eg: Selenium, Geb).

If you are starting the project and still have a chance to select appropriate environment, then you are lucky. You can make your life easier by selecting environment with public management API. If you are deep into the project and it is too late, there are always a ways to hack the system. Give it a try.

Use a tool that will be flexible and won’t enforce specific way of working.

Number of times I was on a project where the tool used for a release was enforcing a specific way of working. Instead of being productive in automating release process I was forced to fight it and hack it.

There are better things to automate your release with than XML.

If the tool doesn’t entirely do what you need, wrap it, enhance it or dump it in favor of other.

Many tools that are typically used for deployment are quite flexible and have build in mechanism for extending it. I found that writing a plugin or simply wrapping the tool in another process that controls it’s startup, makes it simpler to use and produces repeatable pattern.

If you are having more trouble with the tool itself or simply can’t get result required, don’t be afraid and dump it. There are always other tools. In a worse scenario you can write something simple and tailored for your specific needs.

Application design

Build your application in a way that will support state persistence and restoration.

It is not only the process and tools that you are creating or going to use that should support the automation; it should be the Application itself.

In the example of a complex environment I provided, I mentioned the distributed cache. If the cache is full of data, releasing new version of application could potentially cause the data to be lost. You need to think of a way to get it back to the previous state. The release process should accommodate for restoring the state from some king of storage (eg. Disk, database, replicated cluster, etc.).


Keep your configuration with your source code.

Having environment configurations collocated with the source code in the source version control system has number of benefits:

  • It could be unit tested.
  • Provides a history of configuration changes. It is always possible to revert to a previous configuration that was working.
  • Configuration lives close to developers, who usually know the most on subject of required configuration changes.
  • Configuration ships with the deployable.
  • It contains a name of a person that modified it, so whenever configuration changes are not clear you can always ask the person who made a change.

Automate every step.

Don’t leave a chance of error creeping into your process by allowing manual steps. It might take some extra effort to automate those simple, little steps but the award is saved time and reliably released software.

Make sure to have everything that application needs to live contained within the release.

Don’t leave anything out: extra libraries, additional software installed, new versions, etc. Ship it all as a part of the release. It doesn’t have to be collocated with a source code (however it is quite beneficial sometimes). Make sure it is accessible from every point you are deploying your software into.

Keep logs, summary and history of releases.

Having release log helps to track the progress of release, identify issues and even test the release itself.  It is also handy when release takes long time and nursing it needs to be handed over to another person.

Summary page helps quickly identify the version of the software released into environment.

Famous last words

I know that sometimes automation might seem impossible but I also believe that impossible doesn’t exist. There is only easy and less easy to do. Automate your release and make your and your comrades life more enjoyable.

Many happy automated releases.


When done is DONE (or not)

Not too long ago I had a conversation with one of the senior member of the management team of project I’m working on. I had some ideas on how can we do things faster by improving our testing (not developer testing but end-to-end, QA and regression testing). After few minutes of conversation I was asked a very basic question: “What is the definition of DONE on our project?” I was just going to open my mouth and jump out with an answer like: “Well, it takes us usually 3 days to develop piece of functionality”, but I stopped. I actually wasn’t sure. We spend few more minutes discussing some other issues but when I left I felt that this question is still on the back of my mind, trying to desperately find the answer.

After number of attempts I decided to rephrase the question. What is the Goal of the project? Couldn’t find a simple answer. So I asked even more general question. What is the goal of the company? I recalled books by Eliyahu M. Goldratt, “The Goal” and “The Race”. “The goal of the company is to make money in the present as well as in the future”. The goal is to win the race for customers.

My team works on creating and maintaining the software that produces the data for other systems within the company. Those systems are used to deal with clients, to provide them with reports, to sell them information, to protect client interests. This means that our project indirectly contributes towards company’s goal.

All the other teams and projects that are receiving data from us are our customers. We should make all the effort to deliver the necessary features to the consumers in a timely manner as they will be use to generate the revenue.

That’s it. This is my understanding of DONE.

In other words:

  • It’s NOT DONE when BA finalizes the requirements and forms them as stories that got accepted by all stakeholders
  • It’s NOT DONE when developer finishes coding the solution and fixes all the bugs
  • It’s NOT DONE when QAs, BAs finish testing and approve the deliverables
  • It’s NOT DONE when Downstream systems receive the data and confirm it’s quality
  • It’s DONE when client receives the service that he or she requested thanks to the piece of software my team delivered. That’s when it’s DONE!

I think there is an important aspect to touch on. It is the effort of the entire team before DONE could be announced. No one should silo himself into a specific role and take responsibility for the specified area only. Developers should help with delivery of tools for release and testing automation, BAs should help with testing, QAs should help to form requirements, etc.

So, next time when you think you’re DONE, think again. Perhaps you are not really there yet but you could help someone else to make it happen.

Wish you all many happy DONEs in the future. Greg

Design release process from very beginning

Creating good software that meets customer expectations is 50% of success. The other 50% is getting it to the customer in a most quick, easy and smooth matter as possible. This process is called releasing software.

breaking chain

Release flavours

Releasing software comes in two flavors, one is a clean slate installation, second is version/maintenance upgrade. Where first one is rather simple the latter could be quite problematic. The more complex the application and environment it runs in, the more problematic it’ll be.  Releasing software to running cluster of application servers with data migration and without downtime could prove challenging for the toughest release gurus.

I always thought of release in a same way I receive or send parcel. When I have something to sell I organize it online, Delivery Company comes to pick it up and it’s on its way. I can then track it online to see the progress my parcel is making.

It is exactly how I would like any release process to be. When my package (new version of software) is ready I would like to press the button and have it on its way. All I should do is monitor if something went wrong and what if it did.


Automation of the process is a must if one wants to remove wasted time on same repeatable steps. It is quite often automation that gets neglected from the beginning of software life, until the point when release becomes unmanageable manual monster.

Automation should actually be planned from the very beginning. Whenever I start to work on a project I ask myself what do I need to do to get the software to end user as quick as it’s ready with as less possible effort. This is the beginning of the release automation adventure.

Releasing often and quickly adds into the whole iterative development process, combining the whole as one iterative delivery. Process reduces time that takes for the requirement to reach end user as a piece of functionality. That makes end user happy and gives way to feedback. Software development team can use feedback to adapt and evolve the software.

So, what now?

It is important to design and implement release process from the beginning. It is also important to automate it. It will make it possible to ship as soon as piece of work is done. I know of teams where releasing is happening on a daily basis.

Automate every step that requires human interaction. Look for candidates in places where the only manual thing is pressing a button or running a script.

If release process requires monitoring (e.g. waiting for application to stop before continuing release process), try to automate that as well.

I also found that usage of tools that support coding the process, not configuring it via XML, works much better and are more flexible and easy to use.

Little creative fingers

We all have heard about creativity but did we ever take a moment to think about it for a while. What it really is or what it means? How to be better at it?


Definitions of creativity are actually rather simple. Wikipedia states that Creativity is the ability to improve, adding value. Google quotes Princeton University’s website saying that it’s “The ability to create”.

Creativity is a mental process, involving discovery of new ideas, or new view on the old ideas. The process is powered by our conscious and unconscious mind.

With today’s modern psychology and cognitive science, creativity is still rather unknown field. There are number of theories on the process, but all of them can’t explain it precisely.

Graham Wallas presented his theory about creative thinking in 1926. He is dividing creative process into following steps:

  1. Preparation – work on a problem that involves understanding it and exploring different views on it
  2. Incubation – where the problem is injected into unconscious mind
  3. Intimation – it happens when one get the feeling that idea is going to emerge soon
  4. Illumination – where the creative idea bursts into conscious mind
  5. Verification – when the idea is consciously verified, elaborated and applied

My own findings

I started with reading some book on the topic and browsing the Internet. Then I saw TED talk by creativity and innovation expert, Sir Ken Robinson. He inspired me to observe my 3 years old daughter when she was playing. They say that small persons mind is like a sponge. It soaks in all the new encounters.

Things I noticed

A lot of my daughter’s new toys emerged from an item of everyday use, used in a completely new way (laundry basket became a boat, toilet paper roll became a telescope, etc.). She has a great skill to take an item, turn it around, look at it from different angle and than decide what new toy it will be.

My daughter is very good girl and she is hardly ever destructive  (I only assume that boys are more talented in this area). She grabs things that are around her and puts them together. New creation is inspected and either accepted as new toy or discarded (sometimes put together in different way).

Kids have more simple/different way of looking at things. This is what makes them so creative. When “Little Prince” saw picture of a hat, he said it was a picture of giant snake that swallowed elephant (perhaps he was right).

Thinking about the way my daughter creates new toys I came to conclusion that creative adult thinking is very similar most of the times. We look at the things from a different angle, look at it upside down, take tools that we have never used to do different sometimes odd job (using shoe as a hammer).

Putting things together is less physical, more mental. It involves taking pieces of information, knowledge, experience, and combine them together to produce something new. A book, real life observations, notes and mind maps turned into this article.

Recall any music interview that you might hear. Musicians typically mention who is their inspiration. Normally they mention another musician/music style etc. You can recognize in their music, tunes from other musicians, same musical patterns, instruments, etc. This is being creative by combining all the bits together in a new way.

Creativity and software development

Above description of creative processes are sounding very familiar to what I’ve been doing everyday creating software. All my experience from working with other people, technical knowledge I have, domain knowledge I acquired and everything else I know influences the code that I write.

I found that knowledge of different languages and patterns that are present in those, helped me to bring new ideas, become more creative at what I was doing. C# experience helped me to introduce some new patterns to Java. Dynamic and functional languages gave different view on type safety and state. Tools that I typically used in one technology, gave new light to a better use of tools in other technology.

I also found that being brave enough to try new things, use of different tools, led me to a new discovery. For example, swapping build tool to brand new, helped defragment not fully automated release process.


Everyone can be creative however it doesn’t mean that it is simple. More information you have (including domain, technical knowledge and everyday life things) is helpful. More willing you are to try new and different things the better.

Try to stay open to information but be careful, as it is easy to get overflowed with it in the age of Internet. Be open to new things and listen to other’s ideas, don’t shut them down immediately.

Handfull of links (somehow references)



Evernote as blog software

From Evernote:

Evernote as blog software

I was looking for a good software to use as offline writing tool for my blog. Something in the line of the great Windows Live Writer. Unfortunately some good candidates for Mac were not free.

I’m using Evernote to store notes of different kinds for my ideas and research. Idea just popped into my head that I could use one of the Evernote’s notepads to create blog entries. Each note could be a separate entry.

Evernote has editor that enables me to style it. The only thing that is missing is the “Post to blog button”. gives a possibility to post by email though. I will give it a try now.

If you see this post it means that it was a success 🙂

If by any chance you are a Evernote developer or could influence the features, you might consider my simple idea.

Cheers, Greg

Edited after this line.

As you can see Evernote adds additional header. Pity as it could be such a great way of hacking Evernote and together 🙂