Mel Reams

Nerrrrd

Ember tip of the day

Lately I’ve been working with Ember components, which are really pretty cool. For anyone who doesn’t know, in Ember components let you encapsulate layout and functionality neatly together so you can reuse things all over your app without making a huge mess.

Ember components have a lifecycle you should know about and a set of lifecycle hooks you can call. Those hooks are really handy, they let you do all kinds of things at different points in the component’s lifecycle. Be warned, though: you MUST call

this.super()

at the beginning of your lifecycle hook or your component will break in deeply weird ways. When you implement a lifecycle hook in your code, you’re actually overriding a method in the base Ember component. If you don’t call this.super(), the original function doesn’t get called and shockingly enough, it does a bunch of things that are necessary to make your component work right :)

Because Ember is open source, you can go have a look at what the base lifecycle functions do. Here’s the init function, which calls this.super() itself before it does the rest of its setup. Reading the code yourself totally isn’t necessary, but it’s interesting and might help you remember why it’s so important to call this.super().

What is technical debt anyway?

A server room full of very messy wiring. There are so many cables connecting devices together that you can't see the devices themselves,
Actually relevant image by Happy Tinfoil Cat

Technical debt is one of those things that you completely understand when you run into it, but is really hard to explain to someone who has never worked on a large application. That picture on the left of the messy server room is probably the best illustration of technical debt I’ve ever seen, and you should definitely use it the next time you need to explain technical debt to someone.

You can guess exactly how it happened, can’t you? “I know this is the wrong way to do it but we’ve got to get this server back up NOW so just string a cable over to that other switch and we’ll tidy it up later.” FYI, that never happens just once. “Later” when it’s time to tidy it up never comes either. There’s always something more important than going back and fixing something that technically works.

Even when you have the time to make a change the right way, it’s a huge hassle because the server room is already such a mess. Eventually, it gets so bad it’s just impossible to change anything without first tidying the whole thing up. That’s what technical debt is like in code, it’s just harder to see.

Every time you cut corners to get something out the door quickly, you build up technical debt. You make a little bit more of a mess, and as the mess gets worse and worse, it gets harder and harder to make more changes, just like in the messy server room.

Just like financial debt, sometimes it’s worth taking on technical debt. And just like financial debt, you need to think carefully about it before you take on that debt and you need to have a plan to pay it off. Ignoring the fact that you have technical debt is like ignoring the fact that you’ve maxed out your credit card, it just gets worse if you don’t deal with it. Unlike financial debt you don’t directly get charged interest on technical debt, but every piece of new development you do has to work around your existing debt. If your project is dead and you don’t have to change anything then your technical debt doesn’t matter, but on a project that’s still being updated you’ll eventually have to work around the corners you cut. Every time you do that without tidying up the original mess, you make more and more of a mess until you end up with something like that server room above.

All of this is completely obvious if you’re a developer who has worked on a large project, but technical debt can be really hard to explain to non-technical people because they aren’t programmers. That photo is a fantastic visual metaphor for technical debt, which is why I think it’s so great. Once you have a metaphor like that, you can have a productive conversation about technical debt with a non-programmer because they now have the slightest idea what you’re talking about :)

It would be great if management would just trust the dev team when they say they need time to pay down technical debt instead of continuously pumping out new features, and it’s definitely an issue if different parts of the company don’t trust each other, but even when they do I think it’s reasonable for managers to want to understand what’s going on. As a programmer I certainly understand the urge to yell and stomp your feet about people who don’t understand technical debt (or why sometimes things take way longer than you expected or why adding people to a late project makes it later or why you need to make time for documentation, etc, etc), but you know, it’s a lot more productive to find a way to explain it.

What’s the big deal about years of experience in a language?

A young cow in a sunny green field looks toward the camera
Unrelated image from pexels.com to make this post look nicer in social media shares.

A while ago I was wasting time on reddit, as you do, and came across an interesting question: “why do employers and just about everyone else make a big deal about language-specific positions and “what language should I learn”, etc.?” The greater context there was that the asker had a pretty easy time picking up new object oriented languages once they got a good handle on one of them, so they were confused about why people seem to think x years of experience in language y were so important.

I have mixed feelings about job postings that require a certain number of years of experience in any particular language. If you understand programming concepts (from low level stuff to how ifs and loops work to higher level stuff like how to keep your core business logic separate from presentation code) then yes, it’s pretty easy to apply those in whatever programming language you need to.

As a bit of an aside I think a lot of job postings are more of a wildest dreams wishlist than a useful description of what’s actually necessary to do the job from day to day. In the context of this particular question, I have a strong suspicion that when most job postings say the applicant needs “5 years of experience with Java” what they actually need is someone who knows Java and has 2-5 years of programming experience.

That said, while most programming concepts are transferable (especially if you’re using languages with broadly similar syntax), you really are more productive with a language you already know well, especially if you don’t have much programming experience. There are weird quirks of languages you may not run into at all until you’ve been working with them for a while, too.

For example, did you know in Java String.substring() used to return a “view” of the original string, not a completely separate string? And that since Java 1.7 update 6 it returns a completely separate string? Yes, that seems really minor but it can cause some weird weird bugs if you change the original string thinking it’s completely separate from the substring. And because stuff like that doesn’t look wrong, it can be absolutely miserable to track down.

Just because I technically can code in languages other than Java doesn’t mean I can do it quickly. When I need to do any front end work I spend a lot of time looking things up because I don’t remember the exact parameters basic string operations take in Javascript. If I had to write Javascript all the time I would start remembering those details, but that’s with a foundation of years of programming experience to start from. If you’re a new dev who just graduated from college/university/bootcamp, you’re going to have a harder time learning a new language because you’re also going to be learning professional programming at the same time.

Which language you learn first also makes a big difference in how hard of a time you have learning to code. In general I think you should start with whatever language lets you build stuff you’re excited about, but I don’t want to pretend all languages are equally beginner friendly either. C and C++ are good for many things but they are not your friends :) Python and Ruby are easier to pick up because they take care of fiddly details like memory management for you, and Javascript can be a good first language because you don’t need any special programs like IDEs or compilers at all, you can write it in notepad and run it in your browser.

So given all of that, why do (some) employers make such a big deal about language specific positions? Because if you don’t already understand programming really well, you need some way to find people who have a decent chance of succeeding in the position you want to fill. Sadly, not all job postings are written by people who understand the day to day work so it’s not unusual to end end up with some poor HR person’s best guess at what’s needed.

“5 years of Java experience” can also be a pretty decent proxy for “actually likes working with Java and won’t ditch us in a year to work in [cool new language of the week]”. Some languages are just not considered cool and plenty of people have a perfectly legitimate dislike of the amount of boilerplate you have to write to make Java do much of anything, so it makes sense to look for people who are willing to work with your tech stack for the long term (or at least the longer than one year term).

Readers, what do you think of stuff like “must have 5 years of Java experience” in job postings?

Linux tip of the day

Take out the trash! Unlike Windows, Linux (at least my distro, Mint) doesn’t have a recycling bin/trashcan icon on the desktop to remind you to empty your trash directory once in a while. That really adds up if you forgot to empty your trash for, uh, a while. Technically you can just hunt down your trash directory and delete everything inside it, but do you really want to have to remember the path? And remember how to find it if you delete a file on a USB drive?

trash-cli to the rescue! The terminal command to install it is sudo apt-get install trash-cli (at least on systems with apt-get), and to run it you just type trash-empty. Thanks as usual to stack overflow for that answer.

When I finally ran that on my laptop, I got 3.6gb back. Not bad for under a minute of work :) If you’re new to Linux like me, don’t forget to take out the trash.

 

Lastpass tip of the day

LastPass tries to be helpful by filling in form fields for you, but sometimes it gets it wrong. If you see it fill in the wrong data or if you just mysteriously struggle to sign into services that use 2FA (for me LastPass was helpfully inserting an old 2FA code when I tried to sign into AWS, which meant AWS thought my authenticator app was wildly out of sync and would make me resync it every time I tried to log in), follow these steps and see if it helps.

In case that link ever stops working, you’ve got to find the problem site in your vault, click the little wrench icon to edit that site, then click the little wrench icon again in the edit popup to edit form fields, then delete all the fields with bad values. There may be quite a few of these.

Credit where it’s due, one of my coworkers told me about this. Thanks Logan, I don’t know if I ever would have found that on my own!

App 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?

How does a thread work, anyway?

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.

Link 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 :)

JUnit tip of the day

Fun fact about JUnit tests: if something throws an exception that prevents your test from completing normally, it can’t clean up after itself. Normally this isn’t a big deal but if, for example, your setup method adds any test data to your database or creates a whole new database, you’re going to need to clean that up manually. Turns out extra databases eat up a lot of hard drive space if you don’t tidy them up for, uh, months. Just fyi :)

WordPress Appliance - Powered by TurnKey Linux