melreams.com

Nerrrrd

Back to basics: Java generics

in back to basics, development, generics, java

a crowd of people release paper lanterns with candles inside that make them float into the sky. the dark sky is full of small glowing lanterns floating away.
Unrelated image from pexels.com to make this post look nicer in social media shares.

Every so often you’ve got to go back to basics no matter how long you’ve been doing something. It’s amazing how much you forget when you haven’t done something in a while, even if it’s kind of a core feature of a language you use all the time. Like Generics in Java!

So let’s talk about Generics. First of all, what is a Generic? It’s just a placeholder for a type. Where you would normally put a concrete type like String or Integer, you can put T instead.

Why should we care, though?

In short, because class cast exceptions are a pain to deal with. Back in the dark time before Java 5, you could put any object you wanted in a Collection but for that to work with Java’s type system, all of the Collections classes had to work with Objects. That meant you could put anything in, but when you got it out all Java knew was that it was an Object, so you had to know what to cast it to to use it for anything interesting.

As a bit of an aside: yes you can use arrays (not to be confused with ArrayLists) to avoid dealing with casting, but then you miss out on all the handy stuff Collections do for you, like automatically resizing themselves when you add more items. Collections for the win!

Compared to having to resize arrays manually, having to cast your objects back to the object you really wanted when you take them out of a Collection doesn’t sound so bad, but here’s the big problem with that: what if you mess up somewhere along the line and try to cast that object to something it can’t be cast to? Then you get a ClassCastException, which is really irritating because it’s a runtime exception (I should write a post about exception handling in Java shouldn’t I) for something the compiler shouldn’t have let you do in the first place. Not finding out your code is wrong in a totally predictable way until you run it sucks.

Generics to the rescue! With Generics, you can tell a collection what kind of things go in it when you create it, and then not have to do any casts when you take them out because you can only put one (depending on how you count subclasses) type of thing in there.

Okay great, but how do you actually use Generics?

If you just want to put things in a Collection and get them back out, it’s really simple. In general using existing code that uses Generics is super easy.

List<String> names = new ArrayList<>();
names.add("Amy");
names.add("Brianna");
names.add("Cara");

String name = names.get(0);

While I’m at it the <> operator (aka the diamond operator) is great. Before Java 7 you had to specify the whole type in both the declaration and instantiation, which kinda sucked if you needed, say a Map<String, List<ReallyLongTypeHere>>.

Where things get a little more complicated is writing your own code using Generics. There are two places you can put generic types, on the class declaration and on the method declaration and the really fun part is you can put different types in each place. You could put a different generic type on each method if you wanted to, but that would probably be evil so don’t do it :)

Let’s look at the List source code for an example:

public interface List<E> extends Collection<E> {
    int size();
    boolean isEmpty();
    boolean add(E e);
    E get(int index);
    <T> T[] toArray(T[] a);
}

FYI that’s a tiny subset of all the methods on the List interface, I just didn’t want to list a ton of methods that aren’t relevant to this post.

When you put a generic type like E on the class (or interface!) declaration, what you’re saying is that this class primarily deals with Es. That way when you use the same generic in methods like add and get, it’s obvious what’s going on.

Why E instead of any other letter? It’s short for element. This post has a nice list of the naming conventions for generic types. I can’t link directly to that section, so just search for “naming convention” and you’ll find it.

The toArray method declaration shows how you can use another generic type just for one method even if the class already has a generic type. The <T> just means that method takes a generic type T, it’s separate from the return value. Basically, every time you use a generic type, you’ve got to have a <T> (or <E>, or <N>, etc) somewhere so Java knows you’re using a generic and doesn’t go looking for a class named T.

One thing that’s a little tricky with generic types is getting their Class object. You need a Class for things like using Jackson to convert Json into an object in your system, but you can’t do E.class. Luckily, there’s a way around that, you can use Class<E> like so:

//here's an example method using a generic Class
public static <T> T decode(String json, Class<T> destinationClass) { //code goes here }

//and here's how you call it
Result decoded = decodeUtil.decode(myString, Result.class);

I forgot about Class<T> once and made a real mess of my code, but at least you get to learn from my mistakes. A good rule of thumb for using generics is that if you still need to cast anything, something is wrong.

There are a bunch more fancy things you can do with bounded generic types and wildcards, but I’ll get to those in another post. What I’ve covered in this post is the majority of what you’re likely to need to do with Generics, you’ll need to get a handle on this stuff anyway before the advanced stuff makes sense.

App of the day

in android app of the day, ios app of the day, tip of the day

Today’s app is Authenticator Plus It’s available for both Android and iOS and will save you a lot of hassle if your phone dies on you like mine did. On an unrelated note, I do not recommend the Nexus 5x but you can’t buy new ones anyway so that’s kind of a wash.

Authenticator Plus, on the other hand, is great! It stores your accounts in your dropbox so you can simply sync them onto another device if you can’t use your usual device (don’t forget to factory reset it if you lost it!) instead of going through the slow and tedious process of using recovery codes to get back into your accounts. Don’t worry, you have to set a master password to access your accounts on a new device.

Full disclosure: Authy does the same thing and is free where Authenticator Plus is paid. One of my coworkers likes it and another one didn’t like the onboarding process, so you’re going to have to make your own decision there :) I started with Authenticator Plus and can’t be bothered to switch everything to Authy just to try it out so I’ll be no help there.

And while I’m at it, don’t use SMS for your two factor auth! Sure, odds are against anyone bothering to attack you personally but why take the risk?

What does reasoning about code even mean?

in development, how does it work?

Unrelated image from pexels.com to make this post look nicer in social media shares.

Programmers talk about “reasoning about code” all the time, but what does that actually mean? Is it really just pretending to be a CPU and working out exactly when your for loop ends?

Yes and no. Figuring out exactly what your loops are up to is part of it, but at a higher level it’s also about how your methods, objects, modules, functions all work together. Like this stackoverflow answer says, writing code isn’t just about cranking out something that compiles, you’ve also got to be able to figure out if it’s actually right, if it performs well enough, if it can be scaled, if it’s vulnerable to bad data (whether that’s malicious or accidental).

Sadly, tools can only help you so much with everything that comes after getting your code to compile. The compiler can tell you whether your code will run, but it can’t tell you if it does what you meant. Automated tests are a huge help with that, but those tests are code themselves and you also need to be able to reason about them to make sure you’re testing what you meant to test and that the test itself isn’t broken.

To figure out what your code is doing, you need to be able to read and understand it well enough that you can predict what it will do for any given input. That’s basically all “reasoning about code” is. If you can reason about your code, you can change it or add more features without breaking things or spending hours and hours cursing at your computer and howling “whyyyyy won’t this work?!”

So being able to reason about your code is really useful, but how do you do it? Practice, mostly. If you’re a beginner programmer you should not worry even a little bit about understanding a whole codebase or heck, even a whole class. Focus on one method or one loop or one if statement at a time. When you get enough practice, you’ll be able to understand those really quickly and you can move up a level to figuring out what a whole method does with different inputs or how two methods in the same class work together.

Oh, and it really helps if the code you’re trying to reason about is good code (that is, well organized, has good names, etc). Some code is next to impossible to reason about because it’s full of giant methods or the variable names aren’t helpful at all or, and this is one of the worst problems, variables change all the time in unpredictable ways. A “total” variable that changes value each time through a loop isn’t so bad, it’s clear what it’s for and why it changes. On the other hand a “total” variable that gets reused for completely different totals at different places in a method is a real problem. Humans can only hold so many things in their working memory at once and “wait where does total change again?” takes up most of them. If you have a terrible time reasoning about a certain piece of code, it’s entirely possible the problem is not you but the code.

In cases like that when I don’t have time to refactor the code so it’s easier to read I find it really helpful to make a lot of notes and draw myself a map through the code. If you want to be really helpful you can even type up your notes / make a diagram out of your map and add it to your developer documentation.

Reasoning about code can be hard to do and takes practice, but it’s not some sort of magic that only “real” programmers can do.

How does a thread work, anyway?

in development

three large spools of thread, one orange, one purple, and one blue, against a white background
See what I did there? Image from pexels.com to make this post look nicer in social media shares.

Threads are used a lot in java, so I should probably understand how they actually work. They’re one of those things you use all the time without thinking about what’s really happening under the covers. I know threads and processes are related, but not exactly how.

First of all, what’s a process? To understand threads inside a process you need to understand processes first.

A process is an individual thing that’s separate from all the other processes running on your computer. In most cases a process is a single program running on your computer, but some programs have many processes – Chrome, for example, has a process for each tab. To quote the official tutorial on concurrency in Java: “A process has a self-contained execution environment. A process generally has a complete, private set of basic run-time resources; in particular, each process has its own memory space.” As I understand it, the separate memory space is the really important part of a process – this keeps processes from overwriting each other’s memory, crashing your computer, and wrecking your day.

Threads, on the other hand, are just parts of the parent process that execute semi-separately and all use the same memory. This means they can change a variable another thread just set, cause wildly bizarre bugs, and wreck your day. Every process has at least one thread, but can have more.

Okay, so why would you want to use threads when you could use processes to keep everything separate? Because processes use up a lot more system resources than threads, it’s more work to get them to communicate with each other, and they’re just overkill for a lot of problems. If you’re building in a search feature in your app and you want to search by a few different things (like name, address, and ID number) from one search box, creating a whole process for each search is way more work than you need to do when you could just use threads. Do you really want to write a whole separate program for each search? I sure don’t.

So threads are convenient, but what are they really? Saying they’re a single thread of execution through a program is all well and good, but what does that really mean? To quote stackoverflow: “A thread is a basic unit of CPU utilization; it comprises a thread ID, a program counter, a register set, and a stack.” Those things are also called the execution context, because they’re everything you need to know about the executing program to stop it and start it again in exactly the same state it was in. The CPU does that a lot so it can appear to do two things at once (if you have a multicore processor, it actually can do more than one thing at once). If one thread is waiting for data to come back from the database, which takes forever from the perspective of a CPU, the CPU will essentially make a note of where the thread got to in the code and what values all of its variables had, then start executing another thread using the “notes” it made about that one.

Because threads all share the same address space, they can share information really easily by updating global variables. In a process, a memory address (aka a variable) will probably mean nothing to another process. In a thread, any variable that’s in scope can be used and (if it’s not final) changed. This is really handy for stuff like web programming – if a thread that’s handling a particular HTTP request needs a reference to the database service, it can just grab one from the controller/servlet/general parent object that contains methods for handling individual requests.

When a thread completes, its variables get garbage collected as usual (assuming nothing else has a reference to them), you don’t have to do anything special to clean up after it.

And finally, while the tutorial I linked above talks about Thread objects and Runnables, in modern Java you mostly use CompletableFutures and let them handle starting and stopping threads for you.

Let’s play CPU!

in development, learning

white ferris wheel against a blue sky with a few wisps of white clouds
Unrelated image from pexels.com to make this post look nicer in social media shares.

I think one of many reasons it’s so hard to learn to code is that the people doing the teaching have all forgotten what it was like not to know how to code, so we skip over some really important basic steps because we think they’re inherently obvious. Case in point, this poor redditor who nobody ever taught how to work through a piece of code with a pencil and paper. I had to read the question a couple of times to understand what they were even asking, it just didn’t occur to me that someone wouldn’t know how to trace through code manually.

The example that user posted was “x=0; y=0 While (x<7) { x=y-x; y=x+x; x= x+ y + 1;}”

First of all, let’s clean that up a little:

x=0;
y=0;
while (x < 7) {
    x = y - x;
    y = x + x;
    x = x + y + 1;
}

In the beginning x is 0, which is definitely less than 7 so we enter the loop.

Inside the loop, take each statement and swap out the variables for their current values and then do the math and put that value in the variable:

x = y – x becomes x = 0 – 0 becomes x = 0
y = x + x becomes y = 0 + 0 becomes y = 0
x = x + y + 1 becomes x = 0 + 0 + 1 becomes x = 1
At the end of the loop x = 1 and y = 0

Now we check the condition at the top of the loop again and x is still less than 7 so we go through the loop again

x = y – x becomes x = 0 – 1 becomes x = -1
y = x + x becomes y = -1 + -1 becomes y = -2
x = x + y + 1 becomes x = -1 + -2 + 1 becomes x = -2
At the end of the loop x = -2 and y = -2

At this point, I’m getting very suspicious this loop will never exit. I don’t think x is ever going to be greater than or equal to 7, but just to be sure let’s go through the code one more time

x is still less than 7 so we go through the loop again

x = y – x becomes x = -2 – -2 becomes x = 0
y = x + x becomes y = 0 + 0 becomes y = 0
x = x + y + 1 becomes x = 0 + 0 + 1 becomes x = 1

At the end of the loop x = 1 and y = 0. These are the same values we had after we went through the loop the first time, so now we can be completely sure the loop never ends. After each time through the loop x is either 1 or -2, there’s no way for it ever to be 7 or more.

That’s it. Working through code with a pencil and paper is just keeping track of what values all of your variables have and swapping out variables for their values. It’s really tedious, that’s why we make computers do it :) And to be clear, you’re never expected to be able to work through complicated code like that purely in your head. Everybody else needs a pencil and paper too, there are just too many details to keep them all in your working memory.

Okay, so if working through code with a pencil and paper sucks so much, why does anyone do it? Because it gives you a really solid understanding of what the computer is doing, which you’ll need later when you start building more complicated things. For a simple loop like the one above you can just throw that snippet of code into an IDE, run it, and see what happens, but you can’t even start building bigger things without a foundation of knowing what the computer is doing when it runs your code.

Project of the day

in link of the day, project of the day

Somehow I came across a link to this one episode of a podcast called Reply All. That particular episode is about Anxiety Box, a delightfully odd project by Paul Ford. He was dealing with some pretty serious anxiety and being a nerd, decided to write a program to be anxious for him. It’s a really interesting story, and while Anxiety Box is now defunct, all the code is available so you can run your own external jerkbrain if you like.

Repetition is underrated

in development, learning, opinion, unsolicited advice

a brown-skinned woman wearing a dark blue top and a white skirt plays an electronic keyboard
Loosely related image from pexels.com to make this post look nicer in social media shares.

The more I read about the struggles beginner programmers have and the more I mentor at Ladies Learning Code workshops, the more I think that repetition is seriously underrated when it comes to teaching anything technical.

When you’re learning a language or an instrument or a sport or a physical skill like plumbing or carpentry or even math, which is similar to programming in a lot of ways, you expect to have to repeat the same thing multiple times before you remember all the details and get it right every time, but somehow when you’re learning to code we assume you should only need to be told how a for loop works once and you’ll understand it perfectly right away and remember it forever. That’s just not how our brains work and that’s why I think repetition is so underrated.

It is completely normal to need to write a lot of for loops before you get it right every time. Some people do pick up programming concepts very quickly but that doesn’t mean you’re dumb or abnormal if it takes you longer. Something like a for loop (or anything programming construct) seems simple once you understand it, but there are actually an enormous number of fiddly little details you have to keep track of to get your loop to work. You know what’s a great way to learn all of those details so thoroughly you hardly even think about them anymore? That’s right, repetition!

Programming isn’t just a matter of understanding the concepts, you’ve also got to learn them so thoroughly you don’t have to think about how to write a loop, you just write one when you need it. Without that thorough of an understanding, programming is like trying to speak another language by looking up each word individually in your [other language] to English dictionary. That’s one way to learn, but you’ll probably just be miserable and frustrated and forget what you were trying to say in the first place before you’re even halfway through your sentence.

Come to think of it, maybe the kind of drills you do when you’re learning a language could help people learn to program without spending so much time worrying that they’re just not smart enough.

Anyway, repetition is seriously underrated and I wish we collectively talked more about how much practice it takes just to pick up the basics of programming, let alone the complicated stuff like deciding how to structure your code or what to name things (still one of the hardest problems in programming :) ) I think a lot of programming tutorials assume that you know you need to practice without explicitly saying it or without making it clear just how much practice you need. I have to admit I wouldn’t want to write pages and pages of very similar programming exercises either, but it’s not so hard just to say that programming takes practice and you’ll probably need to go through the tutorial a few times before it sticks.

If you did a tutorial or a workshop just once and didn’t instantly become a good programmer, congratulations, you’re normal! If you keep at it, you’ll get there.

Link of the day

in link of the day

Today’s link is a reminder that no matter how great you think your favourite language is, every language has flaws. Some people like to go around talking about how their favourite language is the best language and every other language sucks, but that’s much more about personal preference than it is about any one language being objectively better. Different languages are good for different things anyway.

Read a little YourLanguageSucks and don’t be a jerk about other people’s favourite languages :)

Let the computer do it for you

in best practices, development, tools

Loosely related image from pexels.com to make this post look nicer in social media shares.

Many years ago when I was in college, a friend taught me something that’s been really useful for my whole career. That lesson was to let the computer do it for you. Unless there’s a compelling reason to do things the hard way, just let the computer make things easier for you.

Learning lisp? Get a plugin for your text editor or a simple IDE like Dr Racket that matches your parens for you.

Working with fixed width files? Get Record Editor, it’ll save you so much time!

Fighting with javascript? Get WebStorm! Seriously, it’s freaking amazing.

If you have to do something tedious and fiddly, get the computer to help you. That’s what it’s good at. There is a tool out there that will make your life easier, you just have to go and look for it. The hard part is remembering to go look for it :)

It’s normal to think that if there was a tool you could use your teacher or your boss or someone on your team would have told you about it, but thinking to look for tools like that is surprisingly unusual. And to be fair, it can be a real timesink to try tool after tool just to find out none of them are better than what you’re already using.

That said, if someone on your team hasn’t already told you that they’ve tried everything they could find (and searched for tools recently), it’s worth doing at least a little Googling and seeing if there’s already a tool that would make your life easier. Other people use lisp, you can safely assume there are tools out there for it. Other people use fixed width files, you can safely assume there are tools for those too. And tons of other people use javascript, tools for that are getting better all the time.

If there isn’t already a tool, you might be able to build one. That’s exactly what bash or powershell scripting is for – fiddly things that humans are bad at and tedious but simple things that humans just don’t wanna do. If you’ve ever run a build script, you’ve used a custom tool that someone wrote to automate building your application so it gets done the exact same way every single time. No matter what OS you’re running, there will be other scripts out on the internet that you can take apart to build your own custom tools.

Whether you find tools or build your own, remember that boring stuff is the computer’s job!

Link of the day

in tip of the day

How do you know when to take someone’s advice and when to ignore it? Today’s link lays out a few simple steps to figure out When ignoring advice makes sense. There’s no shortage or advice for programmers out there, but there’s just no way all of it works for every single programmer. If you have a process for evaluating advice, you can be sure that the advice you reject really doesn’t work for you. If you just flail around and try stuff, well maybe the things you don’t like really don’t work for you, but on the other hand maybe they just feel weird and that makes you want to stop and go back to normal before you’ve really given them a chance.

Go forth and ignore some advice, safe in the knowledge that you gave it a fair shot and it really didn’t work for you :)