melreams.com

Nerrrrd

Ember tip of the day

If you use Ember.js and you need to update one element of an array inside you rmodel, you need to use the .replace() method. Getting and updating your array will not work, neither will trying to use this.set(‘model.array[index]’). Ember won’t register your changes unless you call the .replace() method, so do that :)

And yes, I’m writing this blog post to remind myself, I spent a good hour or two earlier this week trying to figure out why Ember wouldn’t re-render anything when I tried to update part of my model.

Let’s try it and see what happens

On Saturday I mentored at the Ladies Learning Code workshop for National Learn to Code Day. As usual it was a great experience, although pretty draining for an introvert like me, but what I want to talk about is the single phrase I used most often with my learners: let’s try it and see what happens.

Now, I’ll freely admit that a good portion of the times I said that were because I didn’t have a lot of experience with the language we were using (python, if you’re curious) and just didn’t know what would happen :) But the bigger part was that I wanted to show the learners that it’s okay to not know what’s going to happen and to mess around and try stuff.

It’s normal to be worried that you’ll look stupid or completely break your program, but the only way you can learn a new programming language (or any language, for that matter), is by trying things and making mistakes. The great thing about programming languages is that failure is just about consequence free. If you get an error message, so what? It’s not even a waste of time, you learned something that doesn’t work. That gives you one less thing you need to try next time.

Even if you’re an experienced developer, you need to keep that willingness to try things and see what happens. Analysis paralysis is what happens when you’re afraid to try something. If you’re working on a large project it’s true that you need to plan it out carefully and run your idea past other developers, but sooner or later you’ve got to start building something even if you’re not absolutely sure it’ll work. The sooner you try it, the sooner you can figure out whether or not it’ll work and the sooner you can try something else. Thinking things through is great but you can’t let it stop you from doing something.

Sometimes no amount of planning can tell you more than a few hours of trying. This is especially true when you’re just starting out, but it doesn’t stop being true just because you’ve got a solid handle on how loops work. And honestly, even the most experienced developers get off by one errors sometimes :)

When you’ve been a developer for long enough, sometimes you lose track of what it was like to be a beginner. We start assuming that we should know exactly what will happen before we even write a line of code even though that’s not even slightly how it works. I feel like I’m raining on new devs parades here, but the uncertainty never goes away. You just work on a different scale when you’re more experienced. Instead of “what happens when I change this == to a >=?” it’s “what happens when I try to use this new library?” or “what happens when we try to make our system talk to this other system?”

The next time you catch yourself slipping into analysis paralysis (and I do all the time), just try something and see what happens.

Awesome Chrome extension of the day

I recently started using StayFocusd and it rocks! StayFocusd is a productivity tool that stops you from visiting websites where you waste time. Whatever your timesinks are (for me feedly and reddit are some of the worst), you just add them to StayFocusd’s blocklist and after 10 minutes (or whatever time you set), it blocks them. By default it also blocks links that you clicked while on a site in your block list. For example, if you follow a link from reddit, that still counts toward your 10 minutes of browsing for that day.

I’m not sure how I feel about having to outsource my self-control to a Chrome extension, but on the upside I get a lot more done when I don’t have to make the decision between doing work and checking feedly again for shiny new blog posts. Try it, you’ll probably hate it but you’ll probably get more done :)

The mythical man month

In the programming field, it’s pretty rare to find a book that’s still relevant even five years after it was published. The Mythical Man-Month is still useful forty years after it was first published, which is either amazing or depressing depending on how you look at it.

What depresses me about how useful the book still is so long after it was written is that in the forty years since, we clearly haven’t learned that much about how to run projects. I first tried to read The Mythical Man-Month ages ago, and I got so frustrated about how little we’ve learned since it was published that I had to set it down. Then I completely forgot about it for a few years because I’m just that organized :) I finally finished it this year, and it’s just as relevant as ever. By all rights everything in that book should be totally obvious and taken as a given by every project manager out there, but sadly it’s not. It is, however, kind of comforting to know that other people have run into the same problems I have.

The amazing part of The Mythical Man-Month is how clearly it shows that the actual programming is the easiest part. Code is simple compared to trying to coordinate a large team and hit a deadline, but as programmers we seem to get hung up on the easy part and largely ignore the hard part. One of the many terrible ironies of programming is that a field that attracts introverts who just want to be left alone to code actually requires huge amounts of communication if you want to get anything meaningful done. For me and probably for most other programmers the code is the fun part, so it’s understandable that we’re not as good at communication as we should be but eventually we’ll grow up as an industry, right?

As sarcastic as that sounds, I think a large part of what we need to do as an industry is accept that things just aren’t as easy as we wish they were and learn to work around it. It’s pretty similar to the way children grow up and understand that the world isn’t as simple as they thought and learn to work around it. I and every other programmer ever have massively underestimated how long something was going to take, and no doubt  we’ll all keep doing that. But understanding that underestimating tasks is common allows you to leave extra space in the schedule and/or prioritize features so you know what can be cut if you aren’t going to hit your deadline.

Basically we just need to learn to account for human nature. Should be easy :)

Underrated dev tool of the day

You might not expect it, but thesaurus.com is actually a really useful dev tool. Like they say, naming things is one of two hard problems in computer science. When I have an object that’s difficult to think of a good name for, I just plug whatever vague description I have into thesaurus.com and poke through synonyms until I find something I don’t hate. Try it, it really does make it easier to pick a name :)

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?