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:

WhyIDoNotUsePostman

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!

–jsp

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!

–jsp

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!

–jsp

JUnit Jupiter Annotations, Chapter 2

Overview

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.

@Disabled

@Test
@Disabled
@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.

@Nested

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:

@Test
public void testEcho_String() {
.
.
}

@Test
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!

 
  @Nested
  public class StringEchoTest {

    @Test
    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, 
                 classUnderTest.echo(expectedString)),
          // hash codes should match, 
          /// but still not quite good enough
          () -> assertEquals(expectedString.hashCode(), 
                 classUnderTest.echo(expectedString).hashCode()),
          // This should do the trick
          () -> assertEquals(
              System.identityHashCode(expectedString),
               System.identityHashCode(
                classUnderTest.echo(expectedString))));
    }

  }

  @Nested
  public class IntegerEchoTest {

    @Test
    public void testEcho() {

      classUnderTest = new Echo();

      Integer expectedInteger = Integer.valueOf(238);

      assertAll("String version of echo() method",
          () -> assertEquals(expectedInteger, 
                 classUnderTest.echo(expectedInteger)),
          () -> assertEquals(expectedInteger.hashCode(), 
                 classUnderTest.echo(expectedInteger).hashCode()),
          () -> assertEquals(
              System.identityHashCode(expectedInteger),
                System.identityHashCode(
                 classUnderTest.echo(expectedInteger))));
    }
  }

Video

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

Conclusion

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.

 

Hyperledger Composer – Refine and deploy your blockchain network

Blockchain is HOT

You can’t go many places these days without hearing about blockchain. It is a truly disruptive technology that will change the way people do business with each other. If you have wanted to learn more about Blockchain but think the barrier to entry is too high, I have good news: Hyperledger Composer. Yes, that’s the good news. Read on.

Wait, what the heck is Hyperledger Composer?

Hyperledger Composer is a set of tools that allows you to quickly build, test, and manage blockchain applications. One of several projects under the Hyperledger umbrella, Composer provides:

  • A Domain-Specific Language (DSL) called CTO that lets you model a blockchain network
  • A sandbox – called Playground – that lets you quickly prototype a blockchain application
  • A command line interface (CLI) for managing and interacting with blockchain applications
  • Security through the use of ACL-style permissions
  • Tools
  • Lots more!

Using Composer, you can quickly build, test, and then manage blockchain applications that run on the Hyperledger Fabric.

Composer lowers the bar to building Fabric applications. How? Composer provides a framework that includes many common features of production-quality blockchain applications like management and security. So you spend your time writing business logic, not infrastructure.

Now, before going any further, if you haven’t checked out Part 1 of this series, you should do that now.

How do I work with a real blockchain network?

In Part 1 of the tutorial series, I showed you about the CTO language, and how to model, deploy, and test a simple blockchain network application using Composer Playground.

Surely there’s more to it than that, right?

Of course. You’ll need tools in order to use Composer to work with real blockchain networks. Tools like:

  • Node.js
  • The Composer CLI
  • VSCode

What about unit testing your chaincode transactions? Composer has you covered. Through Cucumber steps written specifically for Composer, you can test every inch of your blockchain network (okay, maybe not every inch, but Cucumber is super-extensible).

How about a tutorial?

So, you’re convinced Composer is THE tool to use for building Hyperledger Fabric applications. Now what do you do? Sounds like you need a tutorial. Don’t worry, IBM developerWorks and I have you covered.

I’ve written a three part tutorial series on how to use Composer. When you’re finished with this tutorial series, you’ll be ready to build the next hot blockchain application. I talked about Part 1 of the series in a previous blog post. So be sure to check that out if you haven’t already.

In Part 2 of the series, called Hyperledger Composer Basics, Refine and deploy your blockchain network, available at IBM developerWorks, you’ll install the necessary tools to work with real Hyperledger Fabric applications running on your computer, including unit testing your chaincode using Cucumber. Part 2 is all about the development process for building blockchain applications. If you want to be a serious blockchain developer, you owe it to yourself to check it out.

How do I learn more?

Check out these links to learn more about Blockchain and Hyperledger Fabric and Composer:

Videos

Setup your Composer development environment:

Thanks for reading, and happy blockchaining!

–jsp

Hyperledger Composer – Model and test a blockchain network

Blockchain is HOT

You can’t go many places these days without hearing about blockchain. It is a truly disruptive technology that will change the way people do business with each other. If you have wanted to learn more about Blockchain but think the barrier to entry is too high, I have good news: Hyperledger Composer. Yes, that’s the good news. Read on.

What is Hyperledger Composer?

Hyperledger Composer is a set of tools that allows you to quickly build, test, and manage blockchain applications. One of several projects under the Hyperledger umbrella, Composer provides:

  • A Domain-Specific Language (DSL) called CTO that lets you model a blockchain network
  • A sandbox – called Playground – that lets you quickly prototype a blockchain application
  • A command line interface (CLI) for managing and interacting with blockchain applications
  • Security through the use of ACL-style permissions
  • Tools
  • Lots more!

Using Composer, you can quickly build, test, and then manage blockchain applications that run on the Hyperledger Fabric.

Composer lowers the bar to building Fabric applications. How? Composer provides a framework that includes many common features of production-quality blockchain applications like management and security. So you spend your time writing business logic, not infrastructure.

How about a tutorial?

So, you want to build a blockchain application, and Composer sounds like a good tool for getting you started. Now what do you do? Sounds like you need a tutorial. Don’t worry, IBM developerWorks and I have you covered.

I’ve written a three part tutorial series on how to use Composer. When you’re finished with this tutorial series, you’ll be ready to build the next hot blockchain application.

In Part 1 of the series, called Hyperledger Composer Basics, Model and test your blockchain network, available at IBM developerWorks, I tell you all about these features of Composer, and show you how to use them as you work with a perishable goods network. You’ll learn how to model a blockchain network’s features – such as assets, participants, and transactions – using the Composer CTO language, and you’ll see how to use the Composer Playground to quickly prototype and test the perishable goods network using an embedded Hyperledger Fabric instance that runs inside a Docker container.

How do I learn more?

Check out these links to learn more about Blockchain and Hyperledger Fabric and Composer:

Take a video tour of Composer Playground:

 

Model and test a blockchain network using Playground:

 

Thanks for reading, and happy blockchaining!

–jsp

Container Orchestration with Kubernetes, Part 5

Managing Kubernetes

Hey everybody! In this post, I’d like to talk about Container-centric infrastructure with Kubernetes. This is Part 5 of a series of posts on using installing and using Kubernetes.

If you missed Part 4 where I give you Install Kubernetes on your Computer (Minikube), make sure to check that out.

In this post I’ll show you two ways to manage your Kubernetes applications:

  • kubectl
  • Kubernetes Web UI Dashboard

The kubectl command

When Kubernetes starts a pod it’s isolated in its own network. So how do we interact with the application?

One way is through a proxy, which you can start in a separate terminal window. Start a new Terminal window and execute the kubectl proxy command.

kubectl proxy

By default the proxy uses port 8001, but you can specify a different port using the --port option.

kubectl proxy --port=8080

This starts the proxy using port 8080. Now you can connect to the cluster through port 8080 on your computer.

I’ve written a script to get the pod name and use it to access the application through the cluster’s REST interface. The script is called test-k8sdemo.sh and takes the port as an argument.

./test-k8sdemo.sh 8080

And there you see the output.

Now that we have an app up and running, let’s talk about how to manage it. You can use the kubectl command to get information about pods, deployments, and so on.

For example, you can show a listing of the deployments:

kubectl get deployments

Or of the pods:

kubectl get pods

You can even get detailed information about the pods:

kubectl describe pods

This produces a lot of output, but it’s valuable (if somewhat verbose) information.

Kubernetes Web UI Dashboard

Now I love the command line as much as anybody, but did you know that Kubernetes has a Web-based UI dashboard?

By default the Dashboard is not deployed. From the documentation, you can copy the command to create the deployment through the kubectl command:

kubectl create -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml

Paste the above command into the console to deploy it.

Make sure the proxy is running (I showed you how to do this in Part 4). Start the proxy in a separate Terminal window:

kubectl proxy --port=8001

Once the Dashboard is deployed you can access it from http://localhost:8001/ui.

You can see the same basic information as from the various kubectl commands, but in a UI. Here’s an example of what I see using Chrome:

Conclusion

Well, that’s it for this series. I hope you enjoyed it, and make sure to check out the video below that walks you through everything I covered in this blog series (it’s true what they say: a video is worth a thousand pictures!).

Want to know more?

If you want to learn more about Kubernetes, check out this post at IBM developerWorks: What is Kubernetes?

Be sure to check out the other posts in this series:

Check out this video at IBM developerWorks TV, where I show you everything I covered in Parts 1-5 of this series:

Introduction to Kubernetes:

Thanks for reading!

–jsp