melreams.com

Nerrrrd

You don’t have to be a developer

This is a follow up to my post about digital literacy and learning to code. I want to be clear that while I believe everyone should have the opportunity to learn to code and the basics should be taught in school, not everyone has to be a developer or even any good at coding or feel like they need to pour hours and hours into it when they hate it. People seem to get the idea that learn to code initiatives mean everyone! must! learn! to! code! which is not even slightly the case. We just want everyone to be able to make a choice about whether or not they’re interested instead of assuming they’re not welcome.

If you try out, say, a Ladies Learning Code workshop and you come out of it thinking you’d rather have spent the day digging a ditch, great! I started college with a few people who went to all the trouble of applying, getting into the program, and going to class for weeks or months before deciding it wasn’t for them. If you can skip all that hassle and find out in a single day and a measly $50 that code isn’t for you, that’s honestly fantastic. Now you can focus on something you actually like doing instead of something that makes you miserable.

Before you decide code is definitely not your thing, I do have some advice. First of all, learning to code is hard. You’re learning a whole different way of thinking, it takes time to get good at that. Don’t feel bad if you’re not good at it right away. People have different learning styles too. Plenty of my classmates disagreed about which teacher’s explanation of a given concept was clearer. If coding just doesn’t make sense to you, it could be because your teacher isn’t explaining things in a way that makes sense to you.

Or maybe you’re just not in a good headspace to learn a really intense new skill right now. Honestly, if you’re a new parent I don’t recommend trying to force yourself to learn to code. Looking after a tiny human is quite enough stress to put on yourself. If you’re excited about code by all means give it a shot, but if you feel stupid all the time it’s absolutely not because you are stupid, it’s because you’re brutally sleep deprived and stressed out and operating at a huge handicap. Code can wait until you start sleeping regularly again.

All that said, if you understand code just fine but you’d rather watch paint dry, or don’t understand code and would still rather watch paint dry, go do something you actually like! Code is not the only worthwhile thing you can do. Have you ever seen an interface a programmer designed? It was awful, wasn’t it. If you like tech but not programming, you could be a UI designer, an artist, a marketer, a community manager, a tester, a customer service rep, a graphic designer, a copy writer, an admin, a game designer (the easiest way to get to design games is to build your own but that’s not the only way), an animator, an office manager, a level designer, the list goes on and on and on.

If you want to code, great! If you would rather do anything else, great! Don’t ever feel like programming is something you have to do whether you like it or not.

The Visitor design pattern

Let’s talk about the visitor design pattern. This one is tough to find a real-world analog for, but once it clicks for you it can be really useful.

Basically the visitor pattern is used when you want to add functionality to an object or a set of objects without changing the object itself. If you have a list of objects and you want to perform a particular calculation on each one and might need to add more calculations later, you would use the visitor to ‘visit’ each one, get its state, and do the calculation. Headfirst design patterns uses the example of a menu item and an ingredient both needing a nutrition information report. It’s ugly to add essentially the same method to two classes and it violates the single responsibility principle to add a method that does something the base object shouldn’t know about.

Uncle Bob uses the example of building a report with data from hourly but not salaried employee objects. The employee object shouldn’t know anything about how to generate a line for that report or even whether it should be on the report at all, so it’s much cleaner to use a visitor to get each object’s data and use that to build the report.

So how does the visitor pattern actually work? First of all you need some interfaces or abstract classes for your other classes to inherit from. To keep using Uncle Bob’s employee example, you need an employee interface with an accept method that takes a visitor interface/base class as a parameter. Your visitor interface needs a visit method for each type of object it’s going to visit. Now that you have your interfaces set up, concrete employee classes like SalaryEmployee and HourlyEmployee can implement the accept method. All you need to do there is call visit(this) on the visitor that was passed in. Your concrete visitor class just needs to implement visit methods for each visited object and you’re done! There’s a nice clean class diagram here in case seeing it makes it easier to understand.

Why so many interfaces? Wouldn’t it be simpler just to call methods on the concrete objects directly? Not so much. We need an accept method on the employee interface so that the code that iterates over your list of employees and calls accept(visitor) on each one doesn’t have to know what type of employee it is. We need a visitor interface separate from the concrete class/es so that we can add more visitors without having to change the visited objects and because the visited objects shouldn’t be coupled to the visitor object. In the report example, the employee objects shouldn’t know anything about the visitor that compiles the report. To put the single responsibility principle another way, the report just isn’t any of the employee object’s business. If we decide to change the way that report is calculated or add another version of it, the employee object shouldn’t know or care.

Why not put the accept(visitor) method in the employee base class? Because then it would only be able to pass an Employee to the visitor, which is no good if different types of employees need to be treated differently. Yes, it’s duplicate code, but only a tiny little of it and in this case it’s necessary.

Aside from keeping your base objects from having multiple responsibilities, another thing the visitor pattern gives you is one class where all the related methods live. To stick with the report example a little longer, we’ve got all our report logic in one place instead of scattering it over different classes. Yay single responsibility! If we decide to change how we calculate rows in that report, we only have to change one class. If we only have two types of employees that may not sound like a big gain, but what if we need to add contractors and consultants and seasonal employees and part time employees?

The visitor pattern is a really weird concept at first but once you understand it, it can make your code a lot cleaner.

Scheme tip of the day

Get Racket. Technically the racket IDE is for the Racket language, but it works just fine with scheme if you put “#lang scheme” (minus the quotes) at the top of your .scm file. The thing I really love about Racket is the debugger. You can actually step through your scheme code instead of just littering it with (display <blah>)! So much easier!

Digital Literacy

One of a number of places I volunteer is Ladies Learning Code’s Victoria chapter (you can also find them on Facebook, Meetup, and Twitter). What we’re all about in the Victoria chapter is digital literacy for everyone.

To make sure we’re all on the same page, I’m defining digital literacy as the ability to find your way around and get things done on desktops, laptops, tablets, smartphones, and to be able to find your way around on the internet in terms of being able to find and share a link, send and receive email, post and reply to posts on social media, search for the information you need, and recognize blatant scams.

Considering how many of our jobs involve computers, if only for a little word processing and email, it’s pretty clear why digital literacy is important. What might be less obvious is how important it is that everyone get the opportunity to learn a little bit of code, which is the more in-depth form of digital literacy.

There’s been plenty of debate over whether everyone should learn to code or if everyone should be taught to code in school, which frankly is pretty boring. Code is important for the exact same reason science is important: “Because the world is not magic.” Just like everyone deserves to know that the physical world is not magic, everyone deserves to know that the digital world is not magic either. Computers are not magic, code is not magic, software in general is not magic, and the internet is not magic (printers, on the other hand, are infernal machines that feed on human misery). When these things are all such important parts of our daily lives, it’s absolutely necessary that all of us have a basic understanding of how they work.

It’s not that everyone should be experts who are able to develop an entire app on their own, but to quote @alicemazzy: huge diff btwn not knowing how to use a hammer well and not knowing a hammer is a tool that exists that solves a certain class of problems. Everyone should be taught what kind of problems are solvable with code and what sort of problems are created with code. You don’t need to be an amazing developer to understand that analyzing a spreadsheet of registrant data to figure out which events had the most attendees is a problem you can solve with code and that spam is a problem someone else created for you using code. So is terrible software (Ashley Madison, I’m looking at you. Ethical issues aside, if you charge a premium for security your service should actually be secure).

The same way you deserve to know that if a diet or a deal sounds to good to be true it most certainly is, you deserve to know that a Nigerian prince is most certainly not in need of your help and that bankofmontreeal.com is not a site where you should enter your password. If you’ve gone to a single html/css workshop like the ones Ladies Learning Code offers, then you understand how easy it is to build a totally convincing looking website. It’s not magic, it’s just a bit of html and some tedious css pixel pushing.

If you’re going to spend any time on the internet, you need to and have the right to understand the basics of how it all actually works. If you don’t, then you’re stuck with the internet equivalent of hoping that salesguy down at the used car lot is honest. Do I really need to tell you that’s a bad place to be?

Best Practices

Let’s talk about questionable code and the best practices to fix it. Even if you’ve been a developer for years it’s good to do a quick review once in a while and make sure you haven’t picked up any bad habits.

Commenting out code instead of deleting it

I’m as guilty of this as anyone else, but honestly it’s a waste of time. If you ever actually need that code back you can pull it out of source control, that is what it’s for. As much as I’ve wanted to hedge my bets and just comment out that block so it’s easier to put it back if I need it again, I’ve almost never actually needed to do that. The commented out code just hangs around in your file forever, confusing new developers and forcing you to wonder if you should update it every time you work on that method. That’s a lot of trouble to go through over code you’re never going to use again. Just delete it, it’s easier. If you’re really worried about getting it back, put the delete in its commit and add a good descriptive commit message.

Cryptic variable names

This is a huge pet peeve of mine. Characters aren’t rationed! You can use as many as you need to make the purpose of your variable clear, nobody’s going to come and take them away. Excessively long names are annoying too, but they’re not nearly as bad as wasting time figuring out that “un” actually means user name. Autocomplete has been around for a long time, the excuse of not wanting to type long variable names is not going to fly. Give your variables meaningful names, the inconvenience will pay off in the long run.

Long methods

Again, there’s no rationing! You do not need to stuff everything and the kitchen sink into one method, you’re allowed to have more than one. Refactoring has been around for a long time too, any reasonable IDE should let you extract a method in a few clicks. Even if you have to manually refactor, the pain is worth it. With smaller well named methods, you can quickly skim through code and figure out what’s going on. Without them, you can waste a whole lot of time trying to figure out which part of that ginormous method you actually need to change.

Methods with huge numbers of parameters

This issue is closely related to the last one. If your method has an excessive number of parameters, it’s probably doing too much and it’s likely too long as well. This one can be painful to fix depending on the rest of your architecture, but if you can manage it without tearing everything apart it’ll make things much easier the next time you need to look at that code or use that method. The more parameters you have, the more changes you have to mix some of them up and introduce weird bugs into your code. If you really do need lots of parameters, at least bundle them up in a <your method>Config object to make it harder to mix them up.

These are far from the only problems you’ll see in your code, but looking out for these simple issues is a good place to start cleaning up your codebase.

Impressively evil

I’ve seen bad things done in java. The kind of things you can’t unsee. But I’ve never seen anything quite like this java program that makes 2 + 2 = 5:

import java.lang.reflect.Field;

public class Main {
    public static void main(String[] args) throws Exception {
        Class cache = Integer.class.getDeclaredClasses()[0];
        Field c = cache.getDeclaredField("cache");
        c.setAccessible(true);
        Integer[] array = (Integer[]) c.get(cache);
        array[132] = array[133];

        System.out.printf("%d",2 + 2);
    }
}

Thanks, codegolf user MichaelT, I didn’t need to sleep again anyway.

Fiddler rocks

Fiddler rocks. Fiddler is a free web debugging proxy for any browser, system or platform. I’ve only ever used it on Windows so I can’t speak to how it performs on any other OS, but on Windows it’s pretty great.

To go into a little more detail, Fiddler captures every request your browser makes and lets you save, retrieve, and analyze them. Mostly I use it for simple things like seeing the full error message and headers returned by a failed api call when all my javascript is telling me is that “something went wrong.” Thanks js, you’re a big help.

A lot of why I like Fiddler so much is just personal preference. The network tab in Chrome dev tools does a lot of the things I use Fiddler for, but I like Fiddler’s interface better. Fiddler does have some differences, though. If you want to save a few rounds of requests across page refreshes so you can compare them to each other, Fiddler lets you do that. It also has a more powerful filtering system than Chrome dev tools, so you only have to see the requests you care about.

Another awesome thing you can do with Fiddler is set up a mobile device to use it as a proxy. Logging from a mobile app is all well and good, but sometimes it takes much longer to add logging, rebuild, and redeploy than it does to just update your mobile network settings to use Fiddler as a proxy.

While I mostly use Fiddler for very simple request/response viewing, you can do some pretty cool stuff with it like performance testing, session manipulation, and security testing. There are also lots of add-ons you can try if Fiddler doesn’t already do what you want, plus you can customize it on your own.

As much as I love Fiddler, there is one caveat I need to mention. Firefox is totally incapable of coping with Fiddler unless you change some settings. I strongly recommend that you do that immediately if you install Fiddler because you will forget that you have Fiddler running, try to test something in Firefox, and freak out because everything is suddenly broken (not that I’ve ever done that. Repeatedly). It’s not, Firefox should just be ashamed of itself. Even IE can handle a freaking proxy. You used to be cool, FF. Now you’re like a broken down racecar that’s getting lapped by a go-kart. With square wheels. That’s been set on fire.

Why should you care about Fiddler? It might be better than what you’re doing right now. Having better tools to do the tedious stuff for you means more time for actual development, even if you have to invest a few minutes up front to figure out if Fiddler is actually better than what you’re using right now. It won’t magically make you a better developer, but it will give you more time for development, which can be pretty close to the same thing :)

Android tip of the day

There’s this really awesome utility for Android called Tasker that lets you automate all kinds of stuff on your phone. I love how much stuff I can do with it, but the interface doesn’t just fail to be user friendly, it’s actively user hostile. Every damn time I set up a phone I forget how to configure Tasker to automatically unlock my phone when I’m at home. This little how-to guide explains it all really clearly and (at least for now) matches Tasker’s interface.