Building complex programs is just a matter of breaking it down into smaller units, and then putting them together. Unit testing is the testing of those smaller units. If you haven’t written unit tests for your code yet, you should. It’s worth the effort. It helps you think through the expectations of your code in an organized way, minimizes risk and effort when changing that code, and encourages modular design — which has its own benefits.
Good code editors generally all share some common features such as syntax highlighting, tabs for editing multiple files, automatic tabbing to keep the same indentation level, and of course auto-completion. Notepad++ is a well known code editor that’s lightweight and extendable. Many people don’t realize, though, how to turn on auto-completion for this editor and ask me how I do it.
Recently, I went over Dependency Injection to help you understand a simple way to decouple your code a little bit and help your testing out. Sometimes, though, in Node.js a module will depend on a system API provided by Node, which can make it pretty difficult to make sure that private dependency is being used properly. Normal dependency injection doesn’t work in this situation, but don’t give up hope just yet.
Every JavaScript developer knows that events are quite normal in JavaScript and that an event-based system can be quite fun and simple to use. Most even use event mechanisms almost every time they write JavaScript, but have you tried taking it to the extreme? What does it look like when you have an application architecture that rarely has two objects communicating directly with one another?
When looking through design patterns that help to decouple objects in your applications, one of the simplest techniques to use is dependency injection. This is a common practice in Backbone.js, most notably when assigning models to views, but I haven’t seen it as much as I think I should. Here I’ll be examining what dependency injection is, how it helps, and how I’m putting it to good use in my latest project.
Last week, we looked at the basics of using Socket.IO. As we went through that, we discovered that Socket.IO affords us a very simple API based entirely off of sending and receiving messages and being notified of those messages through events. Well, there’s more to Socket.IO than that. It has several advanced features that can come in very handy in certain situations.
WebSockets are starting to become available in more and more browsers. In fact, at this point in time, pretty much the latest version of every browser supports it according to Can I Use. The best part, though, is that you don’t even need a modern browser with WebSockets available in order to utilize the real-time back-and-forth communication between the browser and server that it offers. Socket.IO will show you how it’s done.
The “good old days” are behind us. We no longer have the luxury of having so little JavaScript code that we can do it all by hand in Notepad. In fact, the amount of JavaScript being sent to the client per page has increased quite dramatically from not so long ago. We can’t afford to write everything by hand anymore, which is where all of these tools and libraries come in handy.
Many people come to JavaScript from other object-oriented programming languages such as Java or C++ and are confused as heck. “Where are the classes?” Well JavaScript doesn’t have classes. Rather, JavaScript uses prototypal inheritance to create something similar to classes. Though it is somewhat similar, it’s still quite different and takes a lot of work to understand. That’s the purpose of ES6 Classes.
I have never heard of a language that doesn’t use variables, and JavaScript is definitely not an exception to that. Variables are handled differently in each language and to become a true JavaScript expert you’ll need to understand how JavaScript handles variables too. For the most part it’s very straightforward, but there are plenty of “gotchas” you’ll want to be aware of.