Identifying and responding to issues faster with more frequent deploy cycles

Everything in IT has pros and cons, and as they say, ymmv. One of the things that has always interested me in IT is how your point of view, the lens through which you perceive ‘how things are done’, is always (and perhaps obviously) influenced by your current company/project/client/organizational experience.

If for example your current experience is (and perhaps has always been) traditional waterfall-type development lifecycle, then the very idea that it’s possible to build/test/deploy new functionality to production in anything less than 6 month release cycles, let alone daily, probably sounds like an impossibility.

However, if this is your experience (and to be honest most of my industry experience has been using more traditional methods), there is a light bulb moment when you realize what it means to be able to deploy to production in very frequent, short development cycles.

The faster/quicker you can deploy new features to production, the faster you can learn about what works and what doesn’t. If you find problems sooner, you can respond and fix issues sooner. Fixing problems sooner means problems don’t get out of control and grow into much larger problems that become more expensive and more difficult to fix later. Getting features in front of your users sooner give them the opportunity to provide feedback quicker, and either confirm that this is what they were expecting, or whether changes need to be made to get closer to exactly what it is that they are looking for.

Continuous Delivery is not a myth, there’s many organizations out there already successfully using techniques to deploy to production daily (Infoq.com have a great collection of presentations on their site).

Mark Little on Java EE and Microservices in 2016

Mark Little has an interesting article on InfoQ looking at what’s going on with Java EE and microservices. At the beginning of this year I looked at a number of Java frameworks that are emerging that support microservice development and deployment. What’s interesting is everyone has a slightly different take on what parts of the EE apis they would take with them, and/or how a Java based microservice should be packaged and deployed.

What I find interesting is there’s obviously a general agreement that there’s still parts of EE that are beneficial and useful for microservice development and deployment, but from a distance the activity in this space looks like vultures picking apart the carcass of Java EE.

While there’s still benefit for some to develop monolithic enterprise systems using Java EE and traditional app servers ‘in the traditional way’ as we have done for for the past 15 years or so, it’s interesting that microservices seems to be questioning the EE approach of all your apis in a bucket provided by a single app server. I rather like the JBoss Swarm approach of being able to pick the apis you want and just bundle/deploy a fat War with what you need. I wonder if there’s enough interest and/or momentum in this space that we might see EE (probably too late for EE8, but EE9?) start to embrace this different approach to building apps as many smaller, individual services, and directly offer support for microservices type approach in future EE versions?

Linux Mint Cinnamon upgrade 17.1 to 17.3 – Cinnamon crash with nvidia-304

I’ve been using Mint Cinnamon 17.1 as my main desktop OS, of all the Linux distros I’ve played with in the past couple of years, this is my favorite by far (in terms of simplicity of the Desktop Environment).

17.3 Rosa came out recently, so I hadn’t upgraded for a while, so updated via the menu link in the software package manager.

I realized from installing and configuring 17.1 before that I needed to use the older nvidia-304 graphics – I have an older HP mobo with nvidia 6150SE graphics on the motherboard, and the best driver seems to be nvidia-304.

The upgrade itself was without issue, but after rebooting and logging on, within a few sessions I got the message “Cinnamon just crashed. You are currently running in Fallback Mode” and various parts of the screen started not refreshing. At one point when I pressed Yes on the dialog, but that resulted in more corruption to the point where individual characters became scrambled and not readable.

Seems like others are having the same issue too:

From feedback from others, it seems 17.2 was the last stable version for them, so I reinstalled 17.2 from a dvd, completely wiping my / partition. Luckily my docs and everything else I needed to keep was on a separate /home partition, so this worked out for me.

Usually any issues with a distro are on the initial install. This is the first time I can think of that doing an upgrade had significant issues, so hopefully they can get it sorted.

Running AROS / Icaros Desktop on VirtualBox

I love to install and check out different operating systems. Installing on something like VirtualBox means you can install as a guest, play with it, and either continue to use it or delete the disk image, with no impact to your host OS. So here’s an unusual one to check out:

AROS is an open source implementation of the AmigaOS 3.1 apis, that runs on Intel and PowerPC cpus (Amigas were originally Motorola 68k based). It seems there’s a couple of different variations, the one I installed was Icaros Desktop, which comes with a live CD, which you can also install from.

One installed, it boots from a GRUB menu, and wow, does it boot quick, within a couple of seconds (running under VirtualBox on my i7 MacBook Pro). It boots so fast I might be tempted to install this as a bare metal install on an old PC and play around with it for a while. It also looks very pretty 🙂