Unrelated image from pexels.com to make this post look nicer in social media shares.
Or more specifically, why is javascript called javascript when it has basically nothing in common with java?
First, let’s have a little context. Javascript originally ran only in the browser and made webpages interactive. Java was primarily a server-side language but could run in the browser in the form of applets (they’re very rarely used now, don’t worry if you’ve never heard of them). Javascript is also dynamically typed (you can put anything you want in a variable and the interpreter figures it out (or not) at runtime), uses prototypal inheritance (you create new objects using an existing object as a prototype), and has had closures (first-class functions that ‘remember’ the state of the variables they had access to when they were declared) from the beginning. Java, on the other hand, is statically typed (thou shalt not put a double in a variable that you declared as an int), uses class-based inheritance (you create objects using a blueprint called a class and only classes can extend other classes), and only just got closures (called lambdas in java) in 2014 when java 8 came out.
About the only thing java and javascript have in common is that they both use c-style syntax (curly brackets and periods, basically). So given all that background information about how little java and javascript have in common, why on earth is javascript named javascript?
Back in the 90s when javascript came out, java was the shiny new thing everyone was excited about, and the theory I’ve always heard about the name was that it was a marketing ploy intended to make people think javascript actually did have something to do with java and was therefore cool. According to this interview with Brendan Eich, the inventor of javascript, javascript actually was intended to sorta, kinda, have a little bit of a relationship with java: “the idea was to make it a complementary scripting language to go with Java, with the compiled language.” And according to this press release, javascript’s design was: “complementary to and integrated with Java” It turns out javascript actually can interact with applets, too.
These days javascript has nothing to do with java, and honestly it may never have had much to do with it, but just because you’ve heard the “purely a marketing ploy” theory over and over doesn’t make it the whole truth. Now, who can tell me how the moral of the story applies to programming? ;)
One of the Android apps I use most often – to be fair, that’s because you set it up once and leave it alone – is Twilight. It’s basically f.lux for Android. Technically f.lux for Android is f.lux for Android, but it only works for some phones and requires root.
f.lux (and Twilight) if you haven’t already heard of it, automatically changes the colour balance of your screen to a warmer, more restful shade when the sun goes down. It’s supposed to help you sleep, which I honestly couldn’t say if it actually does, but I personally like it because it feels more restful to my eyes.
That’s great if you’re running Android, Windows, or Mac, but what if you have an iOS device? Well, if you’re willing to jailbreak it you can get f.lux, but if you can’t or don’t want to, you can use this trick to dim your screen. It’s not the same, but it’s certainly better than nothing.
One last thing to note: because Twilight is a screen overlay, Android won’t let you install anything while it’s running, even if it’s not currently changing the colour of your screen. That totally makes sense from a security standpoint, but I wish it would display an error message instead of just silently refusing to do as it’s told. If, for example, you happened to spend an afternoon cursing at your phone because it mysteriously refused to let you install a test build so you could do some debugging, that would be why. Turn off Twilight and magically things will start working again :)
Unrelated image from pexels.com to make this post look nicer in social media shares.
A question I’ve seen a lot on java programming forums is “Should I get a certification?” Like every other programming question ever, the answer is “it depends.” Don’t worry, I’m going to explain what it depends on and how you can figure out whether or not it makes sense for you to get a certification.
First of all, I want to admit up front that I’m skeptical about programmer certifications. I’ve seen excellent programmers with certifications and I’ve seen far from excellent programmers with certifications, so I don’t believe having a cert tells me very much about whether you can code. That said, it’s not going to hurt you to have a certification on your resume, so if you have access to funding for retraining or anything, go for it!
What I believe most people really want to know when they ask if they should get a certification is “Will it help me get a job?” The answer depends on what companies in your area want, but fortunately, that’s really easy to figure out. Research! Hey, I didn’t say it was going to be fun :) What companies want is not some big secret, it’s going to be directly in the job descriptions they post. The trick here is not to look at two or three postings from companies you’re already interested in and call it a day. You’ll get a much more complete picture of the qualifications that companies in your area want if you look at a wide range of jobs both at your current level and above it – you’re not planning to be a junior forever, are you?
Another way you can research is by going to user groups and meetups and asking around. People who already work in the industry are going to be able to tell you things that aren’t in job descriptions, like “the last person company x hired who didn’t have a certification was the boss’s niece” or “company y’s job description mentioned certifications were a nice to have but they were actually perfectly happy with my example code”
Speaking of interviews, they can be a reason to get a certification even if local companies don’t specifically ask for them. If having a certification would make you feel more confident and you can get one for a reasonable price, go for it. The more prepared you feel going into an interview the better you’ll do answering questions, which a cert can help with even if you never get asked about it directly.
Whether you should get a certification also depends on what kinds of credentials you already have. If you have a programming related degree or diploma, I wouldn’t worry about getting certified unless local companies really want certified employees. If you’re trying to switch careers, a cert could really help and is likely to be a lot cheaper than going back to college or university.
It’s a little bit of a tangent, but something certs can legitimately be really helpful with is telling you what to learn. It’s totally overwhelming to do a couple of tutorials online and learn just enough to freak out about how much more you have to learn. Certifications can narrow that down by giving you a nice tidy list of stuff you should know. Fortunately, you don’t have to actually get the cert for that, you can just read the list of topics the exam covers and learn them on your own. Then you can prove you know them by building something that uses those concepts and/or writing about them. As a bonus, nothing convinces an interviewer you can code like showing them your code.
Should you get a certification? Will it help you get a job? You can find out yourself by reading job postings and going to user groups and asking around.
I really enjoyed this post about how Queues Don’t Fix Overload, it does a great job of explaining why bolting something onto your application without digging into the root cause of your problems will just make things worse in the long run.
Bonus link: I found that post in the Programming Beyond Practices newsletter by Gregory Brown, which I also recommend. Have a look at the archives, there’s some good stuff in there.
Unrelated image from pexels.com to make this post look nicer in social media shares.
Not long ago I read this blog post Why Learning to Code is So Damn Hard, which makes a really interesting point about the “desert of despair” between beginning to learn to code and having the skills to build a complete project on your own. The desert of despair, according to the post (which I agree with) is a combination of lack of resources for learners who are between beginner and expert, and having learned enough to know how much you still have to learn. Many aspiring coders get lost in the desert of despair and never find their way out.
I also read Amy Hoy’s post 5 Things I Wish Somebody Told Me Before I Founded My SaaS. One of the points I found the most interesting was that there’s always another inflection point. By inflection point, she means “those knife-edges you tip toe along, when things could go either way, when you are, say… trying to grow your team but lack the time/revenue to do it, but growing your team would help increase the time/revenue to the point where you could grow your team. Ouch. To me, that’s the prototypical inflection point.”
Where this ties back to the other post is where Amy says “Over the last 8 years running this biz, I have said so many times: “We just have to get through this $INFLECTIONPOINT and then things will get easier.”” Doesn’t that remind you of programming?
If I can just learn enough to get my code to compile then things will be easier.
If I can just learn enough to add a feature to an existing project then things will be easier.
If I can just learn enough to start a project on my own, then things will be easier.
If I can just learn enough to break my code down into good methods, then things will be easier.
If I can just learn enough to break my code down into good classes, then things will be easier.
If I can just learn enough to break my code down into good layers, then things will be easier.
If I can just learn enough design patterns, then things will be easier.
If I can just learn this new framework, then things will be easier.
If I can just learn this new style of programming, then things will be easier.
If I can just build enough different projects, then things will be easier.
If I can just learn enough…
There’s always going to be something else to learn, it’s never going to become easy and stay that way. Things do get easier once you find your way out of the desert of despair, but initially learning to code just leads to worrying about whether your code is good leads to worrying about design and architecture and scalability and reliability and security and those are seriously hard problems.
Despite how it may sound, I’m actually not trying to say that coding will suck forever and you should just give up. I’m saying that it’s normal to feel like you still suck at this even after years of working as a programmer. You don’t actually suck, it’s just normal to feel that way. What’s really happening is you’ve levelled up. When you do that you see the problems that used to give you trouble as too simple to count and focus on the stuff you aren’t good at yet, which can easily make you think you suck.
The thing I struggle with is design. I’ve been at this for ten years now and I’m still never sure if I’ll regret the design I’ve come up with the next time we add a feature to the system. Plenty of times I’ve come up with something that seemed like a good idea at the time, only to find out that it had serious flaws when I came back and changed it later.
It’s tough sometimes but on the upside, you will never ever run out of things to learn as a programmer :)
Remember that delightfully sweary “F*ck that, an honest meditation” video? It’s an Android and iOS app now! As silly as it sounds, it really does help me relax. I find that relentlessly cheerful “everything is great!” guided meditations just annoy me when everything is not great, even if “not great” is sometimes as minor as having fought with a badly documented API all day. The F*ck that video and app really work for me because they don’t lie about everything being great, they tell you that you can be okay even when things suck. Plus, who doesn’t love a guided meditation that refers to your life as a three-ring shitshow?
The app itself is very basic, you choose a meditation length from two to fifteen minutes and that’s it. It’s also only $2, so why not give it a shot?
Unrelated image from pexels.com to make this post look nicer in social media shares.
Much like development is maintenance and a creative field, development is also communication. One of the hardest problems I’ve run into with programming isn’t the programming itself, it’s making sure I’m actually building the right thing and fully understand the requirements.
Just because it’s obvious to you that a feature should work a certain way doesn’t mean it isn’t equally obvious to someone else that it should work a different way. Not that I’ve ever gotten burned by that or anything ;) As overly simple as it sounds, it can be really helpful to talk your plan for building a feature over with the person who came up with the requirements and your team lead. Something as simple as having a quick chat about how you’re going to build a feature can uncover assumptions you’ve made that aren’t right or things you missed or even existing code you didn’t know about that could really help.
If you’re working directly with other developers on the same project, it’s possibly even more important to communicate with them. At the very least you need to figure out who does which piece and how your code will work together. If you can divide a project into nicely separated pieces with an interface or API between them that definitely makes things easier, but you still need to keep in touch. Interfaces can change as you build and discover what you actually need, parts of the project can be delayed, there are all kinds of things other people on your project might want to know about.
Even if you’re not on the same project, it’s still useful to communicate with your team. If nothing else, your team lead needs to know how your task is going so they can get ready to assign you more work or re-assign a task they were going to give you if you hit a snag.
Stubbornness is more important than intelligence or talent when you’re learning to code, but that doesn’t mean it’s useful all the time. Listening to other people’s ideas is just as important as refusing to give up. It’s tempting to stubbornly insist on doing things your way, but that’s only going to hurt your project and piss off your team. An idea being yours doesn’t mean it’s the best way to do it. Of course, another dev, even a more senior one, having an idea doesn’t magically make that one perfect either, that’s why it’s so important to talk things out. It’s nice when you get to implement your own ideas, but it’s best for your project if you implement the best ideas you have available, whether those came from you or from someone else on your team.
Whether or not you actually take their suggestions, it’s really important to listen to your team. Despite what you may have heard, software development involves surprisingly little coding in a basement far away from all human contact. Professional software development is fundamentally a team sport, very little of it is so small that a single person can build and maintain an application by themselves. Working with a team means you need to get along with them and listening to them is a big part of that. If you bother asking for anyone else’s opinion, you need to give it a fair shot and seriously consider implementing it. If your mind is already made up, do the polite thing and don’t waste people’s time by asking for opinions you’re not actually going to listen to.
The preceding rant is brought to you by the many horror stories I’ve read online about people who label their listening problems someone else’s communication problem. Listening is communication. Without it, no information gets shared.
Communication skills are at least as important as hard development skills if you want to make a living as a developer. If I had to choose just one, I’d say communication is more important. Someone who will listen to me and explain what they’re doing can learn to code or code better. There’s nothing you can do with someone who can’t communicate. That doesn’t mean you have to be perfect at it – I’m certainly not – just that you’ve got to try.
Redis has a few commands that are dangerously similar. Two of them are rpush and rpushx. rpush appends items to the list at the given key, and creates a new list if the key doesn’t already exist. rpushx, on the other hand, appends items to the list at the given key if and only if the key already exists. If that key doesn’t exist, nothing happens.
If you use redis for anything, make sure the command you’re using is really the command you thought you were using. Learn from my mistakes, it could save you hours of swearing at your unit tests :)
Before we talk about how a binary tree works, we should probably talk about what it is. A binary tree is just a tree data structure where each node has at most two children. Thank you wikipedia :) There’s nothing preventing you from making a tree where each node has more than two children, it just wouldn’t be a binary tree. A tree, binary or not, isn’t necessarily sorted either.
A tree works a lot like a linked list, each node has references to its children, allowing you to walk down the tree. You can also implement a binary tree using a plain old array (see the picture to the right), but that can waste a lot of space if your tree isn’t both balanced and complete. Balanced, when we’re talking about trees, means both sides have the same number of nodes (or at least close to the same number), and complete means that on each ‘level’ all the nodes are filled in. In the example binary tree below, it’s not balanced because one side has 5 nodes and the other only has 3, and it’s not complete because there’s one node missing on the third level and two or three nodes missing on the fourth, depending on whether your definition of ‘complete’ allows for any leaf nodes on the right-most end of the last level of the tree to be missing. That doesn’t actually have much to do with the rest of this post, I just thought it was nifty :)
A binary search tree is a special case of tree where each node has 0-2 children and the nodes are sorted so that you can perform a binary search. In my post about how a binary search works, I mentioned that binary trees aren’t actually the fastest data structure to use for a binary search because it’s hard to balance a binary tree.
How do you balance a binary tree, anyway? Well, if you sorted all of your items before you added them to your tree, then you could start with the item in the middle, then add the middles of the two halves, then add the middles of those halves, and so on until you’ve added everything. That method only works if you already have all of the items you’re going to put in the tree and can be bothered to sort them, though. What do you do if you need to add more items later?
Basically you need to re-arrange your tree until it’s balanced (or at least close enough) again. Some of the ways you can do this are with self-balancing trees like red-black trees or AVL trees. Both of those trees add some extra data to each node to help it both figure out if it’s out of balance and get it back into balance.
In red-black tree, the extra data is the “colour” of the node. Because there are only two colours this only takes one extra bit to store. The colours, by the way, are totally arbitrary so don’t knock yourself out trying to understand the deeper meaning behind them :) According to one of the inventors of the red-black tree, red and black were the colours that looked the best on the laser printer they had available, which they were eager to use since they worked at Xerox PARC where the laser printer was invented.
A red-black tree uses the following rules to keep itself from getting badly unbalanced:
A node is either red or black.
The root is black. This rule is sometimes omitted. Since the root can always be changed from red to black, but not necessarily vice versa, this rule has little effect on analysis.
All leaves (NIL) are black.
If a node is red, then both its children are black.
Every path from a given node to any of its descendant NIL nodes contains the same number of black nodes. Some definitions: the number of black nodes from the root to a node is the node’s black depth; the uniform number of black nodes in all paths from root to the leaves is called the black-height of the red–black tree.
Red-black trees do some funny business with their nodes – what you would think of as a leaf node actually has two leaves that are always black and don’t contain any information. If you’re wondering “well if they’re always black and don’t contain any information, can’t I just pretend they exist and not waste memory on them?” the answer is yes, you can totally do that.
The thing with the pretend leaves is that you need them for the third rule about leaves always being black. When you add a node to a red-black tree, you don’t add it as a real leaf, you add it to the closest node that has a value and then pretend it has black leaves. For the first couple of nodes after the root, this is super simple – the root is black, the new nodes are red, their pretend leaves are black, and everything is good. If you have more than a couple nodes in your tree, things get complicated. That’s where you break out rotations. Because this post is already pretty long I’m going to refer you back to the wikipedia article on red-black trees and this youtube video by OnlineTeacher. Normally I kind of loathe videos, but the pictures in that one are actually really helpful. Tree rotations are one of those things that are really simple when you can see them and really, really confusing when you have to describe it in words. The short version is that because of the way binary search trees are arranged, you can rotate notes back and forth around the root of your subtree, which is going to make precisely no sense unless you already know what I’m talking about :)
And finally, because I keep hearing about it as an interview question, how do you reverse/invert a binary tree?
First, let’s define what reversing a binary tree actually means. Before I looked this up I thought it had something to do with swapping the root and the leaves, which makes no sense because tree structures normally have only one root node. It turns out the question actually means swapping the left and the right children of each node.
If you work with javascript, you need to try JetBrains WebStorm. It has a bunch of really great features I don’t use (I hear there’s support for node and angular and typescript) and sweet, sweet auto complete :) I still wish it was possible to have strongly-typed Eclipsey levels of auto complete with javascript, but something is much better than nothing. It doesn’t always work perfectly, but WebStorm is pretty good at taking you to the definition of a function or object too.
Full disclosure: JetBrains changed their licencing scheme not so long ago and it’s really confusing now. You do not have to keep paying forever! Once you’ve paid for 12 months you get a perpetual fallback licence that gives you only security updates but your product still works.
Either way, you can try it out for free, so why not give it a shot?
ps If any readers know of a better JS IDE I would absolutely love to hear about it.
