DEV Community: scottshipp

What's so bad about four-week sprints?

scottshipp — Mon, 07 Nov 2022 22:19:25 +0000

I've worked in various software teams that use scrum for the past ten years. Some of these teams use two-week sprints and some use four-week sprints. Most software teams I've talked to implicitly believe that shorter sprints are a sign of health and scrum "maturity." Four-week-long sprints are for software teams that are still "children" at practicing scrum. The dominant belief is that those teams should get better one day and move to two-week sprints.

My personal experience, though, is that teams with two-week sprints carry over more work, experience higher deadline pressure from management, and, worst of all, spend a higher ratio of their time in sprint ceremonies rather than implementing and deploying code. Two-week sprints involve three long meetings (sprint demo, sprint retro, and sprint planning) every other week, which is twice as much time spent in meetings as those who only have those meetings every four weeks.

Finally, I have observed that the ability to deliver sprint commitments more directly depends on how much of a team's work is dependent on other teams as opposed to being independently deliverable. The larger driver of the ability for work to be "independently deliverable" is the overall organization of the engineering department. Teams that can complete their work independently are just inherently able to deliver smaller batches of work more often, and it has nothing to do with their scrum "maturity." So my takeaway is that engineering departments who have teams experiencing "trouble" with two-week sprints should probably re-org their teams, rather than flog the "you aren't agile enough" horse.

So, what do you think about sprint length?

What's so bad about four-week sprints?

How to write an effective email as a software engineer

scottshipp — Fri, 04 Nov 2022 21:57:10 +0000

Note: this article was originally published on LinkedIN

You may think most software engineers know how to write effective email but you'd be wrong. Email was invented by software engineers, but it is still a difficult tool to use to communicate technical content.

So what can software engineers do to write better email?

Provide one clear takeaway

The first rule of email is that each email should have one clear takeaway.

If this is the only takeaway you get from this article, then I've done a great job. (See what I did there?)

Before you sit down to write an email, think of a simple, clear, and short sentence that sums up the email. Does the reader need to take an action? Is there a vital piece of information that you need the reader to know? What is the one thing they need to take away when they get up and walk away from the screen? I learned this tip from a Harvard Business School book on business communication.

If you can't summarize in a single clear sentence what you want the reader to know or do as a result of reading the email, grab some tea or coffee while you think about it.

Put the takeaway in the subject line

When you have that one clear sentence straight in your head, come back and write it down in the subject line.

(Skip the recipient lines (to, cc, and bcc) at the top for now. You can enter recipients later after you're sure you have written an effective email.)

Now improve your subject. Remember that it will appear in the middle of a list of dozens of others, so you should make it great. With a great subject line, you can rest assured that if the recipient reads nothing else, they still get the message.

Consider that many people now read email on smartphones and tablets. This usually truncates most subject lines after four to seven words.

Subject line examples

Here are some example subject lines for technical email:

Please update: InternalLib 4.0 is now available
Last chance: Submit feedback on draft Go coding guidelines
Signup now if you want to teach a March brownbag session
New coffee blends now available in the breakroom

Aim for five sentences or less

What about the body? Is it a place to make further points than the one made in the subject line?

No.

The body of the email is for a few additional details about the subject only. Keep in mind that the reader probably has 40 other emails to read, besides meetings to attend and sprint commitments to deliver. They have made their valuable attention available to read your email, so make it count.

As a general rule of thumb, try to limit the body to less than five sentences. Five sentences is not an arbitrary number. There is actually a movement online to reduce email length. Visit http://five.sentenc.es/ to find out more.

An email's body should spur the reader to action. It should not cover other points outside the subject. If you need to convey another, separate message—even if it's related—send a separate email or link to a document after conveying the more important primary point.

This can be counter-intuitive. Once you have made your point in the subject line, you may feel that the other party should have as much context as possible. Resist this urge. If you absolutely feel that more context is necessary, attach a document or leave a link to a web page with that information instead.

But how do you choose what context someone needs immediately versus what can be linked? Especially considering that attached or linked content may never be opened by a busy recipient?

Providing context

In the case of an action-oriented email, consider if the recipient will need to make a decision in order to choose the right action, and give them the context they need to make that decision. For example:

From: Hamilton, Margaret <mhamilton@example.org>
Date: Monday, January 27, 2022 at 11:53 AM
To: Lovelace, Ada <alovelace@example.org>, Hopper, Grace <ghopper@example.org>
Subject: ACTION: Update log4j in your applications immediately

A critical vulnerability in the log4j library has been discovered. Please update to version 2.15.0 immediately.

- Link: How to find out if your application uses log4j
- Link: Log4Shell FAQ
- Link: Security team support page

Thanks,

Margaret

Here, the action is clearly expressed in the subject. The first two lines of the email provide context for that action including why its necessary and what version to use in the update. The following three bullets are all links to further context some recipients may need in order to perform the action.

The non-email option

If you are struggling with communicating a single, clear point in an email, then maybe you need an alternate form of communication:

A meeting
A Gitter room or Slack channel
A pull request
A shared document with commenting turned on
A JIRA story

Use your imagination and your available resources.

Your email may turn into a short invitation to comment on a document, review a PR, or attend a meeting instead.

Replies

If you haven't seen it, a great guideline for replies is the following, from www.five.sentenc.es:

Treat all email responses like SMS text messages, using a set number of letters per response. Since it’s too hard to count letters, we count sentences instead.

www.five.sentenc.es is a personal policy that all email responses regardless of recipient or subject will be five sentences or less. It’s that simple.

Email Debates

It often happens that programmers engage in email debates. Because of the discussion list culture among developers, there is a tendency for even short emails to turn into long email chains. Unless you actually are on a mailing list whose purpose is to have longer discussions, this is a faux pas.

It can be hard for any developer to resist a debate, particularly when someone has said something incorrect, or something inflammatory, about their favorite language or framework. But this is the chance to go with the better, non-email option.

Here is an example email for those times when the debate is too big for email.

From: Lovelace, Ada <alovelace@example.org>
Date: Monday, January 24, 2022 at 8:53 AM
To: Hamilton, Margaret <mhamilton@example.org>, 
Hopper, Grace <ghopper@example.org>
Subject: Re: Proposed HTTP client library 

Hi everyone,

Can we move this discussion to the Gitter room instead? 
It seems clear that we need to incorporate these points into 
the decision and the Gitter room is where we're getting 
everyone's feedback on it. Besides, a number of people who 
should be involved aren't on this email thread.

Thanks,

Ada

Furthermore, this is another reason not to include more than a single point in your email. If your email covers multiple, separate points, you will end up with a reply thread that is going off in all directions. And that means no one is getting any of it.

Don't send it yet

Done? Great! Now revise. Maybe even get a second pair of eyes on it. You should spend as much time revising it as you spent writing it, maybe even more. You only have one chance to get it right!

Mark Twain famously remarked, "...if I had more time, I would have written a shorter letter." Long emails actually communicate less than short emails.

Send it!

You've taken into account all of the above advice. You feel your email is perfect. It's going to get the right message across and do so effectively. Add your recipients, click send, and sit back knowing that you cut through the noise.

Toxic tech interviews still rampant

scottshipp — Tue, 05 Apr 2022 16:48:43 +0000

Photo by Tima Miroshnichenko from Pexels

A tweet that is burning up my timeline today:

// Detect dark theme var iframe = document.getElementById('tweet-1511061905158377476-774'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1511061905158377476&theme=dark" }

If that seems outrageous, wait until you read the avalanche of similar experiences in the thread's replies.

Why is this so common, still, in 2022? The tech industry has always enabled jerks and it hasn't changed despite frequent calls for reform over the years. I have collected a folder full of bookmarks about similar issues for over a decade, and, yet, it doesn't seem to end.

Almost as stark as the calls for our industry to do better, are the "Top 10" articles about how you might be a bad programmer, which neglect to mention any human relationship skills at all, such as Signs that you're a bad programmer.

It's rare to find an essay that pushes back on technical skills in favor of "soft skills" like Austin Tindle's You need better programmers.

I don't know how engineering managers and directors aren't fighting this invasive problem more. People shouldn't be in senior-and-above roles in engineering orgs if they are asshats. No one should have to write an article like Tricks for Dealing with Toxic Colleagues but, in fact, we have many of them.

About interviews: the format of the typical tech interview itself sets up a power dynamic that is not productive. Not productive at all. If hiring is the goal, why is it that we put people in the stressful, alienating position of going into a strange room with no windows, that they've never been in, and then send a series of pairs of people in to grill them with questions and problems that don't even resemble the day-to-day work for a person in that position?

Something needs to change.

Dear tech industry: Do Better.

Estimation is not impossible

scottshipp — Wed, 23 Mar 2022 15:19:39 +0000

We've all heard someone say something like:

Estimation is impossible.

What's the point in estimating?

Every estimate is just a SWAG.

One of my early experiences as a professional software developer was when a project manager brought me aside and told me that the way to make estimates was by the following process:

Write down how long you think it will take. Example: Two weeks.
Double it. Example: Four weeks.
Increase the unit. Example: Four months.

What is estimation?

If all of these things are true, what even is estimation? I think this unanswered question is core to the myth of "estimation is impossible." Whenever I am in a conversation about estimation, I always come away with the strong sense that everyone is talking about different things. One person says estimation is possible because their company delivers to deadlines all the time, proving so. Another person is adamant that developers can't make estimates because too much is outside of their control or even outside of their knowledge. A third will say that software is an amorphous intangible abstraction so you can't estimate it.

None of these people defined estimation. Is it a deadline (a date) when something is delivered? Does estimation inherently involve knowing exactly what that something is? Is estimation inclusive of how many people, how much money, and for how long a company will work on one "thing?"

Estimation techniques

Besides the lack of clarity, there's another problem I find in these conversations. They only involve the following estimation technique:

Sit down and stare at the wall for awhile, then write down how long you think it will take to deliver the functionality in question.

At best, people discuss "planning poker" or having a conversation among the entire team about the delivery of a feature. Besides just arbitrarily throwing out numbers, this is the only game in town.

Learning to estimate

Did you know that the average developer tenure of tech companies is less than 2 years?

I bet if you think of all the people you've ever worked with, the colleague who made the most accurate estimates was either someone who had worked at your company for a long time or someone who worked in the same general industry (maybe e-commerce or SaaS).

This suggests that you can learn to estimate.

It also suggests why no one knows how to estimate.

So how do you?

Steve McConnell, the author of Code Complete, also wrote an oft-ignored book called Software Estimation: Demystifying the Black Art. It tells you exactly how to make good estimates. It defines what estimation is. It gives you more techniques than throwing numbers out. And it boils down to this: every organization can learn to estimate, if they actually kept data on their projects.

McConnell writes the following:

The most important reason to use historical data from your own organization is that it improves estimation accuracy. The use of historical data, or “documented facts,” is negatively correlated with cost and schedule overruns—that is, projects that have been estimated using historical data tend not to have overruns (Lederer and Prasad 1992).

My bet is that no one reading this article has ever worked in an organization that has historical project data from their own organization at hand when they make estimates. I make this bet confidently based on my own experience at six large companies as well as the numerous conversations I've had with software professionals from dozens of other companies including Amazon, Microsoft, and Google.

It sounds shocking that companies have ignored this simple practice, but they have.

Ending on a low note

If you would like to make better estimates, I highly recommend reading McConnell's book, because it will help. Using even the simplest tools that McConnell covers like work-breakdown structures will improve your estimates.

On the other hand, I have bad news. Since you're not likely to work in an organization that collects project data and makes it available to everyone, accurate estimation is effectively impossible, even if it is emphatically not impossible.

I wish you the best of luck.

Web Services 101: Why x00 status codes are so generic

scottshipp — Fri, 14 Jan 2022 00:05:10 +0000

Photo by picjumbo.com from Pexels

Quick intro to HTTP status codes

HTTP status codes are sent in every HTTP response to indicate the result of servicing the request.

They are arranged into categories by 100's, as follows:

Code range	Meaning
200-299	Success
300-399	Redirection
400-499	Client error
500-599	Server error

A useful reference to bookmark is https://httpstatuses.com.

x00 status codes

Now let's look closer at the definition of each x00 status code.

Code	Meaning
200	OK
300	Multiple Choices
400	Bad Request
500	Internal Server Error

Why do you think these are so generic like "Bad Request," "OK," or the even more vague "Multiple Choices?"

Explanation

The vagueness is on purpose. These codes are supposed to cover all possibilities. The HTTP specification describes them as the "stand in" codes for those situations where a custom HTTP status code has been defined by the service, and the client needs to interpret the response anyway.

HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class...

RFC2616

Conclusion

So we can conclude two things.

First: we can create our own custom HTTP status codes. Maybe we want to pick the unused status code 442 and define it as "<SomeProperty> is required." That's totally fine.

Second: we can also conclude that our clients will interpret our custom HTTP status codes as their x00 counterpart. For the given example of 442, clients will assume this is equivalent to 400 "Bad Request."

IntelliJ Hacks: Copy paste history and plain text paste

scottshipp — Wed, 22 Dec 2021 22:25:43 +0000

In our previous articles, we covered various IntelliJ features that you may not know about the first year that you use IntelliJ.

Today's hack is one that I definitely wasn't aware of for quite some time after starting to regularly use IntelliJ, and that's the copy/paste history and plain-text paste option. IntelliJ calls this feature Choose content to paste.

The Hack

To access this feature, simply hold Shift while you press either Ctrl + V (Linux and Windows) or Cmd + V (Mac). This will display a dialog that allows you to choose any prior copied text to paste. It also gives you the option to paste as plain text!

Final tip

Don't forget that you will find many gems like this in IntelliJ IDEA by going to the help menu and selecting "Keyboard Shortcuts PDF" which gives you a nice cheat sheet of IntelliJ keyboard shortcuts!

Awesome!

Introducing todos in noted cli v0.0.3

scottshipp — Wed, 15 Dec 2021 15:13:37 +0000

If you're new to noted, there's a great introduction here:

An amazing note-taking system with Markdown and Git, Part 1

scottshipp ・ Oct 19 '21

#productivity #programming #learning

Introducing the `todos` subcommand!

Version 0.0.3 of the noted cli is out now, and introduces a new subcommand, todos.

The todos command lists your todos.

$ noted todos
/Users/jsmith/Documenents/notes/2021-12-06:todo Send out Christmas cards
/Users/jsmith/Documenents/notes/2021-12-08:todo Read Termination Shock, Jane recommended it
/Users/jsmith/Documenents/notes/2021-12-15:todo Pick up milk

You can also configure any text string as a marker for todo notes. You can set the text string that is used in your .notedconfig file with the NOTED_TODO_MARKER variable.

For example, I've set my personal marker to this emoji: ✳️.

You can read more about it in the todo subcommand reference.

Speaking of which, the documentation has been improved, so take a peek at the README file.

I'm reminded that v0.0.2 has a grep subcommand too, which I forgot to post on here. You can learn more about that in the docs.

Build a next-level RESTful web service with Spring Boot

scottshipp — Wed, 08 Dec 2021 15:36:15 +0000

The easiest way to learn how to use Spring Boot is hands-on with the Building a RESTful Web Service in Spring Boot Quickstart found on the Spring Boot web site.

In this post, we build on top of the result in order to take it to the next level!

So before you continue, please go through the Quickstart and then come back to here.

Building the next level

At this point you have a Spring Boot-based RESTful web service running on your machine. You can visit http://localhost:8080/greeting and you will see:

{"id":2,"content":"Hello, World!"}

You can also visit http://localhost:8080/greeting?name=User and you will see:

{"id":3,"content":"Hello, User!"}

Now, wouldn’t it be nice to be able to change the greeting? Instead of, “Hello, User!” what if it could say something like any of these examples:

Greetings, User!
Welcome, User!
Good Afternoon, User!

Adding a PUT

In order to change the greeting, we will use the PUT HTTP verb. It’s important to use the right verb when making RESTful web services, and PUT is typically what is used to update an existing resource. Since we can GET the /greeting resource right now, changing it will be an update rather than a create, and PUT is what we should use.

The PUT cannot be made easily with a web browser. Instead we will use the useful cURL command-line utility. Here is the cURL command that we can use. This can be executed within a terminal window.

$ curl -X PUT -d template='Welcome' localhost:8080/greeting

Of course, this won’t work yet! But we will make it work in a moment below.

First, let me quickly explain, what the curl will do:

We start by calling curl
We pass “-X PUT” to tell it to make a put command
We pass “-d template=’Welcome'” in order to pass the “data” for the PUT command, and the data we pass is the new template String, passed as a key value pair.
Finally we supply the resource, “localhost:8080/greeting”

Preparing the existing code

Right now the existing GreetingController.java in the project only has a “GetMapping.” As you may have guessed, we will add a “PutMapping.” Since both will use the underlying logic to construct a “Greeting” and return it, we should do a slight refactor before adding the PutMapping. The refactor accomplishes the following:

Change the method that is currently annotated with the GetMapping to call a separate private method to get the result.
Change the template variable in the class to be a member of the class that can be changed, by removing the final keyword.
Also, let’s stop using String.format because it will be confusing for people using our service to have to use Java-specific String formatting. Besides, the “%” symbol that is used will be confusing at best and a problem at worst since it is used in URIs to mean something else. So refactor the new private method to just use normal Java String concatenation. This way the “template” can be one of our previously mentioned options like “Welcome” or “Greeting” and the rest of the greeting can be constructed from the supplied name.

We end up with the following class:

package com.scottshipp.code.restservice;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

import java.util.concurrent.atomic.AtomicLong;

@RestController
public class GreetingController {
    private static String template = "Hello";
    private final AtomicLong counter = new AtomicLong();

    @GetMapping("/greeting")
    public Greeting greeting(@RequestParam(value = "name", defaultValue = "World") String name) {
        return customizeGreeting(name);
    }

    private Greeting customizeGreeting(String name) {
        return new Greeting(counter.incrementAndGet(), template + ", " + name);
    }
}

Once you’ve made that refactor, it’s a good idea to pause at this point, rebuild the project, run it, and test it to see if it still performs the desired functionality. You can follow the section titled “Test the service” in the original tutorial to test this. When you are done, stop the service.

Adding a PUT mapping

Next, we will add a new method that sets a new value for the template variable.

    private Greeting customizeGreeting(String template, String name) {
        return new Greeting(counter.incrementAndGet(), template + ", " + name);
    }

Since this duplicates the existing method somewhat, we can refer to the new method but preserve the existing behavior:

    private Greeting customizeGreeting(String name) {
        return customizeGreeting("Hello", name);
    }

Now we just need a method to handle a PUT request. It iwll be annotated with “@PutMapping.” The new method looks like this:

@PutMapping
public ResponseEntity<Greeting> update(String template) {
  return customizeGreeting(template, "World");
}

Simply by annotating this method with “@PutMapping(“/greeting”)” will now allow your web service to accept a PUT request at that URI. Because the variable the method takes is a String called “template,” the curl command we issue will pass data in the “-d” flag with the key name “template.”

After you’ve added the above method to your controller class, it should now look like this new full class:

package com.scottshipp.code.restservice;

import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PutMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

import java.util.concurrent.atomic.AtomicLong;

@RestController
@RequestMapping("/greeting")
public class GreetingController {
    private static String template = "Hello";
    private final AtomicLong counter = new AtomicLong();

    @GetMapping
    public Greeting greeting(@RequestParam(value = "name", defaultValue = "World") String name) {
        return customizeGreeting(name);
    }

    @PutMapping
    public ResponseEntity<Greeting> update(String template) {
        return customizeGreeting(template, "World");
    }

    private Greeting customizeGreeting(String name) {
        return customizeGreeting("Hello", name);
    }

    private Greeting customizeGreeting(String template, String name) {
        return new Greeting(counter.incrementAndGet(), template + ", " + name);
    }
}

Test the service

Now run the service according to the Test the service section of the original tutorial. While the service is running, issue the curl command in a separate terminal:

$ curl -X PUT -d template='Greetings' localhost:8080/greeting

You should see the same response you would have seen with a GET request, only now using the new template:

{"id":1,"content":"Greetings, World"}

When you issue any subsequent GET requests, you will find that the greeting will use the new template.

$ curl localhost:8080/greeting?name=Earthlings

{"id":2,"content":"Greetings, Earthlings"}

Congratulations

Congratulations! You just took your RESTful web service building skills in Spring Boot to the next level! Consider trying to add another HTTP verb like POST to your controller.

Java Pitfalls: Misuse of types

scottshipp — Tue, 07 Dec 2021 20:25:46 +0000

Photo by Gratisography from Pexels

Java is a great language but it can really bite you if you don't watch out! Here's the second installment of a series of helpful things to watch out for in Java!

😰 Today's Pitfall

Today's pitfall is misusing types. It includes a variety of poor coding practices that can range from blatantly outrageous to rather subtle, such as:

Stringly-typed code
A null value being used to mean something important
Using primitive types to represent complex objects
And more!

We'll cover examples in the "Where you'll see it" section below.

Because these practices are widespread, and they manifest in various ways, it can be hard to notice them!

Beware!

🤔 Why it happens

Generally, inexperienced developers are more prone to the misuse of types than experienced developers. But this is not always true. Sometimes you will find whole teams, or even companies, widely using poor practices in Java, due to having previously used another language.

👀 Where you'll see it

Here are just a few common examples of the misuse of types!

Stringly-typed code

Can a String hold an address? A car? A book? Yes...

How about JSON? A database record? A line from a CSV file? An entire CSV file?

Yes! All this and more!

Except...

Please! Don't do that as a matter of course. 🤦

Not only are there far better ways to represent any of these things or formats, but also code becomes quite prone to bugs like "wrong-order" bugs.

Here's a quick example with not one, but two, bugs!

A method signature:

public NotificationResult notifyUser(String userId, String address, String message, String type)

And a buggy usage:

notifyUser("jdoe2021", "Your subscription is about to expire." "5551231212", "text")

What are the bugs?

The first is a "wrong-order" bug where the supplied parameters are in (you guessed it) the wrong order.
The second is that the value supplied for message type, text, does not match the expected value for that type, SMS.

Onward! To yet more examples!

Null as a meaningful value

An ecommerce site needs to represent that items are:

currently in-stock
currently not in-stock
backordered

OK. Makes sense to use a Boolean, backordered, which means the following, right?

Value	Meaning
true	backordered
false	in-stock now
null	neither in-stock nor backordered

Wrong! The cringe is high. Please never do this (or anything like it).

Yet, it's amazing how frequent you will see code like this, even in public libraries.

Yikes.

Using simple types to represent complex objects

Final example so that we don't go too long. But keep in mind these examples are literally only three of the most common ways to misuse types. There are so many more!

This example is really too common: using floats to represent money. It is so common, that JavaPractices has a whole article about it. You can read what they have to say, and why its a problem, over there.

🛠️ How to fix it

There is an easy and reliable cure for the misuse of types in Java.

Complete the Java tutorials for all trails covering the basics.
Learn and know the standard libraries.
Read Effective Java. (This is a link to the publisher's site, and is not an affiliate link! I have no association to the publisher or the author. It's just a good, universally-respected book.)

Homework

I think the homework is everything just listed under "How to fix it" above.

But I have one more request:

I'd love to hear some of the "misuses of types" that you have experienced in the comments below.

But is remote work equitable?

scottshipp — Wed, 01 Dec 2021 17:10:19 +0000

Remote work is supposed to be "the future of work," but it has me wondering, Is remote work equitable?

Not everyone has the same working conditions. Internet connection? Heat? Noise? Ergonomics? Videoconferencing quality?

I think remote work is great but I'd like to see us discuss how to even the playing field of remote work a bit more.

Thoughts?

IntelliJ Hacks: Save Run Configurations to Source Control

scottshipp — Wed, 24 Nov 2021 15:19:48 +0000

We've already covered instant Javadoc, prettifying JSON, and multi-line editing, all within IntelliJ. Now let's cover shared run configurations.

If you've been an IntelliJ user for some time, you've probably collected quite a few of your own run configurations. What is a run configuration? It's simply a collection of metadata about a run of any kind. It could the metadata for creating a Docker image, running a web service, running a suite of tests, or something else entirely.

Your run configurations always appear at the top of your screen with a green "play" (triangle) button next to them.

They look like this, when you click the dropdown box:

They get created in various ways, but the most common way is simply clicking that little green play button when you see it in the left margin next to some code.

The Hack

Now, for the hack. Most people don't know that you can save these run configurations to files, and check them into source control! That way they can be shared among a team. This is actually a very simple thing to set up:

Navigate to "Edit configurations" in the Run configurations dropdown.
Navigate to the run configuration you would like to save.
Check the "Store as project file" box.
Commit it to your source control the normal way.

More information about this is documented in the help.

Final tip

Don't forget to scrub any secrets out of your run configurations before you check them in. A good way to do this is to replace them with environment variables.

Now go share those things with each other and save your team some time!

Java Pitfalls: Unboxing null Booleans

scottshipp — Fri, 19 Nov 2021 18:00:03 +0000

Photo by Vlad Bagacian from Pexels

Java is a great language but it can really bite you if you don't watch out! Here's the first installment of a series of helpful things to watch out for in Java!

😰 Today's Pitfall

The following code sometimes throws a NullPointerException. Can you guess why?

public boolean checkIfDelivered(Food food) {
    if(food == null) {
        return false;
    } else {
        return food.wasDelivered();
    }
}

It's hard to imagine a NullPointerException happening here, isn't it? Considering the null check?

Yet, here is the exception you may see from Java code like this:

Exception in thread "main" java.lang.NullPointerException
    at com.company.MyClass.checkIfDelivered(MyClass.java:20)
    at com.company.MyClass.main(MyClass.java:13)

OK so it's actually impossible to see the problem without another piece of vital information. Here's part of the Food interface you should know about.

interface Food {
    Boolean wasDelivered();
}

🤔 Why it happens

This all has to do with conflicting types. The return type of Food.wasDelivered() is Boolean, with a capital "B." But the return type of the checkIfDelivered() method is boolean.

Yes, that's right: it's all because of one letter. 😆

Well, that's not entirely fair. There's a lot more to it than a letter: boolean is a primitive type in Java, whereas Boolean is a special class called a "wrapper class."

Primitive types in Java are represented by reserved keywords like boolean, int, and char. Notice that they are always shortened and lowercased.

Every primitive can be "wrapped" in a corresponding Java class called a "wrapper class." Each wrapper class is capitalized according to Java's class naming convention and lengthened to its full name. int becomes Integer, char becomes Character, and boolean becomes Boolean.

The Java tutorial explains it this way:

…the Java platform provides wrapper classes for each of the primitive data types. These classes "wrap" the primitive in an object. Often, the wrapping is done by the compiler—if you use a primitive where an object is expected, the compiler boxes the primitive in its wrapper class for you. Similarly, if you use a number object when a primitive is expected, the compiler unboxes the object for you.

—From the Oracle Java Tutorial

By the way, it is more common to use the terms "boxing" and "unboxing" instead of "wrapping" and "unwrapping." You can read more about autoboxing in the Java tutorial.

The automatic "unboxing" of a Boolean to a boolean is exactly the problem with the code snippet above! The food.wasDelivered() method returns a Boolean object, which means it can also return null. The checkIfDelivered method returns a primitive boolean, which means if you try and return food.wasDelivered() the compiler attempts to unbox it.

And…BOOM! 💥 When it is null, a NullPointerException results.

👀 Where you'll see it

It's common these days to retrieve data over the network from web services. When that happens, the response is usually in a format like JSON, which does not have the same "primitive" types as Java.

It may be common for the JSON representation of a Food to look like this:

{
    wasDelivered: null
}

Null is an entirely valid value in the JSON schema.

Or it may just be missing altogether, like this:

{}

In either of these cases, most Java developers will use a JSON-to-Java conversion library, such as Jackson, to map the JSON object to a Java object. These libraries can be configured to default the value of wasDelivered on the resulting Java object to false or true, but more often either of the above cases will just result in the value being null.

If the resulting object is a Food object like in our example code, you now know what will happen. 😈

🛠️ How to fix it

It's considered a best practice to prefer the use of primitive types in Java because of the performance overhead that comes from autoboxing. So, if you can, avoid the problem rather than fixing it. Use boolean throughout your code and then you won't have to think that much about what happens if the JVM attempts to box or unbox a value.

But, as you can see from the above example of a JSON response being mapped to a Java object, you're not going to be able to avoid it in some cases. It may even be preferable in our Food example that wasDelivered is stored as a Boolean, because it may be useful as a way to know that the value was null or missing in the JSON response.

So that means you just need to exercise your due diligence when retrieving the value.

The offending method can be rewritten just slightly as follows, and all will be well:

    public boolean checkIfDelivered(Food food) {
        if(food == null || food.wasDelivered() == null) {
            return false;
        } else {
            return food.wasDelivered();
        }
    }

You may find that you write a lot of boilerplate methods like the above. In that case, wouldn't it be nice to have a utility to use instead? The popular Apache Commons Lang library has the exact thing you need.

It's called BooleanUtils and has two nice methods you should be aware of. The first, toBoolean, translates the wrapper Boolean to false if it has a null value. The second, toBooleanDefaultIfNull, lets you explicitly define the behavior, meaning you can default to true if that makes more sense for your case.

Here is our offending method rewritten with toBoolean:

public boolean checkIfDelivered(Food food) {
    if(food == null) {
        return false;
    } else {
        return BooleanUtils.toBoolean(food.wasDelivered());
    }
}

Homework

Now that you know a little more about autoboxing, don't forget to read the Java tutorial to learn more.

DEV Community: scottshipp

What's so bad about four-week sprints?

How to write an effective email as a software engineer

Provide one clear takeaway

Put the takeaway in the subject line

Subject line examples

Aim for five sentences or less

Providing context

The non-email option

Replies

Email Debates

Don't send it yet

Send it!

Toxic tech interviews still rampant

Estimation is not impossible

What is estimation?

Estimation techniques

Learning to estimate

So how do you?

Ending on a low note

Web Services 101: Why x00 status codes are so generic

Quick intro to HTTP status codes

x00 status codes

Explanation

Conclusion

IntelliJ Hacks: Copy paste history and plain text paste

The Hack

Final tip

Introducing todos in noted cli v0.0.3

An amazing note-taking system with Markdown and Git, Part 1

scottshipp ・ Oct 19 '21

Introducing the todos subcommand!

Build a next-level RESTful web service with Spring Boot

Building the next level

Adding a PUT

Preparing the existing code

Adding a PUT mapping

Test the service

Congratulations

Java Pitfalls: Misuse of types

😰 Today's Pitfall

🤔 Why it happens

👀 Where you'll see it

Stringly-typed code

Null as a meaningful value

Using simple types to represent complex objects

🛠️ How to fix it

Homework

But is remote work equitable?

IntelliJ Hacks: Save Run Configurations to Source Control

The Hack

Final tip

Java Pitfalls: Unboxing null Booleans

😰 Today's Pitfall

🤔 Why it happens

👀 Where you'll see it

🛠️ How to fix it

Homework

Introducing the `todos` subcommand!