Designing using Options

One of my favorite software development activities is designing: thinking of how to create components so they work together really gets me going. Today, I wanted to write a bit on the way I consider trade-offs in designs. In particular, I focus a lot on options.

• design
• architecture

Thoughts on REST style APIs

I’ve worked with RESTful APIs for much of my career; besides being pretty much unavoidable anyway, they’ve always had a warm place in my heart and I’m very interested in learning more about how to design them.

• REST

Ok, we’re doing iterations: are we agile now?

Despite their usefulness, teams sometimes use iterations incorrectly, decreasing their effectiveness. Here I describe a couple of patterns in which I’ve seen poor use of iterations.

The role of Media Types in REST

REST (Representational State Transfer) is an architectural style that I’ve grown very interested in over the years and try to use when developing webservices. What I like about REST is that, having been “reverse-engineered” from the Web architecture, it provides a guide on how to develop webs of services in an organic (meaning somewhat unplanned and low-friction) manner, as opposed to trying to design and control a large scale system’s evolution.

• REST

Thoughts on Hypermedia

One of the services maintained by my team on my current project exposes a RESTish API and a pub-sub mechanism for receiving notifications when a resource is modified. The service was originally created for a single consuming service, also under my team’s responsibility, but is expected to be consumed by new services in the not so distant future. This has caused some concern for me because, having been developed in parallel with the consuming service by the same team, the service is a poster-child for Conway’s Law:

• REST

CompletionStage and CompletableFuture tutorial

Just FYI, I’ve started working on (yet another) tutorial on Java’s CompletionStage and CompletableFuture, check it out!.

On Privacy

I’m currently reading Bruce Schneier’s book Data and Goliath, on which he argues that technology advances of recent years have sprouted unprecedented surveillance by both corporations and government and that these developments are highly detrimental to individual privacy.

Property-based testing

Property-based testing is a technique I’ve started using a couple of years ago, which is essentially a way of asserting a certain property of a piece of code that holds for a whole category of inputs. This is opposed to example based testing, which uses a finite and fixed set of data points.

When to do method call verification

Ironically, a few days after my post explaining why you shouldn’t write tests based on method call verification, I ended up finding a case where it’s not only useful but also the Right Thing To Do™.

• testing

Reducing tests based on method call verification

Out of today’s programming practices, testing is probably one of the few that is widely accepted. However, in my opinion, test code tends to be written with less care and, as a consequence, to rot much more quickly than application code. Something I see much more commonly than I would like to is method call verification in tests. Using Mockito in Java it looks like this:

• testing

Workshop material, Continuous Delivery style

These past couple of weeks, I’ve been preparing a workshop comprising a slide deck and some practice material. I have done this before but, this time, I also had to select and prepare the development environment for the trainees. Being the CD (Continuous Delivery) fanatic that I am, I started looking around for options for:

• continuous delivery

About Software Engineering

Every once in a while, I try to take a step back and analyze my profession, software engineering. I’ve been doing this over the last few weeks, the result of which is a three component model of software engineering.

Baseball

We’re engineers but sometimes it feels as if we’re baseball players: we don’t really hit home runs often, and when we do, we come up with weird reasons for why it happened.

Book Review: Continuous Delivery

In case you’ve been hiding under a rock for the past few years, Continuous Delivery is the practice of making software releasable at all times. It is the practice that allows companies like Facebook, Google and Amazon to release software often (many times per day or even hour or minute!) in a safe manner, which helps them keep ahead of their game.

Why I'm giving up Haskell

Over the last two years, I’ve been learning Haskell as my first functional language. Now, and despite my love for the language, I’m putting it on hold.

Sharing resources with Jenkins

I’ve recently been asked to design a system for managing the installation of a set of plugins in a server-side third-party application. The fundamental problem is simple: from a bunch of files in version control, I have to create and copy a bunch of files into a directory. The source files can potentially be edited by several people at the same time but any version control software should be able to handle it. It seems like a simple development scenario.

Kaizen

Kaizen is a synonym for continuous improvement. Although in Japanese (the word’s origin) it simply means improvement (according to Wikipedia, at least), it has grown into an expression meaning the never-ending search for perfection, for continually becoming just a little bit better.

Yup, ads

As you may have noticed, I now have ads on my website.

Not Invented Here

Not Invented Here (NIH) is a well-known expression for software developers and describes a general attitude which favors developing software in-house, rather than reusing or adapting existing tools. Today, I’ll try to list some pros and cons of this attitude, based on my opinions and experience so far.

Fragmented Team

It’s a well accepted fact that teamwork usually produces better outcomes than a single individual’s work. It’s easy to see why:

What is your core business?

What exactly is your company’s core business? While I certainly can’t answer that question for you, I’ve come across the mindset that a certain business is not part of the company’s core. As an example, someone might say that a restaurant is in the food business and that real estate is not a core part of the business.

Business Process Rot

As a developer, I’m very familiar with the concept of code rot. It’s a principle that draws a parallel with rotting food, which illustrates that code which is not maintained gradually falls into a state of decay and is rendered useless.

The Framework

Today, I’m writing about what I consider to be a common anti-pattern in the enterprise development world, which is The Framework™. Simply put, this pattern manifests itself as the existence of a company standard, internally developed framework or set of components which everyone must use.

The end of construction

One of the things that I enjoy the most in C++ (one of the few enjoyable things about it, really) is RAII. For those who don’t know, RAII (Resource Acquisition Is Initialization) is a pattern which uses object constructors and destructors to acquire and release resources. This, along with C++’s automatic management of stack allocated variables, allows one to reap the benefits of the language’s high performance and deterministic behavior while avoiding the classical C error of forgetting to free a dynamically allocated variable.

Suddenly, Iterable

I’ve had my first experience with Google Guava (the Java library) on the project I’m currently on. The library is a special kind of useful in that, instead of providing some really new features to Java, it is mostly a collection of utilities which fill some gaps in the language’s current API.

Programming is actually a lot of fun

During my vacations last month (which is part of the reason for not posting in a long time), I went to lunch with some friends of mine. During lunch, I told them that I’d probably be spending most of my time relaxing, reading and programming. They commented that I should get out more and not always be programming.

Continuing Android Development

Today I finally completed my first minimally complete Android app! It is a white noise machine.

Software engineering

I’ve had some doubts about my field of software engineering over the last few weeks, almost to the point where I had trouble working on anything. It started with some articles I read online about differences in programming languages which had really strong opinions on which languages were really bad. I thought about this for a while, then realized that this can be generalized to most activities related to software development, from design to implementation. It came as a hard wake up call: you have this idea that what you’re doing is scientific but then you realize that you’re unable to objectively justify your decisions.

Starting Android development

Ever since I got my first smartphone (which, by the way, is a Samsung Galaxy S which I still use), I’ve wanted to try my hand at doing some development on it and although I have some app ideas from time to time, I never really got into the mindset to really do it. Until now, as I have been spending some time in the last few days to learn about Android app development.

Tests don't make you agile, they keep you agile

Since I follow many programming blogs, I stumble on the subject of testing from time to time. And by testing, I mean automated testing. It’s not that I look down on manual testing but automated testing is the focus of this blog post. I think I’ve heard all kinds of opinions, from “testing won’t help you if you develop with care” to “testing is better than the wheel, fire and electricity combined”.

Hello world!

Hi!