Why I Don’t Use Postman

I do tutorials. Lots of them (check out my 2018 publications).

Sometimes the tutorial involves a REST or SOAP interface. And I get questions like, “Stevie baby, why you use SoapUI? Postman is so much nicer!”

First, I’ve used SoapUI for years, and I really like it (warts and all).

Second, it’s free and open source.

Finally, this:


I absolutely DESPISE sites that make me sign up for anything in order to use their products. When I run across stuff like this, it makes me want to grind my teeth.

Why Postman does this is not lost on me. Creating software is an expensive endeavor. I totally get it.

But, if I have another choice, I’ll exercise it rather than give these companies my email address (which almost immediately increases the already hefty amount of spam I get).

I’m not arguing for or against this type of signup-to-use-our-product shannanigans. I’m simply answering the question I was asked: why don’t I use Postman as a REST client?

Now you know.

What do you think? Leave me a comment. Thanks for reading!


Blockchain: Can this be done with a database?

Greetings, all! IBM Code recently published a blog post of mine of the same title as this post on the IBM Code Blog.

This is a good question. I mean, isn’t Blockchain just a new kind of database? Well, yes, and no. It’s a database in the sense that it is a data store. But it’s not like any traditional database I’ve ever worked with (and I’m talking about relational databases, mostly).

The first question to answer in this dialogue is: What is a “Database”? Once we answer that question we can get the discussion centered around the topic at hand, which is why Blockchain cannot be done with a database.

Then, we have to answer this question: What is the Blockchain, anyway? After all, if we don’t really know what we mean by “Blockchain” (not that we don’t; we just need to all get on the same page w/r/t to the term Blockchain) how can we really talk about what it is and is not?

As I explain in the IBM Code post, the attributes of blockchain that distinguish it from a traditional (relational) database are that it is:

  • Distributed across boundaries of trust
  • Visible to all participants
  • An immutable ledger
  • Always appended
  • A dis-intermediation enabler

That’s a lot, I know. So be sure to check out the full post on the IBM Code Blog.

Thanks for reading, and happy Blockchaining!

What? That’s a word.


IoT and the Smart Home, Series Overview

Hey everyone! Steve Perry here.

Do you like DIY projects? If so, make sure to check out my IoT Smart Home series at IBM developerWorks.

It is made up of three installments, which guide you through a DIY smart home project from start to finish.

Part 1 – Setup the hardware

In Part 1 I give you an overview of the project, including a complete parts list, and three videos that show you how to setup your Raspberry Pi 3, give you a quick tutorial of how to use a solderless breadboard, and how to setup the 433MHz receiver and transmitter modules on the breadboard.

Part 2 – Setup the software

In Part 2 I show you how to download, build, and use the software you’ll need to run on your Raspberry Pi to communicate with the Raspberry Pi, called WiringPi, and 433Utils,  how to use the WiringPi gpio utility, and show you how to capture the 433MHz encoding signals sent from the IoT device remote controls using a program you’ll build from 433Utils called RFSniffer.

Part 3 – Control the smart home

In Part 3 I show you how to setup your Watson IoT platform app that acts as the MQTT broker, how to build, test, and run the software that runs on the Raspberry Pi to control the smart home devices, and how to build and run the Android app that controls the system from your mobile phone.

Oh, there will be videos

Each part of the tutorial has three videos to let you see what I did to build the project, to help deepen your understanding of the technology, and to give you a jump start when you build the project for yourself.

In future posts, I’ll expand on each of these. I’m excited, and I hope you are too.

Get started with Part 1

To get started, check out Part 1, and order your parts. The entire project costs about 125USD, including the Raspberry Pi 3, and a 16GB micro SD flash drive. Not bad, IMO.

If you already have a Raspberry Pi 3 and 16GB (or larger) micro SD card, and want to get started, check out the video below, where I show you how to download and flash the Raspbian Stretch image onto the micro SD card and setup your Pi.

Thanks for reading!


2018 Publications

Here is what I’ve written in 2018. Hope you find something you like!

Looking for 2017 Publications? Click here.

Looking for pre-2017 Publications? Click here.

2017 Publications

Here is what I’ve written in 2017. Hope you find something you like!

Looking for publications earlier than 2017? Click here.

Naming Things is Hard

Good names are hard to come up with.

Some reasons we suck at naming:

  • We get in a hurry
  • Good names take careful thought
  • We are in a hurry

I see a theme.

Here are some rules of thumb I’ve found handy.

Don’t encrypt a variable name. For example, if you are tempted to call a “request id” hashValue because every request is assigned a unique hash, you have encrypted the meaning of the variable (and obfuscated it on top of that). Yeah, don’t do that.

Don’t make method names overly generic. For example, if you have a method that calculates the balance in an account, don’t call it “processAccount()“. Instead call it calculateBalance(). It’s much clearer what it does, and you’re less tempted to pollute it with other functionality that should be included elsewhere as you maintain and enhance the code (think of it as technical debt insurance).

Don’t abbreviate variable or method names. Ever. EVER. The abbreviation might make sense to you, today, as of this moment. But chances are six months from now, it will take you a second to figure out what the heck maxBalCalcd means (maximum calculated balance value? maximum balance calculation date? No, sorry, it’s “has the maximum calculated balance been reached”, thanks for playing). As sucky as we are at naming, we are even suckier at abbreviating those bad names. Your colleagues will thank you (okay, probably not, but it’s still a good idea).

Don’t play code golf with variable or method names. I’ve seen really smart developers use variables like e to hold the return value from a function call. And the description of the data does not even start with the letter e. But even if it did, it’s still a bad idea. It’s not obvious what it does, and just makes the code harder to read.

Do give something a name that exactly matches what it is does. If it’s a function or method, name it according to what it does (and if it’s name would be too long if you called it everything it does, then you need to refactor your design). If it’s a variable, name it according to the type of data it holds.

Do give loop variables simple names. Yes, this seems to fly in the face of what I’ve been saying, but I’m talking about throw-away variables that are used to loop through the items in a collection, for example. I like aa, bb, and cc. Some like i, j and k. But whatever you do, for god sakes, though, don’t call it loopVariable. That’s overkill.

Do use long names because they’re descriptive. I would much rather see a method called computeChecksumIfPossible() than compChksum().

Do learn the language of the business domain you’re writing code for, and name things accordingly. My favorite awful method name of all time: getAreaCode(). Looks innocent enough, right? Turns out the developer wanted the first three digits of the U.S. zip code. In the USA the term “area code” has a whole other meaning. I’m not making this up.

Hope you found these tips helpful. Please feel free to comment and add a few of your own.

Happy naming!


JUnit Jupiter Annotations, Chapter 2


In part 1 I introduced you to JUnit 5 annotations:

  • @DisplayName
  • @Test

In this chapter, I’ll show you two more annotations:

  • @Disabled
  • @Nested

With code examples for both, and a video where I write code using these annotations.

You can download the complete sample application from GitHub if you like.

Let’s get started!

The Class Under Test

Before diving into the meat of this, let me show you the class under test. It’s called Echo, and it’s very simple (so as not to get in the way of the lesson):

public class Echo {
  public String echo(String stringToEcho) {
    return stringToEcho;

  public Integer echo(Integer intToEcho) {
    return intToEcho;


The class is pretty simple: its contract stipulates that it echoes whatever is passed, unchanged.

In true Test-Driven Development (TDD) style, you’ll write the implementation after you write the unit tests.


@DisplayName("A disabled test")
void testNotRun() {
  // This method will not run

Use this annotation to tell the JUnit platform not to run this test method. Notice that the method is annotated with the @Test annotation. Normally, JUnit would execute this method at the appropriate point in the test lifecycle, but annotating the method with @Disabled tells JUnit not to run it.

Why not just remove the @Test annotation? It might be good for documentation purposes to leave it annotated with @Test so you know it was a test method, or maybe you just want to temporarily disable the method.


This is a super cool new feature of JUnit 5 that allows you to create nested (inner) classes that keep groups of tests together in the same main test class, but separate from the other test methods in that class.

In the case of the Echo class, both methods are called echo, so you need some way of distinguishing which echo overload you’re testing. You could do something like this:

public void testEcho_String() {

public void testEcho_Integer() {

And that would work just fine. But JUnit 5 and the Jupiter API give you the @Nested annotation. So let’s use it!

  public class StringEchoTest {

    public void testEcho() {

      classUnderTest = new Echo();

      String expectedString = "This is a test";

      assertAll("String version of echo() method",
          // equals() should match, 
          /// but that is not good enough
          () -> assertEquals(expectedString, 
          // hash codes should match, 
          /// but still not quite good enough
          () -> assertEquals(expectedString.hashCode(), 
          // This should do the trick
          () -> assertEquals(


  public class IntegerEchoTest {

    public void testEcho() {

      classUnderTest = new Echo();

      Integer expectedInteger = Integer.valueOf(238);

      assertAll("String version of echo() method",
          () -> assertEquals(expectedInteger, 
          () -> assertEquals(expectedInteger.hashCode(), 
          () -> assertEquals(


In the video below, I’ll go over these annotations in detail, and you can watch me explain the code as I write it.


In this article, I showed you some of the annotations from the JUnit Jupiter API you’re most likely to use. But there is a LOT more to JUnit than the Annotations.

Be sure to follow along with this series here on my blog, and the accompanying videos on my YouTube channel.

To learn more about the annotations provided by the JUnit Jupiter API visit the JUnit 5 User’s Guide.

Check out my IBM developerWorks JUnit 5 Tutorial Series:

Check out the first post in this series here.