Posted on

Geek Reading for the Weekend

I have talked about human filters and my plan for digital curation. These items are the fruits of those ideas, the items I deemed worthy from my Google Reader feeds. These items are a combination of tech business news, development news and programming tools and techniques.

I hope you enjoy today’s items, and please participate in the discussions on those sites.

Posted on

Continuous Delivery != DevOps

Continuous Delivery and DevOps are interdependent, not equivalent

Since the publication of Dave Farley and Jez Humble’s seminal book on Continuous Delivery in 2010, its rise within the IT industry has been paralleled by the growth of the DevOps movement. While Continuous Delivery has an explicit goal of optimising for cycle time and an established set of principles and practices, DevOps is a more organic philosophy that is defined as “aligning development and operations roles and processes in the context of shared business objectives“, and gradually codifying into principles and practices. Continuous Delivery and DevOps possess a shared background in agile methods and Lean Thinking, and a shared desire to eliminate Waterscrumfall silos – but what is the nature of their relationship?

Posted on

Build Continuous Delivery In

Building Continuous Delivery into an organisation requires radical change

While Continuous Delivery has a well-defined value proposition and a seminal bookon how to implement a deployment pipeline, there is a dearth of information on how to transform an organisation for Continuous Delivery. Despite its culture-focussed principles and an adoption process described by Jez Humble as ”organisational-architecture-process not tools-code-infrastructure“, many Continuous Delivery initiatives fail to emphasise an organisational model in which software is always releasable. This contravenes Lean Thinking and the Deming 95/5 Rule – that 95% of problems are attributable to system faults, while only 5% are due to special causes of variation. Building an automated deployment pipeline can eliminate the 5% of special causes of variation in our value stream (e.g. release failures), but it cannot address the remaining 95% of problems caused by our organisation structure (e.g. wait times between silos). From this we can infer that:

Posted on

Appsec and Technical Debt

Technical debt is a fact of life for anyone working in software development: work that needs to be done to make the system cleaner and simpler and cheaper to run over the long term, but that the business doesn't know about or doesn't see as a priority. This is because technical debt is mostly hidden from the people that use the system: the system works ok, even if there are shortcuts in design that make the system harder for developers to understand and change than it should be; or code that’s hard to read or that has been copied too many times; maybe some bugs that the customers don’t know about and that the development team is betting they won’t have to fix; and the platform has fallen behind on patches.

It’s the same for most application security vulnerabilities. The system runs fine, customers can’t see anything wrong, but there’s something missing or not-quite-right under the hood, and bad things might happen if these problems aren't taken care of in time.

Posted on

Busting PermGen Myths

In my latest post I explained the reasons that can cause the java.lang.OutOfMemoryError: PermGen space crashes. Now it is time to talk about possible solutions to the problem. Or, more precisely, about what the Internet suggests for possible solutions. Unfortunately, I can only say that I felt my inner Jamie Hyneman from MythBusters awakening when going through the different "expert opinions" on the subject.

I googled for current common knowledge about ways to solve java.lang.OutOfMemoryError: PermGen space crashes and went through a couple dozen pages that seemed more appropriate in Google results. Fortunately, most of the suggestions have already been distilled into this topic of the very respected StackOverflow. As you can see, the topic is truly popular and has some quite highly voted answers. But the irony is that the whole topic contains exactly zero solutions I could recommend myself. 

Posted on

What Is a Monad? Basic Theory for a Java Developer

As you can guess from the title, the main topic of this article will be monads. I will try to dive deep in their structure and inner workings. With some help of Java Optional, I will try to describe all of this in a more detailed way. At the end of this article, I will implement a log monad — a type of a writer monad —and then describe the role of each major code fragment and provide a simple example of its usage.

Why Learn How Monads Work?

First of all, it is always good to have a basic understanding of how things that we use work. If you are a Java developer, you probably use monads without even knowing about it. It may surprise you, but two of the most commonly known Java 8 features are monad implementations, namely Stream and Optional. In addition, functional programming becomes more and more popular nowadays so it is possible that we will have more similar monadic structures. Then, this knowledge will be even more very valuable.

Let’s start with describing what a monad is – more or less accurately. In my opinion, the matter here is fairly straightforward.

Posted on

Thoughts of a Chronic Blamer

I didn't do it.

I have a long list of people I like to blame for the dysfunction I see in organizations. I blame Managers, Directors, CEOs, Testers, Salesmen, Recruiters, Architects, IT Engineers, Customers, Business Analysts, Help Desk, HR, Finance, Consultants, and Coaches.

I blame those with more experience and those just starting. I blame the courageous and the scared. I blame my friends, my foes, and my family. I blame those I understand and those I don’t. I am expert in everyone else’s problems.