Defensive Programming in JavaScript - Lately in JavaScript podcast episode 53

Contents

Introduction (00:20)

Motion Sensing using the Doppler Effect (0:58)

Unblocking JavaScript to Allow Page Indexing by Google (6:24)

Comparison of JavaScript Linting Tools (11:18)

The State of Chrome DevTools (15:34)

New JavaScript techniques for rapid page loads on Chrome (18:04)

Defensive Programming in JavaScript (20:43)

Nudity Detection with JavaScript and HTML5 Canvas (31:53)

JavaScript Innovation Award Winners of January 2015 (34:30)

JavaScript Innovation Award Rankings of 2015 (36:12)

Conclusion (37:53)

Contents

Listen or download the podcast, RSS feed

Watch the podcast video

Read the podcast transcript

[Music]

Manuel Lemos: Hello. Welcome to the Lately in JavaScript podcast. This is episode 53, and as always, I have here with me, Arturs Sosins from Latvia.

Arturs Sosins: Hello.

Manuel Lemos: It seems to be warm over there, right?

Arturs Sosins: Oh, it's getting warmer, yeah.

Manuel Lemos: Yeah, probably warm for you.

Arturs Sosins: Already over ten degrees-plus Celsius, so it's warm.

Manuel Lemos: Hoohoo! Ten degrees.

[Laughter]

Manuel Lemos: Over here, ten degrees is very cold.

Motion Sensing using the Doppler Effect (0:58)

Manuel Lemos: Well, but we are here to talk about JavaScript, and we are going to start talking precisely about a very interesting library. I've never seen a library doing something like this. And to be honest, I was not able to replicate the claims.

It is based on a paper that talks about using the Doppler effect to detect motion. Well, if I remember correctly, the Doppler effect is about sound being emitted by moving objects, and as the objects get closer or farther, the perception of the frequency is changed. The idea here is take advantage of that effect to detect motion.

And if I got this right, actually, the author of the article wrote a library that can emit a noise, inaudible noise, of frequency of 20 kilohertz. You wouldn't listen to that noise, but if you have your computer emitting the noise, then have your microphone capturing the noise, anything that affects the distance that the sound travels, it would alter to the perceived frequency of the sound wave.

So, as they showed here, in this animation, the guy in the image is playing, is moving his hand. And since the library that he developed detects changes in the frequency, he translates those changes in frequency as movements that he uses to scroll the page.

Now, I've never seen anything like this. Arturs, what do you think of this library?

Arturs Sosins: I was actually really, really impressed by it. I also tried it. It seem to work, at least for scrolling for me. I was impressed that you could really go to this web site and try it, and you don't really have to do much.

Couple of things to note when you try it... first thing is that there would be a small pop-up above that you should allow accessing microphone for this Web site. Second, you need to know where your microphone is to wave it because you basically need to put your hands before your microphones, so the sound trails. So some inconsistencies are served.

It's not just like in the video; you wave above the keyboard. You just need to wave before your microphone was somewhere near the camera. So I tried to find it. I tried waving above the keyboard, nothing happened. I waved around the camera, and starts scrolling. At least, that one worked for me. It was really impressive.

I imagined if you calibrate it properly for a specific microphone, you can achieve much more.

Manuel Lemos: Yeah, I think you need to use some speakers, not headphones because headphones will not emit the sound loud enough for the microphone to capture.

Arturs Sosins: True. And you also, if you also put your speaker somehow and your microphone on the best sensitivity, you can because it's really all about what your microphone have. If you have a strong microphone, like I have in my notebook, it should work great.

Manuel Lemos: Yeah. Well, I've tried it, and it start bouncing around by itself without any movements. I guess there was some kind of environment noise that was causing it. Well, this is interference that would prevent the library to detect what is really the song that is being emitted or not.

But I think the idea is brilliant. I have never seen something like this. It just proves that anything is possible in JavaScript these days.

Arturs Sosins: Especially with the new HTML5 APIs for browsers, lots of new possibilities.

Manuel Lemos: Exactly. This one just requires that you have access to sound and microphone.

Unblocking JavaScript to Allow Page Indexing by Google (6:24)

Manuel Lemos: OK, moving on with the next topic. We are talking about something indirectly related with JavaScript. Recently, Google announced that they will be starting to index differently or at least rank differently pages that provide good experience for mobile users or not.

So if you have a page that renders fine for desktop users, but it doesn't render fine for mobile users, it won't rank well when the users are searching it for things in mobile devices.

But for Google to determine if they are able to render pages well, they also need to render parts of the pages that rely on JavaScript blocks. For instance, widgets that run on the page that if JavaScript is disabled, they probably won't load, but they need to load to be rendered.

And if you have your robots.txt file blocking those resources, Google can't retrieve those resources and so, it can't render the page well.

So they have announced here, in this article, that starting this month... actually past month, March... they will have a report in the Webmaster Tool site where you need to log in and review that report for your site. You need to show the URLs that are being blocked and prevent Google from rendering the pages.

This is very useful. I realized I have certain pages, certain URLs blocked. They were used to render internal ads using JavaScript, and so I had to unblock them.

Arturs Sosins: But why? Why was it blocked?

Manuel Lemos: Because it didn't serve any new content, just advertising. Each user would see a different thing. Now, Google wants to retrieve it and see what is there, put it in place. Maybe it's an image or some text or something. Now, they have these reports to help you solve that problem, so it won't affect your search ranking.

It's not just JavaScript. It could be CSS, could be iFrames, could be anything that is inline in the page. You just need to go there. They show a report like this, and then you click here on this link, and you'll see the pages that are affected or not, what pages need to be changed, to be unblocked.

Now, for instance, if you didn't want Google to index those resources, you can just unblock them in robots.txt, and then serve them with meta tag "no-index". Or there is an equivalent header "no-index" that can help you to prevent Google to index things that are not really content to be displayed in search results.

So this is an interesting news, and it is indirectly related with JavaScript. So if you are concerned with being ranked well in Google, you should take a look at these tools because there are various ways to solve these problems.

Comparison of JavaScript Linting Tools (11:18)

Manuel Lemos: OK, now moving on to another topic, this time an interesting article comparing Lint tools. Let me share it here. So, for those that are not aware what are lint tools, such are just tools that analyze your code and point possible mistakes that you might have had.

I've been using a couple of these tools that they mentioned here... JSLint and JSHint... and they've been very useful to prevent some kinds of bugs or at least annoyances. Sometimes, I forgot to declare a variable as local, and it tells all about all the variables I should have declared. It's just definitely an example.

About the other two JSCS, I was not aware. The other one, the ESLint, I'm not sure if it is not derived from...

Arturs Sosins: ECMAScript?

Manuel Lemos: Yes. But I'm not sure if it was derived from JSLint. Anyway, I have not used it either, but it's supposed to also support ECMAScript 6.

Arturs, do you usually use these tools?

Arturs Sosins: Yes, basically, in our continuous integration systems, automated testing, linting is the first thing to do. I think I actually went in the same order that was here. I tried JSLint, and it was very limited. It had specific presets, and you could not really configure anything.

So next thing I tried was JSHint. It was basically, you can configure anything you need, any warnings there. It also work with Node.js and other libraries that basically I use, so I stopped at it, and we are using JSHint till now. It's great. I didn't even try the rest of the things.

Manuel Lemos: Well, I always try both because there is hope that if one doesn't catch one thing, maybe the other catch it. But about this other two, I didn't know. Well, I'm not doing anything with the ECMAScript 6... at least for now... but this other JSCS, I think I'll take a look later when I have more time to investigate.

I don't know about this too, but one thing that I like about JSHint and JSLint is that they have an online version that they just can quickly paste some code and figure any errors.

And sometimes, there are errors that it complains that I don't want to be considered errors. I can also allow those errors as they call them, because for me, they are not really, really errors, just things about style, I think. Things like that.

But I think it's great to always have more tools because any new tools that appear gives ideas to the authors of the others, so they also improve their tools to match up at least in features.

The State of Chrome DevTools (15:34)

Manuel Lemos: OK, now moving on to another topic. I just want to mention briefly, there is this talk by Addy Osmani that happened in jQuery UK Conference 2015. There is a link to the video here. I watched at least part of the video, and it is basically to mention about the improvements that are coming to Chrome Developer Tools.

Arturs Sosins: Can you mention the specific features?

Manuel Lemos: Well, they talk mostly about things that can help you improve the performance of your code, but it's better to watch the talk, so you can learn all about the details.

One thing that I learned... I'm not sure if it was already possible, but if it was not possible, now it is possible... sometimes you have a library that is minimized and now, there is a button that you can click and it prettifies the code so that code can be readable. So I thought that was very interesting.

I don't know, did you know if that feature was available?

Arturs Sosins: No, I've never heard of that thing, but it seems interesting.

Manuel Lemos: Yeah, because sometimes you have errors you don't know, you can't take in mind the code because it's all...

Arturs Sosins: You get error on line 1, character 3,400 or something, and you can try to scroll and find it. Yeah, that actually would be really helpful.

Manuel Lemos: Yeah, well, I'll mention the page of this talk in the Show Notes. I forgot to share the screen, but there's a video about it. It's in the site of the talk, but anyway, we are not going to watch it now, of course.

New JavaScript techniques for rapid page loads on Chrome (18:04)

Manuel Lemos: Moving on with another topic, just to mention briefly something that is related, again, with Chrome. Basically, it is a couple of improvements that they are planning to implement, starting with Chrome 41.

One is that they now will start parsing JavaScript code in parallel, while the code is being downloaded, so they may be able to gain some time while the code is being downloaded, probably, from a slow source. That was one of the improvements starting Chrome 41.

Starting Chrome 42, they will be doing something that I thought they were already doing, which is caching the compile JavaScript code of all pages. For instance, if you got back to the same page and the code did not change, they will not compile it again. That is good if you keep visiting different pages.

Arturs Sosins: What happens if different pages use the same script from the same source?

Manuel Lemos: Well, I don't know what is the logic here. I suppose they have to be careful to not assume that the same JavaScript code is loaded always in the same page every time you access because it might not be the case. But well, I'm sure this has been thoroughly tested, and they are being careful enough to not make mistakes and run the wrong cached version.

Arturs Sosins: Yeah, and as you see from the text, it actually says that it also provides improvements for mobile devices to save precious battery rather than you would notice the difference in desktop.

Manuel Lemos: Yes, not just speed but also battery because it will save you CPU time.

Defensive Programming in JavaScript (20:43)

Manuel Lemos: OK, now moving on to another article about something that personally, I think is a good idea, which is to talk about techniques of implementing what is called defensive programming, in this case, defensive programming in JavaScript.

The idea of defensive programming is to implement approaches that will prevent certain errors to happen, what is help to prevent, because it may not work all the time. But if you use defensive programming techniques in any languages, chances are that your code will be more robust.

The first thing that they recommend is picking a lint tool, or maybe more than one lint tool. I tried several lint tools on same code in order to get more warnings about things that may be wrong. As we already mentioned, using lint tools is a good idea.

Arturs Sosins: But also, I suggest to use it like in the editor, so it would be like in a real-time, while you're writing code, it would already find the mistakes before you even make them.

Manuel Lemos: Yeah, it could be. As long as you use a lint tool in real-time, while you're writing or not, it doesn't matter. As long as you use it, I think it is always a good measure.

The next recommendation is to use encapsulation everywhere. So they are suggesting to use a private variables that functions to access those private variables rather than using them. I supposed this is meant to avoid that you, for instance, type the wrong variable name and assign it, and the variable didn't exist.

And if it is a new variable, and you are changing different variable than you thought, that an error may go unnoticed. So if you can encapsulate the access with those variables, if you call a function that does not exist, it will result in an error rather than just accessing the variable that has the wrong name.

Well, that's all what I got from this suggestion.

Arturs Sosins: Also if you create a global variable, some other library can use the same name and modify the value underneath, then you will be looking for a box and never find it. Why is something random happens, for example.

Manuel Lemos: Yes, that may happen, too.

Their next recommendation is let those variables be constant. In this case, they are suggesting to... Well, I'm not sure if I got this right. They are suggesting that if you use a variable to make some calculations and change its value, probably you'll run into errors.

Well, I don't think this code here that they show is the same.

Arturs Sosins: Yeah, you will return different value, but...

Manuel Lemos: Yes, because sum will not be altered in here. And here sum it is altered. I'm not sure what was the purpose here, because it's not just to better or worse. It's different. Maybe I need to read this part of the article again. I don't know what you got from this.

Arturs Sosins: Nothing much, too. More of code maintenance kind of site that somebody else... If you are modifying the variable in a large code block and somebody else after you uses it, it expects you to do like the initial variable and doesn't know if it was modified or not, something like that probably. It could create new variable so other could use it.

Manuel Lemos: Yeah, could be it. Well, moving on, the next, they say immutability matters. Basically, what was here is that you are in a loop and you are altering a date by adding some time, but it uses a new object every time it iterates this loop.

But, in this example, they suggest to use an object that allows you to have time without creating new object. So this would probably save memory being faster.

Arturs Sosins: But underneath, I think it's all the same. The wrapper would have to recreate objects, wouldn't it?

Manuel Lemos: I don't know because this is a new class called 'moment'. It's not the same. Internally, I don't know what it does.

Arturs Sosins: Unless it's always towards an integer timestamp and convert it to date when it's needed or something like that. It also could be that.

Manuel Lemos: Yeah, probably. OK, the next recommendation is string concatenation. I think this is problem that the + operator can give different results depending on whether you have strings or have numbers.

Arturs Sosins: Integers for that. This is the main thing that every stronger type language programmer dislikes in JavaScript or PHP, that our arithmetic operators are also concatenation. Usually, it's not... In PHP, it's dot, and then, JavaScript, unfortunately it is the same. So it may be misleading.

Manuel Lemos: Yeah, well, so they suggest we use some explicit string just to provide that result to...

OK, the next recommendation, Where there is an if... I think this is to prevent that you run into undefined behavior because you did not consider all the other cases. So this could be applied not just to if statement but also switch case. You should always have a default, even if the default is an invalid case; maybe you should throw an exception or something.

In this case, if you run this code like this, if the condition is not true, it would be assigning the value to the default value. It would be the same code, but they suggest that you use this style better.

Arturs Sosins: I would disagree. I don't know, I like the first much more if you define variable just before the condition. You either way need to initialize it with var so it would be in the same scope, so why not keep it valid? And by less code, it has branched... This is probably one I disagree with in this article.

Manuel Lemos: Well, if you use this style and the condition is true, you'd be assigning the variable twice.

Arturs Sosins: Yeah, it is intended. So I have a default value, if it's something other, then I change the value. But default will always be assigned once in initialization. I think that's the best way.

Manuel Lemos: Yeah, I think they meant this in general case, not just the initialization. Maybe you do other things inside the condition statements that there should always be a behavior defined for when the case is not true.

OK, the next recommendation is to always wrap blocks with braces. Well, you need to type more code, more braces, but sometimes, it saves you from making some kind of confusion. I suppose that does not make sense.

Arturs Sosins: Simple mistake here would be comment out foo and it would execute var only in that condition.

Manuel Lemos: Exactly. That could be one possibility of a wrong behavior.

Well, the last thing is just only the paranoid (and defensive) survives. It's just the comment of the author. In general, well, although know if you need to be paranoid, but if you are defensive, the problem with this is the cost of developing and maintaining your code. If you adopt certain practices that will help you to catch bugs before they cause damage in production.

Arturs Sosins: I would not wait any other reply from you, since I heard that you're using both JSHint and JSLint in your code. It seems that you are defensive also.

Manuel Lemos: Now, I'm going to use the other two.

[Laughter]

Arturs Sosins: Oh, my God.

Manuel Lemos: Yeah. Now, you can leave.

Arturs Sosins: That's paranoid, that's not defensive.

Manuel Lemos: I'm sure there are cases that want to protects and the other doesn't.

Arturs Sosins: Exactly. That's called paranoid.

Manuel Lemos: OK, that's an opinion.

[Laughter]

Nudity Detection with JavaScript and HTML5 Canvas (31:53)

Manuel Lemos: Finally, we have an interesting article about a library that is supposed to be able to detect nudity in images using JavaScript HTML Canvas objects. So basically, what it does is to analyze a picture and somehow check whether it contains nudity or not.

There is a demo with predefined images, so you can click here, and let's say this one is not nudity. This one is not nudity.

Arturs Sosins: If you could share the screen, it would be better.

Manuel Lemos: Oh!

Arturs Sosins: Or there are pics that you don't want to show us?

Manuel Lemos: I forgot. It was obviously not intentional. What I'm talking about...

Arturs Sosins: Yeah, let's make the podcast safer.

Manuel Lemos: Well, I don't know. Sometimes, publishing in YouTube, you could get a report, "Oh, you're showing nudity."

OK. So this is the library, nude.js. The examples that I was trying to show is the demo pictures. This one. That's the start. This one, it says not nudity. This one, it says it's not nudity. This one, it says not nudity. But this one, it says it's nudity.

So at least with the test pictures, it works. How it would perform in real world pictures, I don't know. I have not tried it. We wouldn't have the time. But I think it's an interesting library.

Arturs Sosins: Especially, as it down in the client side in your browser. That's impressive.

Manuel Lemos: Yeah. I think it can be useful for many sites that need to accept pictures from users, but there could be some abuses of users sending nude pictures and cause problems to the site users. I think this is useful.

JavaScript Innovation Award Winners of January 2015 (34:30)

Manuel Lemos: Well, now, it's time to move on with the regular section on which we comment about the Innovation Award of the JS Classes. We'll talk about the winners of January that were voted in February, and then, in March, the results came out.

So in January, unfortunately, there was only one submission. Unfortunately, this is just what we got that month. It was actually a very interesting application called Call Me.

It can establish video chat communication between users. It was written by Andras Toth from Hungary. It was very, very interesting, and I think everybody should try it because it is very neat to see video chat working on a browser which is done in pure JavaScript, although it relies on the service called PeerJS.

And for this, Andras picked one book of choice, a Packt.

JavaScript Innovation Award Rankings of 2015 (36:12)

Manuel Lemos: Well, even this, in spite in January, there was only one nominee, the current Innovation Award ranking already takes in account also the nominees of February. Guess who is in first place?

Arturs Sosins: Really hard to guess. It was not intentional. It was not intentional.

Manuel Lemos: Yeah. Arturs is leading now the ranking with just one package, but got three points; followed by Ovidiu Bokar from United Kingdom with one package and two points; then, Jason Gerfen and Andras Toth with one package and one point.

By country, it's also nothing surprising because it's practically the same ranking of the nominees. Latvia is in first with one package and three points; then United Kingdom with one package and two points, and then United States and Hungary with one package and one point.

Well, fortunately, then in March, there is some more nominations, so I hope this JavaScript Innovation Award gets more interesting, so we can talk about it next month.

Conclusion (37:53)

Manuel Lemos: So with this, we practically ended this podcast. We covered several interesting news and libraries about JavaScript. I would just like to thank you, Arturs, again for coming.

On my behalf, that is all for now. Bye.

Arturs Sosins: Bye.

[Music]