Improving the Quality of Your JavaScript Code - Lately in JavaScript podcast episode 24

Show notes

Download Size: 31MB Listeners: 1868

Introduction music: Riviera by Ernani Joppert, São Paulo, Brazil

RSS 2.0 feed compliant with iTunes:

http://www.jsclasses.org/blog/category/podcast/post/latest.rss

Watch the podcast video

Note that the timestamps below in the transcript may not match the same positions in the video because they were based on the audio timestamps and the audio was compacted to truncate silence periods.

Show notes

• Article on Increase your JavaScript code quality with JSHint

• JSHint project

• Article on Acorn and other JavaScript parsers

• Article on Top 5 JavaScript testing libraries

• VMWare JavaScript scripted editor

• Article on Unobtrusive JavaScript

• Article on Making Node.js work in your RaspberryPi device

Read the podcast transcript

Contents

Introduction (00:20)

Find Problems in your JavaScript Code with JSHint (2:22)

Acorn and other JavaScript code parsers (11:10)

Top 5 JavaScript Testing Libraries (13:48)

Scripted JavaScript Code Editor (27:08)

Unobtrusive JavaScript Programming (37:39)

Making Node.js work on a RaspberryPi device (43:09)

Latest JavaScript Objects Released on the JSClasses site (44:29)

Upcoming Articles on the JSMag magazine (51:01)

Conclusion (54:50)

Introduction (00:20)

Manuel Lemos: Hello. Welcome to the Lately In JavaScript Podcast. This is episode 24. And as usual, I have here with me, Michael Kimsal, direct from Raleigh, North Carolina, right?

Michael Kimsal: Very much so. Good morning.

Manuel Lemos: How are you doing, Mike?

Michael Kimsal: I'm fantastic, but do you really want to know because I'll tell you.

[Laughter]

Manuel Lemos: Ever been hit by any tsunami waves?

Michael Kimsal: No. No. It's...

Manuel Lemos: It's on the other...

Michael Kimsal: ...it's dismal outside, but I think over that way or maybe it's one of the directions from here towards the coast. They've been getting a lot of rain apparently, yesterday and today, but not much here.

Manuel Lemos: OK. Well, today we are going to talk about the regular batch of topics, things that have been happening in the JavaScript world.

Actually, I want to ask you, Michael, you've been trying Windows 8. Anything related with JavaScript yet that you have tested?

Michael Kimsal: Well, yes and nothing substantial. I got my editing system or I got everything updated yesterday. I'm on Windows 8 Pro, whoa!, and I got Visual Studio Express for the Web installed.

I was going to try to do a bit of JavaScript stuff over the next few weeks, but I've gotten many other things coming up; client deadlines and conferences and things.

So I may have to hold off until November 18th before I dig in. Maybe by next podcast, I will have some real experience with it. It's just fun and nice, I just haven't done much with it so far.

Manuel Lemos: Well, I think it will be interesting because as you mentioned in the last episode, there are some things specific for JavaScript to develop applications on Windows 8. So I think it will be an interesting topic to bring it back when at least one of us has more information about it.

Find Problems in your JavaScript Code with JSHint (2:22)

Manuel Lemos: Well, we're going to continue talking about some interesting topics. This month, I would like to talk a bit about a tool that can somehow improve the way that you work and produce your JavaScript code.

And some time ago, we have talked a bit about JSLint, which is a tool that will help you to eventually find problems in your code. And there is another tool that has a similar, almost very close name, which is JSHint.

Michael Kimsal: Uh-huh, yeah.

Manuel Lemos: I think it's somewhat for the same purpose. I have not tried both tools extensively to compare them, but from what I could understand, they are very similar in giving hints on stuff that you probably need to fix or at least improve.

And I found this article here about JSHint, some new features from Elijah Manor and I decided to take a bit closer to this tool because, well, sometimes you have bugs in your code and for some reason, they did not show up yet.

Michael Kimsal: Oh, sure.

Manuel Lemos: The tool, actually, there is a sort of a playground for the tool online and I tried to paste a class that I've written for myself and it complains a lot about stuff that I'm not even sure if...

Michael Kimsal: I've complained about your code many times. I'm glad they're doing it. Ooh!

Manuel Lemos: I think you are smarter than this tool because it's blaming even about comments.

Michael Kimsal: Well, uh...

Manuel Lemos: Or maybe... no, wait. Maybe I didn't paste this correctly.

Michael Kimsal: It could be.

Manuel Lemos: Let me try this again.

Michael Kimsal: Yeah, I'll try that. Linting and Hinting tools in general, it's still complaining.

Manuel Lemos: Are annoying.

Michael Kimsal: Yeah. Well, I wouldn't say...I mean, they can be annoying. They can be useful for you to get an idea of best practices, styles, things that as you said things that might cause problems later.

The big one for me tends to be cyclomatic complexity, which it looks like this tool covers that idea of saying "I've got a function call. I've got a method call. And it's got nine levels of nested code blocks in it and it's got 30 variable names" and that sort of thing.

It's not just me. I mean, I look at other people's code. I can sometimes write code like that and I have done that and I've left it for other people, but I've found that the older I get, and this could just be that the idea of a tool that measures complexity is just an old person's way of saying "No, you're doing it wrong", but it gives some objective justification for you need to simply your code.

It doesn't mean the code needs to do less, but you need to break this in a multiple methods, you need to break this into smaller chunks of code maybe to facilitate testing.

But even outside of that, the idea of... and this, this is what I get from these complexity testing tools is that if there's a computer saying, "This is going to be hard to understand," and it's nice for me because I find some of these things hard to understand sometimes.

And when there's numbers to prove it, this has a complexity of X and it really should only be half of X, if it's somebody else's code, it makes me feel better like, "Ah, yes, I'm not crazy. This tool is saying it's complex."

And if it's my own code, it gives me something to shoot for to say, "I can reduce the complexity of my code, somehow." So I don't think they're bad, but you're relying on that as your only measure of code quality. It's probably not the best thing to do.

Manuel Lemos: Right. Well, I'm still trying to figure what are these complaints because it is complaining, for instance, right here, which... let me try to increase the font.

Michael Kimsal: That's good, yeah.

Manuel Lemos: It's saying that there is a curly brace...

Michael Kimsal: What's the line before?

Manuel Lemos: Fifty three.

Michael Kimsal: Well, I know the line before 52, but what's on it?

Manuel Lemos: Fifty three, yeah. Fifty three, it's here. Oh, maybe it wants for me to put curly braces here.

Michael Kimsal: You write code that way?

Manuel Lemos: Yeah.

Michael Kimsal: I hate you. I hate you. You suck.

Manuel Lemos: Yeah. I'm not going to heaven, I know.

[Laughter]

Michael Kimsal: End of line 52, put a curly brace.

Manuel Lemos: If I put the curly brace here, it stops complaining. That's what it is saying.

Michael Kimsal: I think so.

Manuel Lemos: Well, it's to shut him off.

Michael Kimsal: See if it that does it, yeah.

Manuel Lemos: Yeah.

Michael Kimsal: And then reparse or relint.

Manuel Lemos: I increased the font so much that now, I don't...

Michael Kimsal: Yeah.

Manuel Lemos: Well, it seems it was it.

Michael Kimsal: Look at that! Wooo!

Manuel Lemos: One blocks. OK.

Michael Kimsal: Another one for special K.

[Laughter]

Michael Kimsal: Yeah.

Manuel Lemos: Oh, now I disabled one complaint and it looks much better now.

Michael Kimsal: Yeah.

Manuel Lemos: Well, I think I need to study this tool better because it is giving a lot of complaints lint that I do not quite understand.

But there are some complaints here that actually clarified one of my doubts. For instance, this one that complains about triple equal sign instead of double equal, let me... well, not just in JavaScript, actually in PHP, I was wondering the triple equal would not be more efficient than double equal.

Well, for those that are not sure what is the difference, triple equal requires that the left and right side matches exactly, not just... well, but...

Michael Kimsal: Well, both down. Yeah, the type.

Manuel Lemos: Yes, the type. So if you compare a string with zero inside with the number zero, the triple equal will not match but double equal will match. And it's the same in PHP and I think, ultimately, the code will run faster if you have triple equal. And the same for different sign that you can use exclamation and double equal instead of exclamation single equal.

Well, this is interesting and no matter how experienced you are, this was also a good way to learn things that probably you are not paying much attention and even if you are very experienced to assume that you write excellent code, and you probably don't.

Michael Kimsal: Well...

Manuel Lemos: You tried to tell me before.

Michael Kimsal: Well, yeah. I mean, you say, well, I write bugs and... well, yeah. For those people that write bugs, these things are useful, but when you're like me [Laughter] it looks like fun.

Manuel Lemos: You don't need... you are above with everybody else.

Michael Kimsal: No. It's not that I never write bugs. I mean, I sometimes do it for fun. I do it to demonstrate to other people how awesome I am and how much better I am than they are, so.

Manuel Lemos: Yeah.

Michael Kimsal: Yeah.

Manuel Lemos: Well, other than that, I also find some warnings here like document write cannot be a form of eval.

I wonder what this mean. Is this sort of potential security warning, security problem like eval could be used to run malicious code and somehow document.write provides that by writing some JavaScript to the page.

Michael Kimsal: I'm not sure exactly what they're meaning and what the issue is with that, but I'm sure you'll study it and figure it out and become a better developer because of it.

Manuel Lemos: Well, the idea here is to just mention JSHint as yet another tool to help you to improve your code. Usually, these tools are very pedantic and probably some of the warnings we'll always ignore because you don't stand a tool that is too pedantic.

Anyway, there is an article here that I'll also post it in the show notes about it from Elijah Manor that covers some of the new features.

Michael Kimsal: Thank you, Elijah. I met him once at a conference. Nice guy.

Manuel Lemos: Oh, yeah.

Michael Kimsal: I met him face to face. Shook his hand even.

Manuel Lemos: Yeah. So now, he qualifies to go to heaven because he touched your hand.

Michael Kimsal: No, no, no, no. Nothing like that. I mean, I think he even needed it more than that, but it was at CodeStock 2009, I think, in Tennessee.

Acorn and other JavaScript code parsers (11:10)

Manuel Lemos: Yeah. Well, this was an interesting tool to talk about and I'm moving on with the podcast I would like to talk also about JavaScript parsers.

Michael Kimsal: Oh, Acorn.

Manuel Lemos: Actually, Acorn is...

Michael Kimsal: No?

Manuel Lemos: Yes, it's just one of those tools.

Michael Kimsal: OK.

Manuel Lemos: Let me screen share here an article that talks about Acorn parser. Well, for people who listen to the podcast, maybe you're wondering why would be a JavaScript parser interesting for anything useful in the real world?

Well, if we have a JavaScript parser you can somehow process your code into somewhat developed tools like this JSHint and JSLint that can be used to evaluate if you are doing something right and some other purposes that can always be useful, it's up to your imagination.

And in this article here they are talking about Acorn and then they also mentioned other parsers like UglifyJS and then ZeParser and Narcissus, Esprima even. There are a few others that I do not recall their names, but they can be useful.

Some of them transform your JavaScript in Abstract Syntax Tree, AST, which is sort of intermediate form of output that is used by compilers to somehow produce code... I mean, compile code in one language and do something useful with it like, for instance, compiling it into another language...

Michael Kimsal: Oh, yeah.

Manuel Lemos: ...or machine code. And this article covers a bit about them. I'm not going to talk much of these because this is very specific to the Acorn parser. But I think for those that feel brave enough to developer tools that somehow could be useful to enhance the quality of the code that you produce or... well, do something useful.

Maybe some interpreter that is more safe that you can run in certain circumstances without risking to compromise your environment security. You could use these JavaScript parsers to do something to improve your code.

Well, anyway, moving on with the podcast.

Michael Kimsal: Moving on already? OK, that's fine.

Top 5 JavaScript Testing Libraries (13:48)

Manuel Lemos: I'm going to move on talking about... there's an article here about testing libraries. Well, if you're following me and I'm trying to cover several interesting articles that have been published recently regarding tools that can improve your code somehow or somehow contribute that you produce better code or at least... oh wait.

[Laughter]

Michael Kimsal: Hey! Who's that handsome devil?

Manuel Lemos: And this is amazing. When you want to do something like that on purpose, I'm never able to make it... let's see. Now, I pulled it out.

Well, as we're mentioning, there is an article from, I think, Jack Franklin, the author here, that compares some testing libraries for JavaScript.

I'm not sure if we can call them the top five. Well, it depends on your point of view, but in his opinion these are the top five in JavaScript testing libraries. And it basically covered Jasmine, QUnit, and Mocha, and Buster.JS, and YUI Test.

Well, I don't know. Michael, do you think this could be called the top five JavaScript testing libraries?

Michael Kimsal: I mean, I was just thinking that and, I don't know, but I'm not sure there is a way of calling anything the top five of any. I think that that field is too broad.

Manuel Lemos: Yeah.

Michael Kimsal: Jasmine, I've noted to be popular amongst colleagues of mine.

QUnit is another. I've used QUnit on occasion. Those are the two that I've used. We actually had a couple of articles on Jasmine in the past in JSMag. Well, no, I should.. yes, I should say I did use YUI Test briefly, not really for anything production, but I've not used Mocha and I've not used Buster.

Manuel Lemos: Yeah.

Michael Kimsal: It looks like Mocha is a... Buster, too, are Node ones. So maybe that's why I've not used them.

Manuel Lemos: Well, from all these, well, I didn't know YUI Test. Well, I'm not a YUI user. Did you use YUI somehow extensively, Michael?

Michael Kimsal: No, it wasn't extensively. This was a few years ago, there was a testing suite that came with YUI 2.

Manuel Lemos: Well, I wonder... yeah.

Michael Kimsal: This looks like it's version 3, so I don't know how much is changed. Probably a lot.

Manuel Lemos: Yes. Well, what I wonder if this is somehow like one of testing... JavaScript testing projects that I feel it's missing here which is Selenium. Is this sort of like back in the library? Probably not.

Michael Kimsal: Yeah. These are more for testing...

Manuel Lemos: Code, right.

Michael Kimsal: ...the code itself and running assertions against the code in inside the browser or maybe in... what's, Node, running a Node headless or something like that. The idea of Selenium would be much more what does the actual browser when it runs it, what is it? And you're going to do assertions against things and comments.

Manuel Lemos: Right. It's not specific to JavaScript. It could be even four pages that do not have any JavaScript at all.

Michael Kimsal: Yeah.

Manuel Lemos: Well, for testing tools, I think Selenium is somehow mandatory because to test your JavaScript code in a real world environment on which you use an user interface, I think Selenium seems to be a good project tool.

Something that I think it is difficult and probably will not work all the time very well because there are all these conditions that change in your browser. But, well, I personally, I'm not a fan of tests not because they should not do it, but because it's boring. It's not my vocation. I'd rather write code than being a doctor and try to fix everything. I'm more a builder than a fixer.

Michael Kimsal: My standard line on testing is you're going to do it.

Manuel Lemos: Yeah.

Michael Kimsal: You're going to do it. Are you going to be doing it at two in the morning on a Saturday, when everything is broken, when everybody can see that everything is broken, and it might be costing you or your clients loads of money, or you're going to do it in the beginning during the development?

Manuel Lemos: So are...

Michael Kimsal: You're going to do the testing.

Manuel Lemos: Are you fond of test-driven development or maybe not so much?

Michael Kimsal: I like the idea of it and I did one small project a couple of years ago that was entirely test driven. I forced myself to do it that way and I got a lot of good out of it.

What I'm finding is that a lot of the projects that I'm on, I'm the soul person and I don't really have the luxury of working with other people to define this and define that and do stuff that I had more luxury when I did that test-driven thing because I was working with a couple of other people that were actually very, very talented, much more talented, one was much more talented than I was on the tech side.

So I could trust that other person and I got to spend some time doing test first. I go through periods where I'm doing tests, not necessarily first, sometimes in JavaScript, sometimes in PHP or Java or whatever it happens to be.

And I find that I go through this period where I do it long enough, I don't know if you can see my screen or not, but I do it long enough, or see my fingers here. I usually do it at the beginning or during a specific time in the project where it helps me define some of the core models and concepts and some of the core functionality.

Once I have enough of that and I know that the tests run and I can make changes in the test I'll run, then a lot of times it's how do I put UI layers on top of that, an API layers on top of that? And sometimes, things change but... and ideally, I would be using tests for everything to write all of it, but I usually just don't have time.

And, yes

Manuel Lemos: Yeah, it's expected...

Michael Kimsal: if I come back to, yes, I am going to be fixing some of these things at two in the morning proverbially speaking, but I feel more comfortable the more tests that I have.

Manuel Lemos: Yes, well, I agree with you basically you just said what I was going to say about it. Ideally, yes, but in practice, no, because it's expensive.

Michael Kimsal: Well...

Manuel Lemos: If you spend a lot of time ahead building tests for first things, they probably will never break because they are very simple and they are not the center, they are not so critical because the code there will not be executed...

Michael Kimsal: But you probably wouldn't need to be writing a lot of tests for those either. If it's something that you trust, if it's already a library that you use in a bunch of other things, you don't need to write tests for that.

In my view, is that the tests help you solidify ideas and make sure that as you experiment, that your previous assumptions don't change. Or if they do, then you know where to go when you need to go to make those changes.

But you say it's expensive and, yet, any major project that I've been on including the JavaScript aspect of things, when we didn't test up front, we're like, well, we don't have time to do it.

We've got to get this done now. We have six weeks to do something. By the time everything was launched and done and finished and it's signed off, and, hey, version 1 is done, it's in production, it was 10 or 12 weeks

So now, you can say, “Well, we're going to get it done in six weeks.” Well, we can't afford the test because that's going to add another four, five weeks onto the beginning of the project.

Reality has been that it's never actually done when people think it's done. So put it out, it's launched, and then you've got weeks of people clicking it and the people are actually testing it. They're going through this testing process.

So this idea of it's expensive, I think is largely a false economy. But you have to feel comfortable with knowing where and what to test and you don't get that comfort level and know when you can skip test until you've done it a few times.

I'm not going to test... I'm not going to write five tests to connect... to test connecting to a Solar instance and did it work, did it not work. You know what, I'm going to trust that when I run Solar, it's going to run, and when I connect to it, it's going to give me back a document.

Manuel Lemos: Yeah.

Michael Kimsal: The data in the documents may change and that would be an integration test, but I'm not going to write tests for every single... I added one to A, is A now equal to two?

Manuel Lemos: Right.

Michael Kimsal: Once that the math library work.

Manuel Lemos: That's the kind of tests that are ridiculous and you should avoid them because even if they are simple you spend time on them.

Well, anyway, regarding the deadlines that you mentioned that slip. I think they slip anyway regardless if you added tests or not, that's because sometimes your estimation is just wrong.

It was not a matter of having tests or not, but obviously fixing bugs takes a lot of time. And I think the circumstances on each tests can be more useful are those that are you did not think they would break but in the end they break and that they are very critical for the project.

Michael Kimsal: All right.

Manuel Lemos: So between not having any tests at all and having tests for everything, I think there is a middle ground on which you can choose those components that are more critical and totally cannot fail like sensitive parts, those that deal with money or those that deal with other critical aspects like people's lives or whatever is the scope of the project, I think you can choose those parts.

Michael Kimsal: I cannot argue with somebody advocating pragmatic middle ground that's... there you go.

Manuel Lemos: Yes. But that's just my circumstances. That's my circumstance because I only work for myself, so I cannot speak what happens when I work... because if my code breaks it's my loss. It's the loss of my own business.

In your case, that you prefer consulting to other companies, if you lose, if your code breaks, probably you'll get sued by those companies and your loss is just not just a matter of time or emotional. You can actually have financial damages.

I don't know if you actually sign contracts in which you are obliged to.

Michael Kimsal: I'm not at liberty to say. Actually, it varies between projects and typically, that for better or for worse, typically, that aspect is normally glossed over. Sometimes they're detriment sometimes to mine, but even if it's just, “Hey, fix this”, OK, that fix may take me five or six hours and that's time spent that I'm not doing new stuff whether my own stuff or paid client projects.

Manuel Lemos: Yeah. Well, I think this testing topic is very interesting, actually, to raise that... for some people, it's very passionate about the topic.

They certainly have strong opinions about this whether it should have full tests or just those that, for instance, you see many projects that are test after the fact. They only have test after they found bugs. So they only have test to see if the bug is still there or not.

Michael Kimsal: Sure.

Manuel Lemos: Well, I confess that somehow, even in some of projects, components that are critical that they cannot fail because they are complex. And if you mess with some code in one point, it will affect the functionality of code in other points.

And you may be fixing something and breaking something else and that's annoying and tests are definitely very useful to make sure you do not release a crappier code than they were before.

[Chuckles]

Michael Kimsal: Such a lofty goal.

Manuel Lemos: Yeah.

Michael Kimsal: Not less than you did last month. Yes.

[Laughter]

Manuel Lemos: Well, that should be the definition of progress. You don't learn to walk backwards.

Michael Kimsal: Yes.

Manuel Lemos: Well, anyway, but moving on with our podcast, what's that?

Michael Kimsal: I'm going to have some Red Thunder, baby.

Manuel Lemos: Oh, we don't have that here, I think.

Michael Kimsal: No.

Manuel Lemos: Is it energetic power and some

Michael Kimsal: Oh, yeah. Oh, yeah.

Manuel Lemos: power drink?

Michael Kimsal: I'm going to be powered up.

Manuel Lemos: Well, the only power drink I have here is not really on topic, but...

Michael Kimsal: Nice.

Manuel Lemos: This one was given to me like 11 years ago in the PHP International Conference. I wonder if there is a version of this for JavaScript.

Michael Kimsal: I'll be happy to do it.

Manuel Lemos: Because I definitely could use the JavaScript power drink.

Scripted JavaScript Code Editor (27:08)

Manuel Lemos: Well, anyway, as I was saying, moving on with the podcast, now I'm going to talk about yet another JavaScript editor. Let me screen share here. OK.

This one comes from VMware people. Well, you are talking about the VMware; you are using in your machine to virtualize your operating system.

Michael Kimsal: SpringSource owned by VMware, but SpringSource is kind of their own thing.

Manuel Lemos: Yeah.

Michael Kimsal: Yeah.

Manuel Lemos: Well, basically, this is like any other editors for JavaScript. I was trying to see if they have the demo of something. Well, they have the project page here in the GitHub, but, well, if I click on these screens, they do not get bigger. They're already in the final size. So I was trying to see if they will do something unusual.

Well, these are find much that I could say it is unusual, but, well, they offer... give certain explanations on why they decide to create yet another JavaScript editor.

Well, these editors are always useful. I don't know if we need many of them. Anyway, what they could be useful is for environments in which you can develop your projects on the so-called cloud on which you are editing code that is probably hosted in some version control repository.

And the actual server-side platform will save the updates to the version control repository. That is interesting. Michael, did you...

Michael Kimsal: I thought I had seen it like a demo video of this at some point.

Manuel Lemos: Probably you are thinking about the one from Adobe that we talked.

Michael Kimsal: No. I've...

Manuel Lemos: ...in the last episodes.

Michael Kimsal: Because I'm not huge into Spring, but I do keep up with some of the stuff because they're Grails thing and I could swear this came across in some email or feed maybe a week or so ago. And I thought I clicked on it. Maybe I didn't, but what...

One thing there is that they do link to... you had a link there to the Github stuff and it's almost becoming passé for somebody to write yet another JavaScript editor, but the meta-interesting thing to me is that so many people are now sharing so much of their code and things like Cloud9 when that came out, maybe a year or so ago, like “Oh, this is a big deal.”

And it kind of was, but not just, “Hey, this is a great tool,” but I think the idea of how to build these sorts of things and will become in some sense less exciting, but probably more useful and more ubiquitous over the next couple of years.

I think hosted cloud editors, I think we're still ways away from those being generally useful because I don't think they quite hit the level of features but also the use cases for workflow.

Again, things like is it going to be able to run all my tests? Am I going to be able to do... are you going to be able to integrate with other stuff? I have a test database. Do I host my test database in the cloud than to...

There's so many things that we take for granted on local dev machines and I think it's going to be a while before an entire dev environment really makes it in the cloud.

But we may see things like, “Hey, you got an embedded SQLite and we're going to run that in your browser for your test data. And then you're also going to deploy the SQLite in your server environment, wherever this gets deployed.

So as we blur the line between deploying an application and editing it, hosting it someplace, we may see that this become more ubiquitous.

Manuel Lemos: Well, as I was looking here, I'll stop screen sharing, so I can see if I get it again. Well, at least it has some interesting features. I don't know if the others have these features like integration with JSLint for providing markers for errors and warnings on things that probably you need to fix on your code.

And there is also some integration with JSDoc to extract documentation from comments. Well, as you said, I'm not sure if this is mature enough for you to use

Michael Kimsal: If not used...

Manuel Lemos: ...on the cloud.

Michael Kimsal: Yeah. If not used directly, then learn from what's the direction of these tools are going in. Is there something that you could use this for maybe in internal workflow?

The other flip side of this idea of hosted tools, code editing tools, is in some sense, things like WordPress and Drupal and whatnot, web-based content editors, we have content management systems and there's been this huge divide between content management and code management, code development. We may see more of a blurring of those at some point.

So maybe some of the tools that people have been developing to be focused on HTML, JavaScript and so on, maybe those will be adopted more for hosted... live hosted content management with good version control management, things like that.

Manuel Lemos: Yeah. Well, I think at least from what I understood, you are not required to use this tool, this editor in particular, in the cloud. I think you can use another machine.

Michael Kimsal: Sure, sure.

Manuel Lemos: If it is better than your regular IDE tool whatever you use.

Michael Kimsal: Nothing is better than my IDE.

Manuel Lemos: Yeah, especially yours, right?

Michael Kimsal: I paid for it. Cash money

Manuel Lemos: What is the name of your IDE? Special KIDE?

Michael Kimsal: Oh, I wish special KIDE.

Manuel Lemos: Special K.

Michael Kimsal: I use PhpStorm a lot when I'm doing PHP stuff. I use Zend Studio for some things. And Zend Studio just had version 10 Beta come out. I downloaded it, I have not run it yet, but I hope to on November 18th. And IntelliJ when I'm doing Java stuff and Grail stuff.

Actually, RubyMine, I played with the RubyMine for a Ruby project a couple of months ago and that was fun too. I like JetBrains projects or products, I should say. I like them.

Manuel Lemos: Well, actually, now that you mentioned Zend Studio, the latest version, it seems they have some integration with PhoneGap.

Michael Kimsal: Oh, PhoneGap, too, yes.

Manuel Lemos: Well, because Zend realized that many companies want to develop mobile first and if you use PhoneGap, actually, there is the Cordova Project, which is the open-source version.

Michael Kimsal: What's interesting you say mobile first because I've heard that phrase uttered a few times and I've not actually taken it to mean “make a mobile app first” but design with mobile dimensions in mind.

Design your UI, you know, what are your core things?, make those for a Tablet first or a smart phone for Android or iPhone first and grow the website or if it's an application, grow the web application the desktop size from those course.

And that doesn't... I mean, it's great that they're putting Cordova and that's kind of cool and whatever, more power to him. More on the UI side, I think, would be a nice thing from Zend Studio, but trying to do UI stuff for the Web inside Eclipse is, for me, has been problematic in the past.

Manuel Lemos: Yeah. Well, I did not take a look what they... because they just announced it, but it seems that now they have some visual tools to create basic user interfaces. Probably if you want something more sophisticated you will do it with separate tools.

Well, anyway, I think your perspective is interesting...

Michael Kimsal: So do I. Thank you.

Manuel Lemos: ...regarding mobile first.

Michael Kimsal: I get that all the time.

Manuel Lemos: I think it just means develop an API first and then wrap your mobile or Web interface around that API. Well, somehow I've been doing that for years. It's probably nothing new. It's a design pattern, if you can call it that.

Basically, we have a service layer on which you wrap your... well, I'm not sure if wrapping is the right word, but...

[Beatboxing]

Manuel Lemos: Not the kind of rap.

Michael Kimsal: Oh, OK.

Manuel Lemos: I meant call your API from your Web layer...

Michael Kimsal: Not rapping.

Manuel Lemos: ...which would be also layer that to your call from your mobile application. And so, basically, this mobile-first thing is not really nothing new. Just a new name for something that we were used to be or an old version.

Michael Kimsal: Hello? Oh, I was calling my API. Sorry, from my mobile.

[Laughter]

Manuel Lemos: OK. Always a great sense of humor. I think that probably would deserve a whole show dedicated to it whether how to fit mobile development in your Web application development, your cloud, now they call it cloud.

Michael Kimsal: Oh, yeah. Back in my days it was just a server.

Manuel Lemos: Yeah, right. We are doing that like 15 years ago and now they call it the cloud. It's probably...

Michael Kimsal: Because you're an old man. I mean, no, because you're a senior developer.

Manuel Lemos: And I use old names.

Michael Kimsal: Uh-huh.

Manuel Lemos: Old names for these so-called new things that are still old.

Michael Kimsal: Yeah.

Manuel Lemos: Well

Michael Kimsal: Go back to your floppy disk, to your token ring.

Manuel Lemos: Yeah. I think I have some floppy disks somewhere in one of those boxes in the back, but it's getting... well, it's not getting dusts because it is inside a box, but...

Michael Kimsal: The box is getting dusty. I think

Manuel Lemos: You're right.

Michael Kimsal: we have to pin the idea of sort of abstraction of layers there. I get it. I mean, it's in a box.

Manuel Lemos: It is all wrapped.

Michael Kimsal: I'm on a vault.

Manuel Lemos: Well

Michael Kimsal: Sorry, a different song. I'm sorry.

Unobtrusive JavaScript Programming (37:39)

Manuel Lemos: Moving one with the podcast

Michael Kimsal: Please, please.

Manuel Lemos: I like to now mention just briefly an article that I find interesting about unobtrusive JavaScript.

Michael Kimsal: I don't think we're able to do anything briefly. I don't know why you have been saying you're going to mention that briefly because we've never been able to do anything briefly.

Manuel Lemos: Yeah. That's me trying to convince myself that I need to rest so in the end of the podcast.

Michael Kimsal: OK. I'm going to put a timer... I'm going to put a timer on and you've got, sorry, Jason, you're just lucky to the draw. You've got, what do you say, you've got one... no, no...

Manuel Lemos: Thirty seconds.

Michael Kimsal: No, no, no. You can have... where did it go? What the heck? Zero, no, OK, one minute. You got one minute because that's the lowest. Go.

Manuel Lemos: OK [Chuckles]. Well, this is a very simple article. Let me mention something that we already been doing for a long time, but, well, at least for me, I would not think of calling it unobtrusive JavaScript, which is basically to put your JavaScript separate from your HTML.

Well, they show you here sample code of how it used to be, actually, in many sites to like this, like you have some JavaScript buried in the HTML tags. And according to the author, thanks to jQuery, people start using code more like this on which you define the hooks.

Michael Kimsal: You do see you got 20 seconds left right now.

Manuel Lemos: Oh, OK. Basically, you have a code like this that hooks on the JavaScript, I mean, the HTML elements using some calls that register events, some code to handle those events...

Michael Kimsal: And that was so...

Manuel Lemos: somewhere else.

Michael Kimsal: That was it?

Manuel Lemos: And, well, that's basically what I was going to ask you, Michael. Do you write totally unobtrusive JavaScript or maybe not?

Michael Kimsal: It was supposed to do the ring. It was supposed to do the... what the heck? Yeah, iPhone. OK. Do I write unobtrusive JavaScript? My JavaScript is so unobtrusive, it lives on somebody else's server.

It doesn't even get loaded on the page. It's just, if somebody wants it, they could go download it separately. There's like a little button that says, “Do you want this JavaScript,” and you click it and it comes down separately.

On a somewhat more serious note, I like to think I'm getting better at unobtrusive JavaScript. I'm not perfect at it, but I have... the more I've done JavaScript over the past several years, many, many years, but the more I've done it on moderate-sized projects, the more I've understood the... and this would probably be in general, the longer-term maintenance aspects of it, to me, unobtrusive JavaScript is more about maintenance and ability to go back and make changes later.

Testing is, I wish it was a higher priority, but there are some benefits to testing there. So, yes, I'm getting better but that's only because I really sucked at it before.

Manuel Lemos: Yes. Well, I think if you do not write all of your code in an unobtrusive way, well, as it is defined here, in my opinion, you will not go to hell if you do not do it, but as you... [Laughter] as you just mentioned it makes them easier to test if your code is actually separate.

Also, another point I want to bring is that being unobtrusive, it does not mean that it cannot be on your page. I think it just have to be separate from the actual HTML elements that you are going to go.

Michael Kimsal: Ideally... yes, separation there.

Manuel Lemos: Yeah.

Michael Kimsal: Parting of the Red Sea.

Manuel Lemos: Well, in my case in many circumstances, I have JavaScript generated with server-side components, so it gets naturally buried in HTML that it is also generated for the same purpose. I don't know if you use any framework tools on the server side that actually do that.

Michael Kimsal: No. None.

Manuel Lemos: So if you do your form validation generation...

Michael Kimsal: All by hand.

Manuel Lemos: ...you do it manually. So you have to do it in the server side and go to separate...

Michael Kimsal: And you do it manuelly.

Manuel Lemos: Yes.

Michael Kimsal: And I do it manually. I've been doing it by hand.

Manuel Lemos: I try to do not repeat myself, so I use some code on the server side that generates the JavaScript for...

Michael Kimsal: I do everything by hand.

Manuel Lemos: ...actual validations from the same code.

Michael Kimsal: I wrote my own operating system. I do everything by hand.

[Laughter]

Michael Kimsal: Built my own servers, I fab my own chips, I've made my own silicon for goodness' sake. I can't trust that... I would get obtrusive silicon if I didn't do that.

Manuel Lemos: Yeah. But that's not what I'm talking about...

Michael Kimsal: But this will probably become obtrusive.

Manuel Lemos: ...developing your own code. What I meant by that...

Michael Kimsal: But everything, everything...

Manuel Lemos: I use components that's going to generate the JavaScript for the forms, so it's both the...

Michael Kimsal: Yeah, I know you do. I know you do. And I'm just saying [Clears throat] Oh, sorry, backwards. OK. That's all I'm saying. Carry on. You said you're going to be brief or maybe...

Manuel Lemos: Well...

Michael Kimsal: ...did you say you were wearing brief.

Manuel Lemos: I was brief for the other part, but that thought, I was trying to talk about. So what you are saying having going to hell, that's...

Michael Kimsal: No, I'm just saying you're going to the next topic, is what I'm saying.

Manuel Lemos: OK. It's not hell, fortunately. Well, you are right. We need to move on because we are getting closer to the end of the podcast.

Michael Kimsal: I think we hit the end about 10 minutes ago, but we're still rowing, so.

Making Node.js work on a RaspberryPi device (43:09)

Manuel Lemos: Oh, there is one last topic before the regular sections that will end the podcast, which is in the case, one thing that I thought you would be familiar, but in the end, it seem you are not, which is about the Raspberry Pi devices.

Michael Kimsal: Yeah, it's not me. I mean, my... I spam about it.

Manuel Lemos: You know the...

Michael Kimsal: But I, yeah, I only spam about them. I don't actually know anything about them.

[Laughter]

Manuel Lemos: I heard about that spam. Well, actually, for those that are not familiar, Raspberry Pi is a sort of a Linux box that costs, I think, $25, right?

And it's a very small device that you can use to develop any device that has some functionality that could be useful. And since it runs on Linux, the could also run on Node.JS, but there is an article here that explains what you need to do to make Node.JS run well on Raspberry Pi devices.

Well, I have never used a Raspberry Pi device. I think that's interesting

Manuel Lemos: I haven't either.

Michael Kimsal: but I do not have the time. I think it's interesting, but I do not have the time. And so, I'm sure there are... there is other people that is always interested on these things.

Latest JavaScript Objects Released on the JSClasses site (44:29)

Manuel Lemos: So on this topic, that's all I wanted to comment about. And, fortunately, this time it was brief, so we are going to move on to the next topic which is the one of the regular sections on which you comment the latest classes. Probably she's on the JS classes.

Michael Kimsal: Oh.

Manuel Lemos: And this...

Michael Kimsal: I just thought if I run, it can make you

Manuel Lemos: Yeah, a few, not many, but a few classes to talk about. Well, Michael, from these, I think, four that were published in this month, which ones do you like to mention?

Michael Kimsal: Well, talk about the top two there, the HTTP Client which serves as the basis for the jsgtv2c, which is kind of a mouthful there. But both of those from, I hope I'm going to say his name right, Juraj, which I... is probably a roughly equivalent to George, it'd be Juraj.

[Laughter]

Michael Kimsal: I'm just thinking because sometimes names are very similar between Mikael and Michael and so on. You got that up. I've got it up on my end. I don't have it up on my shared screen though, but the HTTP requests or the HTTP Client object is, more or less, the basic class wrapper around the ability to post, to do posts and gets HTTP client stuff.

Interesting that what he didn't implement, it would have been interesting to implement, to see him implement, I guess just to say, PUT and DELETE. Now, a lot of server-side environments can't directly handle PUT and DELETE methods or maybe even HEAD, but to have an HTTP Client that would support all of those would be more useful to more people in more situations.

That's just my initial thought. But I think you've initially done this as the basis, as you've pointed out before, for the other class, if you want to bring that up. And, Juraj or Juraj...

Manuel Lemos: Are you able to screen share yourself?

Michael Kimsal: I'm not sure I should because I might break something this time.

[Laughter]

Michael Kimsal: Well, because I'm not using the normal browser that I use and it might... can you just bring up the other thing?

Manuel Lemos: I can, but it only shows when I'm talking.

Michael Kimsal: Oh, OK.

Manuel Lemos: Let me go there.

Michael Kimsal: I can try. I'll try. Let me give it...

Manuel Lemos: Your brought...

Michael Kimsal: If I brought it up in IE, it'd be probably fine. Oh, you got it there. This other one is the jsgtv2c. This is a object that uses that HTTP component to call the Google Translate API to do text translations.

Manuel Lemos: Yeah.

Michael Kimsal: So what is the EP... oh, EP License. So this is GPL3, OK. If you brought up that sample and look at it.

Manuel Lemos: Well, it's nothing sophisticated, but I think it's useful. Not only it extracts its translations of texts that you're giving some other... in some input language and you expect it to be translated to some output language, but it can also detect when the server API changes the detective language.

So if you assume it's English, but it's some other language, it also returns the other language that it was changed. And this is useful for you, too, if you are integrating this in the translation form, you can update the input that defines the initial language of your text.

Well, basically, this is to provide a similar interface to Google Translate on the Web, but using the Google Translate API, so you can do it in your own site. Well, this may have its uses. Well, anyway.

Michael Kimsal: Thank you to the Czech Republic.

Manuel Lemos: Yeah.

Michael Kimsal: Well, to all of you, yes.

Manuel Lemos: That's great. We did not have many contributors from the Czech Republic, so it's great to see people from other countries, not from the same countries that the majority of the contributors send their packages.

But moving on with the classes that were published in this month, this time all like tools were mentioned a class from Gabor Martini. He is already a developer that have submitted another package.

And this time, he just created... actually submitted a class that does things with prime numbers like decomposing a number and factors that once multiplied they give the original number and it decomposes the number in prime numbers.

Prime numbers are useful for many math purposes, so if Gabor developed this class, he probably has a good use for it because in abstract, probably it's just an interesting academic example, but he probably has a useful purpose for this class.

And the other class that I wanted to mention, another one from Karl Holz, which became a regular contributor of the site, it's somewhat is related with other classes that he already submitted, not just here to the JS Classes site, but also to PHP Classes site.

This just sends an AJAX request to retrieve an RSS feed and it parses the RSS feed to return it's values. So you can do something useful with them like displaying the RSS feed on a web page. And eventually, this could be used to display some activity on some server that is updated by an RSS feed.

And if you're using AJAX request, you can update the page without reloading it. So this seems to be an interesting class from Karl Holz from Canada. Kudos to him for this class too.

Upcoming Articles on the JSMag magazine (51:01)

Manuel Lemos: Well, on this section of the classes, we do not have more to comment on this class, so let's move on to our final section on which Michael will comment about the very important topics...

Michael Kimsal: In my world.

Manuel Lemos: ...that will be covered...

Michael Kimsal: I got a whole bunch. I'm going to make this quick. Stop what you're doing because I'm about to ruin. No, I can't. I'm not going to go there.

We've got a JSMag; we've got a few articles coming up in the next issue. It should be out sometime, ideally Thursday, but I think we've got some production conflicts this week, so it may not be out until Saturday or next Sunday.

We've got an article on reflows, when content gets reflowed and or repainted and some optimizations around that, how to optimize that. We've got another one from Mike Schwartz who has continually basically documenting his development of his SilkJS server-side JavaScript continuing on that series.

We have an article on playing snippets of video and another one which we may have... actually, it looks like that as actually... I'm actually pulling this up right now. Creating a simple message bus Web project using RequireJS for dependency management, jQuery for event dispatching, and underscore.JS all written in CoffeeScript with Jade as a templating system.

I think we'll have that out as well. As I said before, there's always this, we've got this, they're in the pipeline, they're in various stages of being edited, and if they don't hit this month, they'll hit next month, but that's what's on dock or on the docket for right now.

Manuel Lemos: Yeah. Well, that's all is an interesting batch of topics. Somehow, continuations of previous issues, right?

Michael Kimsal: Yeah.

Manuel Lemos: Well, for those that did not actually watch this podcast before, maybe you would like to mention about the subscription of your magazine, right?

Michael Kimsal: Sure. Well, I guess a few things. We do monthly PDF publications and that is a monthly magazine PDF publications suitable for print, but we don't print.

People can get a 12-month subscription either from now into the future or maybe earlier batches of 12 at a discounted rate. You can buy that online at jsmag.com and we're always looking for authors, contributors, writers, and whether it's you've got an idea for just one article you'd like to write or perhaps a series.

I actually talked to a couple of people this week about potentially doing a series, though I think given their schedule, it may not work out, plug in to the month, something like that. We'd like to get back to some more continuous content to this series, others that we had in the past, so if you got an idea for something, anything to do with JavaScript you'd like to talk, michael at jsmag.com.

Manuel Lemos: Yeah.

Michael Kimsal: Thank you.

Manuel Lemos: And do not forget that you pay.

Michael Kimsal: Oh, yes, yes, we do. It's usually not a huge amount, but we do pay for articles. As a matter for fact, I forgot his name. I'm blanking on his name. Goodness.

Manuel Lemos: Arturs.

Michael Kimsal: Arturs, yeah, who has done loads of JS Classes stuff in the past. Artur Sosins, yes. He had written for us a number of times in the past and hopefully, will again in the future, but I think he... was it on this podcast a few months ago that he said that he bought a new Mac book with the money from the JSMag articles?

Manuel Lemos: Yeah.

Michael Kimsal: So I think that's... it adds up. It's enough that if you want to buy something serious like that, you can.

So we do pay. We pay the editors as well too. We pay the authors. We pay the production. We pay everybody because that's what we'd like to do.

Conclusion (54:50)

Manuel Lemos: Right. Well, finally, we're actually talking about Arturs, not about something that the he has done visibly, but he is one of the better testers of one feature that I've been working on for quite a few months that will be hopefully released this month, coming of November, which will somehow make it more fun for authors to submit their class to the site.

Michael Kimsal: Are you going to pay them? That will be fun.

Manuel Lemos: Somehow, they'll somehow be rewarded not necessarily with money, but with something...

Michael Kimsal: Oh, come on.

Manuel Lemos: ...funnier than before, hopefully. And actually, Arturs is just one of about 10 better beta testers that have been giving feedback and it has been very useful and they are very enthusiastic with what is coming.

I'm dying to talk about it, but I have to be left...

Michael Kimsal: Don't die. Don't die, please.

Manuel Lemos: ...to next episode because...

Michael Kimsal: Give them some cold hard Reals. Is that how you say it? Give them some cold hard Reals.

Manuel Lemos: Yes. Well, for some people there, they have been paid for some artwork that is being used.

Michael Kimsal: I'm just making term saying the word right, that's all.

Manuel Lemos: Yes. Oh, well. Anyway, as I was saying, we do not have the time this episode and it's still not ready. I'd rather not talk about it because between now and then things probably will change, but I think it will be a great thing to talk about next month. Other than that, on my part that is all. I don't know if you, Michael, want to remind about the conf...

Michael Kimsal: I've got two things. I'm going to try to share my screen. I'm going to try because I made a separate tab and hopefully this will work. Yeah. Two things, can you tell me if you see that. Do you see that?

Manuel Lemos: Yeah. Oh, yes.

Michael Kimsal: OK. We've just got a little over two weeks. I think we have a little under three weeks in the count. This is our third annual conference for, primarily, freelancers. If you're a Web freelancer, Web designer, developer, graphic person, writer, somebody working in that space...

Manuel Lemos: Bill Gates is coming?

Michael Kimsal: No. I wish.

[Laughter]

Michael Kimsal: But even somebody like the people who are primarily marketers, if you're primarily working on the Web, you'll find a place... I was talking to people the other day and said, "Well, I do home inspections. I do..." I actually met a guy who does pet ambulance services, which is pretty niche.

I had to think for a moment, there will be some sessions there that will make sense and will give value to people like that, though the majority of people there will be in the software business.

There's not much in terms of actually coding sessions. There's a lot of things like, yeah, how to monetize your web site, you can see that, copyright stuff, how to protect your work online. How to deal with lawyers and attorneys and contracts and things like that, we got a CPA coming and so on.

So it's going to be an interesting mix this year as it has been in the last few mix. We've got some old speakers. We've got some new speakers. If anybody is interested in attending, you can register with the code JSClasses at indieconf.com, click the little registration button and it will take you directly to the registration page and you can put in... enter the promotional code, enter JSClasses and you will get a nice discount.

Feel free to email me or you just contact me through the indieconf web site if you have any questions.

Last, I would like to impose on you just for a moment, Manuel, may I do this?

Manuel Lemos: Well, it depends.

Michael Kimsal: I've done it.

Manuel Lemos: Oh.

Michael Kimsal: I'm asking for testers. If anybody out there watching this would be interested in testing this hosted virus scanning service, please go to the virusaid.com and sign up.

Go to that website and sign up.

Manuel Lemos: I remember you talking about this some months ago.

Michael Kimsal: Yes, and I had to... about a year ago. And I had to put it together. I had to put together virus scanning for particular project. I extracted it and put this up and was piloting using it as a Web service.

I had to... for a couple of reasons, I had to do some under-the-hood changes to both sets of code, but I've moved this to a different server, I've updated some of the stuff that needed to be updated from a security standpoint.

So this is sort of ready to be tested again. I'm using it regardless, but I want to see if other people would have a need for it. And my initial thought was I'm not going to press this "people won't have a need for it", but the bigger thing that I've noticed and you may noticed, if we're talking about the cloud, there's loads of cloud services out there; Heroku and CloudBees and so on.

A lot of cloud services that do not... let me close that. You do not get access to the file system. You can't just take files and just store them on the file system and say, "Well, I'm going to run Clam or I'm going to run... we got McAfee and I'm just going to let it scan this directory."

You're not allowed to do that. You're on a scalable... dynamic scalable system. You don't have direct write access to the file system. So things like... trivial things like I want to run ImageMagick, I want to do this, I want to run that, I want to run a virus scanning system. These aren't things that you can easily implement on your own system because you don't actually have your own system when you're in the cloud.

So if there's anybody out there running on PHP Cloud or I guess it's AppFog now or CloudBees or Heroku and you like to help thresh this out, please let me know. Thank you.

Manuel Lemos: Yeah. Well, that's interesting. Well, maybe actually you can come back to our future episode. If you provide an API, well, it's always interesting for people to integrate in their applications.

Michael Kimsal: Yeah. If anybody... and I'll answer after all that, if anybody would like to write a JavaScript class for it, reach out to me. I'll give you access for the API, I'll give you a key and you can knock yourself out. Thank you.

Manuel Lemos: Well, that would be interesting.

Michael Kimsal: Yeah.

Manuel Lemos: Well, with that note, we practically ended this podcast. And there is nothing else to add, I think. So on my behalf, I like to thank you everybody for being patient and listen to us for more than one hour. So bye, all.

Michael Kimsal: Bye-bye.

[Music]