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 termBlockchain) 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:
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.
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.
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’tplay 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.
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:
I don’t know what has happened to Make Magazine over the years. When I received my first issue in 2004 I was very excited about the content, the projects (Mousebot!).
And this great editorial focus continued for years. Robots? Check. Circuit design? Check. Tesla coil? Van deGraff generator? Check. Check.
But something has happened in the past couple of years or so. The occasional article about “wearable blinking jewelry” (W.T.F?) has become the norm.
Back in the day, my Make subscription was a nice complement to my Nuts and Volts subscription (which has stayed true to its editorial focus since I’ve been a subscriber in 2005). Now, they are nothing alike.
O’Reilly, please cancel my subscription to Make. And good luck with wearable drone jewelry.
