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

Container Orchestration with Kubernetes, Part 4

Working with Kubernetes on your Computer (Minikube)

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

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

The Application

So now you’re finally ready to start using Kubernetes. The first step in deploying a containerized application is, well, the application. I’ve put together some demo JavaScript code that you’ll run as a Node.js application.

Open a Terminal window or command prompt, navigate to a location on your computer where you want the code to land and clone the code from GitHub.

git clone https://github.com/makotogo/developerWorks

Navigate to the kubernetes directory and take a look at the JavaScript code. This toy application doesn’t do anything serious, just outputs a message to the console. But it’s enough for our purposes here.

Now run the application in Node.

node k8sdemo.js

Open a browser and point it to http://localhost:8080 to see the message.

And there it is. Now that you have an application, it’s time to containerize it.

Containerize the application

Here’s how you use Docker to do that. Take a look at the Dockerfile:

FROM node:6.11.4
EXPOSE 8080
COPY k8sdemo.js .
CMD node k8sdemo.js

Use this Docker definition to containerize the application. But before we can do that we need to start minikube, and I’ll show you why in a minute.

Execute the minikube start command:

minikube start

The first time Minikube runs, it has to download the ISO image to run inside of VirtualBox, and may take a minute or two depending on the speed of your internet connection. Once the image has been downloaded, minikube will start.

Minikube runs inside VirtualBox in its own VM. We need to make sure that Docker uses the internal Docker registry on Minikube’s VM by executing this command:

eval $(minikube docker-env)

Otherwise Docker will use the local registry on your machine, which is not accessible from the VM where minikube is running.

Now, from the Terminal window, execute the docker build command:

docker build -t k8sdemo:v1 .

This will create the image with a name of k8sdemo and a tag of v1, and store it in the Docker registry on the minikube host VM. When deploying the image to Minikube, you’ll reference that tag explicitly.

From the Terminal window execute the kubectl run command:

kubectl run k8sdemo --image=k8sdemo:v1 --port=8080

And now the application is up and running in its own Pod.

Conclusion

In this post I showed you how to work with Kubernetes on your computer. You containerized a simple application, then deployed it to your local Kubernetes cluster.

In Part 5, I’ll show you how to manage an application running in a Kubernetes cluster using kubectl and the Kubernetes Web UI Dashboard.

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