JavaScript Jabber

JavaScript Jabber is a weekly discussion about JavaScript, front-end development, community, careers, and frameworks.

Subscribe

Get episodes automatically

015

015 JSJ Open Discussion


Panel

Discussion

  • Node.js vs Rails
    • Conventions
    • Tools
  • Service Oriented Architecture
  • Connect
  • Express
  • Disagreement across the community
  • CoffeeScript
  • RailCar
  • CRUD (Create-Read-Update-Delete)
  • Non-Blocking IO in Ruby
  • Debugging in JavaScript
  • Monkey Patching in Ruby makes it harder to debug
  • Stack Traces on Node.js
  • Domains in Node 0.8
  • Process.next_tick
  • Anonymous functions
  • Build process
  • Arrow syntax for functions
  • JS.next *-notation
  • Error handling in node
  • Asynchronous composition
  • Flow control library
  • Futures.js
  • Generators?
  • Grunt
  • Backbone.js
  • Require.js
  • Write your own generators
  • Prototypes
  • Asynchronous callback notation for Javascript
  • iced coffee script
  • JSON
  • executing JSON gives you a Javascript object
  • all higher level languages have some support for JSON
  • JSON defines a lot of different native type
  • XML
  • Comments (use YAML)
  • SpotterRF JSON examples

Picks

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

CHUCK: I so heard…  I so heard when you said, “Not everybody is using Node.” I so heard, “Not everybody’s using Node — like they should.” [Laughter] CHUCK: Hey everybody and welcome to Episode 15 of the JavaScript Jabber Podcast. This week on our panel, we have AJ O’Neal. AJ: Yo, yo, yo coming at you live from the forest of Orem, Utah. CHUCK: We have Jamison Dance. JAMISON: Hey. CHUCK: And I’m Charles Max Wood from teachmetocode.com. And this week, we are going to be just talking about stuff that we’ve run across. Now, one thing that I want to mention before we really get going is that we all kind of live in the same general area. You guys all live in Utah valley, right? AJ: Correct. CHUCK: So in fact, I think I’m the most remote of the three of us. But anyway, so we attend the same JavaScript user group and we are on the same mailing list for the user group. So this week, we are just going to kind of talk about some of the stuff that we’ve seen come up. And you know, some of the stuff that we’ve been discussing in the chat before the show. So, one of the first things came up was there was a company here in Utah that said that they were moving from Node.js to Ruby on Rails. And you know, there were some discussion about why that was and what that meant. JAMISON:  Basically like he is talking about doing a CRUD app, and he missed a lot of the tooling and the convention and the automatic stuff that you get from Rails since it’s such a mature platform, where you just get Restful resources that work out of the box and lots of decisions have been made for you. Whereas with Node, you have to start from scratch every time you make an app, to create the world kind of a new… for every new app you start in for every new resource you make. AJ: That’s not fair to say, because there are tools that do the scaffolding; there’s just not a clear winner. JAMISON: Much less well known and much less mature though. CHUCK: And the other thing is that scaffolding is really kind of the… it isn’t what makes Rails, Rails. I mean, for example you can use the scaffolding and it will generate something that does the CRUD and follows the rest conventions that Rails is set up. But there are a lot more there, you know, just from a security stand point and functionality stand point, that you don’t have to build yourself as opposed to what’s in Node.js. AJ: So from a security stand point, what are you talking about exactly? CHUCK: Well, it has built in cross site request forgery protection and there are a lot of plugins and things that allow you to easily set up SSL encryption and things like that. And you know, with all of those different features and tools, it just makes it easier to roll it out. I’m not saying you can’t do it with Node.js, but it makes it pretty easy. And that’s the big win I think with Rails is that they thought through a lot of these processes and said, “Okay, well let’s just do a lot of these by default.” JAMISON: So at iTV, we use a lot of services where we have kind of service-oriented architecture and we have run into lots of problems with having each service we kind of designed from scratch. So with Rails, you get a lot of decisions made for you, and you might not agree with  all of those decisions all the time, but there’s actually a lot of value in just having one less thing to decide and to argue about. Even if it might be sub optimal for your use case, the fact that you don’t have to think about it at all, and you can just kind of work around it if it turns out to be not that great is really valuable. CHUCK: Yeah well and the other thing is what you’re talking about is Rails is an opinionated framework that uses convention over configuration. And so the conventions are what’s nice, but you can actually configure them, so that you can do something that is outside of the convention if you so desire. JAMISON: Yeah and Node almost is a framework, framework. Like, you use it to make stuff that can make stuff. So, conventions are… [Crosstalk] AJ: I think… JAMISON: …at least when you’re talking about doing web apps with it. I mean, I guess if you want, you can just write using the HTTP server and stuff. But I don’t know. The conventions live in each individual app instead of some centralized place, it feels like. CHUCK: But sometimes you need that and you know, so there is definitely power in being able to make the decisions and build it from the ground up and get exactly what you need. For me, it’s not that one is right and one is wrong; it’s just right tool for the right job. JAMISON: Yeah. What’s AJ going to say though? I feel like I keep cutting him off. AJ: So I was going to say… so first of all, to Chuck’s earlier point, the csrf and all those standard things, they are all available in Node. Like if you are using Connect and Express, the modules are there. So you do have the security things. I would definitely entirely agree that Node has some distinct disadvantages in the community; one is it’s only been around for what, 2-3 years? CHUCK: Yeah. AJ: Another is that whereas in the Ruby community, you have a pretty tight group of people that are like minded. In the JavaScript community, all of the leaders completely disagree with each other and bicker all the time. Like, you can’t get Crockford and Isaac Schlueter and Jeremy Ashkenas and John Resig to agree on anything. And those are like the leaders. So you have these four different school ols and then everybody is going in different direction and saying that everyone else is wrong. So that is like a huge problem that is affecting the whole JavaScript environment as you know, as I see it. So Node is not going to have the cohesiveness that Ruby has — probably ever — because you can never get those 4 or 5 guys to agree on anything. CHUCK: Right. JAMISON: But most of those guys don’t care about Node. Well, not “don’t care about”, they are not directly involved in the Node community. Of the four guys you mentioned, I think Isaac’s is the only one that’s actually the leader of the project but all the other guys are just… [Crosstalk] AJ: But what about Jeremy Ashkenas? I thought that CoffeeScript has gained just huge momentum in Node. JAMISON: Yeah. AJ: So I can see that as more of a Node technology than a browser technology. JAMISON: He doesn’t really influence the direction of Node itself at all — I don’t think. CHUCK: Yeah CoffeeScript is pretty much engine agnostic, right? It just compiles down to JavaScript and runs. But you know, and I can see that to a certain degree. Part of the deal though is that you know, Ruby on Rails is basically built by a handful of guys that make the decisions. I mean, we all give input and we tell them what we hate about it and they ignore some of it and use some of it, depending on how they think it fits with the philosophy of the framework. AJ: That’s how it ought to be. CHUCK: And to be honest, I don’t know if its necessarily fair to compare Node.js with Rails, because effectively, what we are doing is we are comparing a framework on Ruby with a language implementation of JavaScript. And to be honest, you know if there was a framework that was comparable to Node that are comparable to Rails that ran on Node.js, then I think we might be having a little bit different conversation here. JAMISON: So the thing with that is there are some people that are trying to make more full-stack opinionated frameworks. I think there’s one like RailCar or something like that. There’s a few of them that all have like railroad industry inspired names to… [Overlapping talks] AJ: Yeah that’s the problem with their names is like, who wants to use something that’s built to be like Ruby? Just use Rails. JAMISON: Well yeah, exactly. That’s what I was going to say. So part of the issue with this guy’s email on the mailing list is he is writing a CRUD app, right? He is writing an app that frankly, Rails was pretty well designed to handle. It gives you CRUD functionality basically out of the box. And Node can do CRUD, but its strengths are for different problems. So I mean, I know a lot of people who get into the Node versus Rails thing and I guess we kind of are too, but they solve very different problems. Like for us, so I complained a little bit about service oriented stuff in Node, but it’s also really nice when you’re calling out to all these different services underneath you at the same time and it’s great to do that asynchronously. So you don’t really have to block on any of these calls. CHUCK: Yeah but Ruby has non-blocking IO, so it’s really a non-issue there either. JAMISON: Yeah, if you use event machine. Yeah. CHUCK: No. Ruby, the language has non-blocking IO. It won’t block on IO calls. AJ: Oh, really? When did that change? CHUCK: it’s always been that way? Hasn’t it? AJ: No. Remember when… what’s that server called… it starts with like a “t” I think, built on event machine. Thin! CHUCK: Yeah? AJ: When Thin was coming out, it was like when there was all these big hubbub about event-oriented architecture and non-blocking and  that was about the time, that 6 months of excitement on Thin and other things that were coming up is when Node started getting some traction. CHUCK:  I don’t know. From what I understand, basically the way it works is you have the threads in Ruby — which aren’t native threads like you would normally see in regular Unix application — but basically, if you have one thread that is waiting for IO, then it will just run around in to the other threads. AJ: Well that’s the nature of threading. I mean, that’s not… all threaded languages work that way. [Overlapping talks] CHUCK: Right I’m just saying it doesn’t block your entire process. JAMISON: Yeah if you want to do it in threads. I was just talking about without using threads. So if you just go without threads then block. CHUCK: Yeah if you have a single thread on a single process, then yeah, it’s going to block. And I understand that the JavaScript is a little bit different that way. AJ: The one thing that I do like about working in Node and that community — I use Connect a lot —  but the thing that I really like is it seems to be easy to debug people’s code because of the nature of the language. Like with Ruby, there’s all that monkey patching, which I think Ruby is such a fun language to start learning, but I feel as I learned it more, it became more difficult to learn more rather than easier because of all of the monkey patches and like the 3-line function where you have to chase around like this to that, to that, to that, figure out what’s going on, if it’s in a different file in a different directory and it’s just a two-line function that you got to find somewhere — needle in haystack problem, you know? CHUCK: That’s coding style though. That’s not the language. JAMISON: Are you talking about the meta-programming stuff? AJ: Yeah I’m talking about all the meta-programming stuff where like, you have something like find by id and username and then it parses the function name to determine what the parameters are that should be passed to the function. So instead of like, instead of calling find and then saying, you know, name = this and age = this. They do .findbyage and username, and then pass in age and then user name. That kind of stuff gets really, really confusing to debug. Well for me, that’s for me. CHUCK: Yeah. I can see that. I generally don’t do that and again, it comes down to whether or not you like those magic functions or not. But yeah, I can definitely see that. And a lot of the other meta-programming, if you directly, for example in Ruby have open classes; in JavaScript, you kind of have the same thing. I mean, you can change stuff on an object will nilly. And you know, it’s kind of hard to figure out where the change came in if somebody doesn’t properly name space their changes and things like that. And that can make it hard to debug. JAMISON: You could probably correct me on this Chuck; didn’t Rails in version 2 used to have a lot more kind of hairy magic meta programming? Wasn’t that part of the changes to Rails 3 because they cleaned it up a little bit. CHUCK: I think they cleaned some of it up. I think most of it… [Crosstalk] JAMISON: Called then magic? CHUCK: Well, they moved a lot of it out into it might each set of functionality is now sort of on its own library. And so it’s easier to figure out what’s going on there because it’s like, “Okay this comes out of ActiveModel and this comes out of active record and this comes out of, you know, this other place,” And you can kind of mix and match some of it. And for example, use a different ORM and then you get different functionality with different libraries and things. And since they kind of broke it apart, it makes it a lot easier to manage. But I don’t know if they did a way with a lot of the magic meta-programming stuff that AJ was talking about. JAMISON: So if we are talking about Node as well though, debugging in Node can be kind of awful because the stack traces are so bad, these stuff happens on the next event loop and you lose all the context of where the calls came from and stuff. I think aren’t domains supposed to fix that though? In Node 8? AJ: I don’t know about that, but I haven’t had problems recently with those kind of calls traces. Because there was something they were working on in .4 and I think they’ve done pretty well on .6, its very rare now that I get one of those 2-line stack traces. Normally, I’m seeing stuff that’s readable and helps me figure out where it is. JAMISON: I see a lot of stuff that just ends up at process done next tic, and that’s kind of frustrating. AJ: That maybe a code style thing too, a little bit because there are certain ways that you get more stack trace and then there’s certain ways where you lose more. JAMISON: You mean with anonymous functions? AJ: Yeah. Just different styles of setting up how your asynchronous flow goes. CHUCK: I have to say, anonymous functions are the bane of my existence. I freaking hate those things. JAMISON: [Laughs] CHUCK: Like you’re trying to figure out what’s going on and it’s like, “Function on this line.” And it’s like, that doesn’t help. JAMISON: Oh, man. AJ: Yeah they definitely are. I really wished that people would not use them so liberally. I mean it’s nice for something really simple, like the “for each”, where you just wanna make a quick anonymous function but, I agree it would be a lot nicer if they used functions and then lambdas and not these 300 line anonymous function things that have bad scope and… CHUCK: Well the thing is I mean, you have a function reference, so just define the function and then use the variable name. AJ: But then I have to type five more characters! CHUCK: Oh, yeah. And then minify it when you’re done. [Laughs] AJ: But then I have to use a build process. JAMISON: You have to anyways. CHUCK: You should anyway. AJ: But then I like to whine! CHUCK: [Chuckles] Now you sound like my kids. JAMISON: And you are in a right place, AJ [Laughs].  We should talk about CoffeeScript then because one of the wonderful and also horrible things about CoffeeScript is the arrow syntax for functions. And it makes it so much easier to use it to define and use anonymous functions, which means that instead of having to type function and then curly braces and stuff, you just typed arrow and then it just happens. I find myself using the anonymous functions all over the palace in CoffeeScript. AJ: JS.next is better because it’s only one character, star. CHUCK: Oh, really? AJ: Yeah if you look up the JS.next transpiler that Google has — and there’s another one too that maybe Mozilla has — but yeah, you can start writing JS next that will compile them to JS and you can do things like star instead of all the function declaration. CHUCK: Yeah but even then, you can still do var functioning = * or then CoffeeScript you know, variable name = arrow notation. I mean… JAMISON: It’s right there Chuck! It’s so easy. [Laughs] CHUCK: It is! it is easy. But it’s just as easy to sign it to something that you can actually then reference. It makes your code reusable. Anyway… AJ: I’m with you. JAMISON: Another thing with that is the error handling paradigm in Node. I’ve actually been running into problems with this. So this is where very functions take a callback in the first parameter and error. So, every time you ever use one of those callbacks, you just have to check if the first parameter is an error. It feels like a lot of repeated code. Have you guys developed any better strategies for handling errors when you are using Node? Like I have a controller that’s probably 30 lines of error checking from all these different services and 50 lines of code. CHUCK: I like my strategy; I don’t check for errors. JAMISON: [Laughs] CHUCK: Honestly though, to be perfectly be honest, I haven’t done a ton with Node, so this isn’t a problem that I’m really all that familiar with. AJ: The thing that I handle with is 1. I don’t compose too much. Because you run into that problem where you have like asynchronous composition, where you’ve got this asynchronous function calls that asynchronous function, calls that asynchronous function and then you do end up with where you have these ten functions and each one is checking the error of the previous one. And I think if you really wanna clean up code where you are doing that a lot, then you wanna look at a flow control library that will handle it a little bit better, so that you’re not… so that it feels better and that’s one of the things I wished that they’d added to JS Next is some sort of default way of saying, “We all agree that flow control sucks in JavaScript. Here’s something built in to the language that can help us handle it.” CHUCK: That leads me to a question that I have. So I’m pretty familiar with composed method. I mean, you know I’ve talked to Kent Beck about it and you know, it’s something that I like, yeah name dropping there we go. But yeah we had him in Ruby Rogues and we talked about… what was it… Smalltalk Best Practice Patterns? JAMISON: Yeah. That was good. I listened to it. CHUCK: You know, I think that’s something that both the book and the episode are something that’s worth anybody listening to that’s in programming, because the principles kind of apply anywhere. So if you are using composed method, yeah you can compose all the way down to, “Okay I need a method that increments this variable and then I need another  method that that uses the incremented variable to you know,” and you can compose it all the way down to you know, idiocy. And I liked that AJ kind of brought up asynchronous composition where you kind of the same thing, except you know, it’s all evented so it’s okay, increment and then firing event that will cost something to use that, whatever. Does that tend to get any better or worse? This asynchronous composition, is that any better or worse when you boil it down to that level of insanity? Is it better or worse than synchronous composition? AJ: Oh heck a way worse. Like it’s absolutely… you need to research a flow control library and look at it if you want code to be kind of pretty and JavaScript if you are doing a lot of composition, because you’ll have more lines of function declaration and error checking like Jamison was saying. What I have found is that if you use the prototype style — like creating classes — it’s a lot better. I’ve started using the prototype classic — the proto classical whatever you wanna call that design pattern — a lot more recently, and it’s improved the functionality of the code, like the performance as well as makes the code easier to read. And I have less problems with composition because I’m storing more stuff in this and so, you have fewer callback parameters and more that you’re just storing in this. Makes sense? JAMISON: Yes. So one of the problems with the asynchronous flow composition is it seems like a lot of syntax and boiler plate for like three asynchronous operations. Like so, you get a request in your server, you need to call it to some other service and then you need to hit a database. So that’s like 2-3 asynchronous calls or asynchronous operations that you have to do. And if you use a flow control library, then you have to define like an end function and you have to somehow wrap it all up in a function call like async.foreach or async.sequence or something like that. I don’t know, it just feels like a lot of boilerplate and that’s where anonymous functions are siren like in their call to me. So, have you used it for just little simple things like that? AJ: The flow control? JAMISON: Yeah, which is 2 or 3 things. AJ: So the main things that I use are there’s three functions and the Futures library that I wrote — Futures.js — that for each async, when I have a list of items of data that I’m going over sequence if I have a number of functions that I wanna use sequentially, join or if I have a couple of asynchronous functions or I just wanna know when they’re all done, then I added a new one like a week or two ago lateral, which is a combination of sequence and join; you do batches of things — basically a thread pool — you do four things at a time and then queue up another thing every time one of the things in the pool finishes. For the really small stuff like what you are saying with a database call, a website request and then like a file call, I usually just do those by hand — and its annoying. CHUCK: So one other thing that we were talking about before the show was that you know, you brought up a scaffoldings and generators for like… because Ruby on Rails has those and I was wondering if such a thing exists in JavaScript, is that part of like the different frameworks or things that you can use or you know, are there different generators like that where people have written them? AJ: So there’s… I’ve heard that there are some, but haven’t really used them because it’s… I don’t know why I don’t use them. It seems like I would, but as painful as JavaScript is, I don’t find it that painful at the end, you know? JAMISON: We use it, so we use Grunt for some of our front-end stuff. We use it to generate when we want to make like a new Backbone view, we generate a style sheet and the HTML template and the CoffeeScript file for it. So we do a little bit with it, but not a huge ton. And it’s all kind of handled with Grunt. CHUCK: What is Grunt? JAMISON: So Grunt is one of these build tools you can use it, it’s kind of designed to work with Require.js style stuff. But you can extend it with plugins. So it will do things like uglifier code and run the Require.js like compiler to put all your code into one JavaScript file and things like that. And we just extended it to have a task to create these files that we use for our Backbone stuff – that’s about the extent of it. CHUCK: So I’m going to bring up something; I’m bring Rails up again, but basically it’s to kind of illustrate generators a little bit in a way that I use them. So generators, you know, they just generate your boiler plate code. And it seems like about 90% of the time, when I generate something with the generator, I wind up removing a lot of the boiler plate code. So it’s just basically, for example, I was doing an example where I was building a blog in Rails and I was just showing how quickly you can put one together. But you know, when I was working with comments, it turns out that I only needed the create method because everything else is shown on the post page. And so I did a scaffold generator, which gives you all of the CRUD operations for comments and then I went in and I removed everything except create. And so I removed like 80% of the controller, just to put it there. But the nice thing is that it did set everything up for me and then all I had to do was just take out a bunch of lines. JAMISON: I think that’s why you write them yourself. I mean if you need generators, it’s because you are doing lots of competitive things and you are the best person to know what solution would help you. So I mean that’s why it’s nice because they are like, “Well we do this for every single Backbone view we create. We create style sheet and we create HTML templates, so we’ll just wrap this up.” And I don’t know, it’s not crazy. I can’t even post a link to it. I think it’s open. I’ll put it in the show notes. I think our Grunt extensions are open source. But yeah, it’s pretty easy; maybe 30 lines of JavaScript to generate it. CHUCK: Yeah. So one other thing that occurred to me with the workflow discussion we were having just to jump back  real quick was that is there any reason where after you complete the step of the asynchronous process, you couldn’t just call the function at the end that’s supposed to clean everything up and have it checked to make sure — or even a function that just checks — just to make sure that its ready to end and then when it’s not, it’s just says, “Okay I’m just not ready.” And then it’s done. JAMISON: You mean just only handle errors at the very last asynchronous call? CHUCK: I guess. Basically, what I’m saying is like when you have to make a database call and you have to go open a file and you have to go access 2 or 3 other services that are out on the internet, if you don’t have that data back yet, then it’s not ready to finish up. You know, you have that last thing that kind of ties it all together and so, couldn’t you just say, “This is the guy that is supposed to get called after me, and so you call him” And before he actually does his job, he does a quick check and says, “Hey, am I ready to go?” “No. I’m not ready to go.” “Okay, I’m done.” And then the next guy that also calls through to him says, “He’s after me,” calls him and then finally when enough of them have called and said, “Hey I’m done.” And then it goes and checks and says, “Now I have everything I need,” and then it runs. AJ: Yeah you can do that in the sense that you can… kind of like the decorator pattern, right?  So you can create a class and then run it through a function that will wrap all of those functions in that kind of logic. It’s still not… CHUCK: It’s not pretty. AJ: The problem is that the language itself doesn’t address the issue. CHUCK: Right. AJ: And so even when you use these libraries. Like so I created this, as part of Futures, there’s this function called Chainify, which is basically allows you to wrap something in that fashion, but the problem is I designed it, it’s really pretty, it looks really nice, it feels really nice if you are writing an API with it, but I never end up using it, because it’s like too much boiler plate — just like Jamison was saying before — that you have to do; so you got to require the library, you’ve got to include it. And then if you do it by hand, the best thing you can do is use Prototypes. If you use Prototypes and you store things in this, that’s the simplest way to do it. Not as pretty as if you’re using some flow control solution, but that’s boiler plate – well, kind of. CHUCK: So you are talking like the language should give you a good way of handling this and I wanna push back a little bit because ultimately, the language has given you enough of the tools to solve 80-90% of the things that are going to get thrown at it. In fact, I’m pretty well convinced that most of the programming languages out there —  for at least 60-70% of the problems that are going to be thrown at it — it’s fine for. So you know, so 60-70% — maybe more — can be handled by JavaScript. They could be handled just as well by Ruby or C# or Java. You know, whether or not those actually fit the way that you want to approach or think about the problem, that’s a different discussion. AJ: Well, Okay. Ruby has generators, right? And Python has generators, and they are really useful. And we are talking about “generator” the programming construct, not “generator” that writes my code for me, right? JAMISON: Does Ruby have generators? AJ: Doesn’t it have like a built in iterator? CHUCK: Iterators, yes. But anyway, so to the point of whether or not you should have a flow control library, I think that’s open for debate. AJ: But here’s the thing, like a language has the tools to manage the kind of things that it does. Like Ruby has all kind of produced stuff built in. You know, it’s got so much in there that’s just like it makes the language part of what it is. It helps define what the language is designed for. CHUCK: Yeah. AJ: So, JavaScript has all these asynchronous stuff, kind of by this legacy heritage. But one, it’s reverted from the way it was originally used, because originally, JavaScript had callbacks passed in the first parameter, not the last parameter. And I don’t know who came along and screwed that up for everyone, but it was a terrible mistake. CHUCK: [Laughs] AJ: Because if you pass callbacks as the first parameter, your code is a lot simpler and a lot cleaner. One, because its ugly to pass in anonymous functions as a first parameter, but also like things like function composition and what not becomes simpler. It makes sense without having to have even more boiler plate. But there wasn’t really a way. There’s not been a way to handle that full control. And there really, really should be. Like in CoffeeScript, I think it would be great if somebody just came up with the mechanism that can be library in JavaScript but was just part of CoffeeScript where every functions has a dot on, like every function  and event or like every function has some method of like… I just think what’s crazy is they are adding generators to the language. So you can call like .iterate or — I forget what the keyword is – but any function will now have like a .iterate. [Crosstalk] CHUCK: Each? AJ: I don’t remember exactly what it was. But they are adding something as every function will have it, just like arguments. Like arguments just exist, it’s just there. You get it for free, you don’t have to create it. And there needs to be something like arguments for flow control; something that is part of every function just like this, just like arguments, that helps you navigate it without having to use a library, because every single person that writes in JavaScript either shoots themselves in the face or uses a flow control library, or they are one of those that’s like, “Oh, I love writing a 100,000 lines of code and making it complicated and repeating myself everywhere.” JAMISON: Not a… CHUCK: [Laughs] JAMISON: Those are the only three options. CHUCK: Right. So I’m just… [Overlapping talks] JAMISON: …by the way, AJ it’s CoffeeScript. Its CoffeeScript with built in flow control or the compiler that wait on the first stuff. So it’s kind of a library but it’s also kind of built in to the language. AJ: That sounds amazing. That is exactly the kind of thing that I have wanted to see. JAMISON: I linked to it in the chat. AJ: Yeah, yeah I just opened it up. But I was on some discussion like 6 months ago on the CoffeeScript bug page or something where, we were having this discussion about, well, flow control should be in the language because with CoffeeScript, you have the liberty to do it. So I’ll definitely have to take a look at this this. JAMISON: You were saying something, Chuck; what was it? CHUCK: I was just wondering if well, I was misunderstanding because I was thinking iterators instead of the flow control. Anyway, but yeah I like the idea of having some sense of built in flow control. But I think it has to be simpler than what — like Futures.js — where it’s you know, here’s how chain these together and here’s who you build these up sequentially and stuff. I think the pattern needs to be simpler where it’s just like, “When I’m done, this is who I’m talking to.” Or “When I’m done, this is the event that I’m firing.” And you know, and then that’s it. AJ: Well, I would argue that there needs to be two things; there needs to be who to call when I’m done, but there are two different ways, primarily that people are using this. One is you do all asynchronous things at once and when its al done and the other is you wanna do it in sequence. Those are the two really important use cases that if a built in construct doesn’t handle both of them in some way, then you still need something else. Because with the join thing, basically, all you do is you have a counter. You say, “This number of asynchronous functions, every time one completes, I increment the counter. When I get up to counter = number of functions, then I end.” Then the other one is you are saying, “Every time a function finishes, do the next function in the queue. If all functions are done, and a function gets added to the queue, do it right now.” CHUCK: Right. But then we need a simple notation for that. AJ: Oh, definitely. CHUCK: You know, I don’t know that… because it has to feel natural. You know, it’s not a work flow manager’s super structure manage these thingies and these thingies and these thingies, you know, if it’s too cumbersome, people won’t… I mean, people will use it because it pays of, but you know, it should feel natural to the language. JAMISON: Just to whine about it. CHUCK: Yeah. Whereas if it feels like it’s just a natural flow from the language, then it makes sense. And I think it’s an interesting conversation, but again, you know, I mean, you brought up the iterator stuff that’s built into Ruby, well in fact, it’s actually part of the core library. It’s not actually in the core of the language itself. It’s something that’s added in and distributed with the language. I mean, people use it like it’s a core part of the language — and it may as well be — but you know, there is a slight distinction there. AJ: Well, in JavaScript, when you declare a function… like in Ruby, you have so much meta programming, that you can really do almost whatever you want, aside from changing the syntax, you go and then even you changing the syntax… [Overlapping talks] CHUCK: You can fake it out a lot of times. AJ: But in JavaScript, there’s no way for me to say — at least I don’t think there is — it would be changing the syntax of the language to say that there’s an object that’s like this, that’s part of every single function that gives me the ability either to declare myself as a callback, or to declare myself as an end point for an asynchronous process. CHUCK: Right. AJ: Because the way that it would work best is if there was, instead of the return, there was like  a complete. And so if the function were going to be asynchronous, when you call complete, then would do the callback. If its asynchronous and if its synchronous, then we do it as a return and it will just pick either or or, depending on how you are using the function. And like after you declare the function, you could call like the .win or .then or something of that nature or maybe like an asynchronous callback. CHUCK: You should just rewrite Node. JAMISON: There’s actually people that are working on it with stuff like that. Well, it’s not quite like that, things like… [Overlapping talks] CHUCK: And I was going to say that that’s the rub, right? Is you get used to that notation in Node or the Node.branch or whatever, and then you go into the browser or on a machine that doesn’t have your branch with your functionality in it, and then you are in a mess. So, yeah. AJ: So if its implemented well in this Iced Coffee I think it really needs to be something that’s at a core level where it’s part of the syntax, it’s easy, it’s simple, it’s enjoyable. CHUCK: Yeah that makes sense. So I wanna jump in on something else really quickly. And this is something that we were talking about going into we’ll talk on real quick and that is JSON APIs and JSON in general. I think the big win for JSON in general, is just that, if you execute it with a JavaScript engine, then you get and object back, which is kind of the big win there between JSON and JavaScript. Am I wrong? AJ: No, but I would say, further than that, its every high level language uses JSON as part of it’s the core distributed libraries. JAMISON: I agree. AJ: It’s not just JavaScript, it’s an object notation that’s a generic object notation. CHUCK: Right. So all the higher level languages have some sort of support for JSON. JAMISON: Yeah and turning it into native objects in that language. So like in Python, you can match JSON… you can turn JSON into Python dictionary. In Ruby, you can turn it into hashes and stuff – which is great. AJ: The big win with JSON in comparison to the other elephant in the room is that JSON defines objects, arrays, numbers, Booleans, strings and null. Whereas the other big elephant in the room defines nothing. You have to have some sort of documents, interpreter, style guide sheet, xls, Java something rather. CHUCK: So, you are trying to figure out how to turn XML into a four letter word? JAMISON: [Laughs] AJ: It already is. CHUCK: Three letter acronym into a four letter word. AJ: XML. XML. So when you use XML, and you go to XM-Hell. CHUCK: So my big thing with that is that, I mean a lot of the enterprise solutions out there use XML and ultimately, if you have a parser that understands what it’s doing with the XML, I don’t think it’s a big deal… AJ: But it’s different in every language. CHUCK: Yes. There is that and I mean even if there are standards like soap, that’s a four letter word. AJ: Yeah it is. CHUCK: You know it provides you with enough conventions for understanding it, but still it just doesn’t…  I don’t know, for me, I like to be able to read my APIs if I have to and that’s the big win for me with JSON is that I can glance at a single object and I can figure out what it’s about, without having to read this entire document to figure out – or this section of the document – to figure out what it’s doing. And the other thing that’s nice about JSON is that its less chatty, because I mean, you just annotate it with curly braces, colons and square braces. Whereas with the others, you are effectively using XML tags to do it. But I don’t think that’s a major loss just because I mean, we are talking about pretty minute amounts of data being passed back and forth. AJ: I think that the thing with XML that drives me nuts is there’s no standard for it and everyone uses it differently. Like Apple will open up a tag called like, you know, open the data tag and then type equals array and then like you can’t create a generic parser for XML because it won’t know what the heck to do with it. It won’t know whether to turn something into an array, or if it should turn it into property because there’s only one of them and then like the distinction between an attribute and a property and yeah, that might be if there’s no way to parse it. CHUCK: Right. So are there any issues with JSON between the different higher level languages? AJ: The only issue I know of is comments. Sometimes you just wanna be able to comment out of a line out of your config file, but in that case, you use YAML because YAML and JSON are one to one; they are both object notation. They are almost exactly identical. CHUCK: Right. It’s just white spaces instead of curly braces and… AJ: Well, YAML parses JSON, but JSON doesn’t parse YAML.  So JSON is a strict subset of YAML. CHUCK: Okay. JAMISON: I think Crockford said he didn’t allow comments because people were using them as parsing instructions and it’s just opened up a whole horrible can of worms that would have made JSON not simple. AJ: Yeah, they were doing like type hinting and stuff like that, like the kind of thing you do in JavaScript for the closure compiler. CHUCK: Well, now what people tend to do is they’ll have like a top level key or attribute on their JSON object, and then that will tell them what type or what object to  convert the value that has… AJ: And that’s perfectly appropriate. CHUCK: Yeah so, anyway, that’s one thing that I like about JSON. I’m actually putting together a webinar. I hate to use that word, mainly because they got a lot of blowback for using that word. I’m going to be doing some live online training – let me put it that way – on JSON sometime in June. I’ll have, hopefully I’ll have the sign up available here before this episode goes out and then people can go and sign up. And I’m going to be talking about like the different concerns that are, how to keep it secure, how to structure your JSON so that it makes sense. And the different approaches that people take to it so that you can communicate in the best way between your service and your consumer of your service. And I’m also going to bring up a couple of unconventional things that a few people have pointed out to me that I think are interesting that you can do with JSON to provide APIs and maybe a less standard, but maybe more useful way. AJ: Interesting. CHUCK: Yeah. So anyway, if you are interested in any of that, then I’ll put the link up in the show notes and you can go over there and just click on it sign up. I’m going to be charging $50/seat and it will probably be 1.5 – 2 hours. And then if you can’t make it on the day that I’m doing it, I’ll put it up for sale. I’ll probably put it up for sale for $50. The only difference is you won’t be able to ask your questions live and things, and get some feedback on what you’re doing. So you know, there’s an upside for being there. And you’ll get a digital copy if you come and listen live. So, anyway. AJ: Let me put on a plug real quick. So, here at SpotterRF, we use JSON as the data format and so, we have actually built a lot of examples for our customers where we got stuff in the difficult languages; Java, C#, C and we’ve kind of already discovered some of the gotchas with parsing it and we have little read throughs and that’s on our GitHub. And you can put a link on the show notes for that. CHUCK: All right. I just added the link. All right. Well, let’s go ahead and get the picks done. Jamison, what are your picks? JAMISON: So, my pick is Diablo III — and that’s why I haven’t slept very much this week. CHUCK: [Laughs] I asked my wife if I could buy it and she said, “Well you haven’t beat Skyrim yet,”  is basically what she told me. JAMISON: [Laughs] CHUCK: Because I’ve played it a little bit. I haven’t played it a lot. JAMISON: If you get it Chuck, hit me up. We’ll play some time. It’s great. CHUCK: Can you play it together online? JAMISON: Yeah. So the raging cords of the Internet are grumpy because it’s always online and I agree that’s a horrible thing for possibly a single-player game, but that means you can play online really easily. That’s the one upside. CHUCK: So Diablo III is all online? JAMISON: It’s all online. If you are playing by yourself, you’re still connected to a server. CHUCK: Really? JAMISON: Yeah. CHUCK: What if I wanna play it on my laptop and I’m on the airplane or something? JAMISON: Then Blizzard does not care about you, Chuck. CHUCK:  [Chuckles] Oh, man. Because that’s something I like about like Diablo 2, is that it’s on my machine. JAMISON: So, it’s funny. I mean, the game is awesome, I love it, but I could rant for a long time about all the problems that all these online brings. They have a real money auction house, so you can pay real money to buy items in the game. CHUCK: oh, gee. JAMISON: That’s part of why they want everyone to be online so that everyone will be… I mean if you played it offline, they wouldn’t wanna let you in to the auction house because then you could have duped items and stuff. I mean, people get hacked for real money now instead of just your account got hacked and your character lost its item. Yeah, it opens up a whole can of worms. But regardless of that, the game itself is incredibly fun. CHUCK: Yeah so this is the second podcast within the last week that’s had Diablo 3 picked, so… JAMISON: [Laughs] If I don’t come to any other podcast episodes, you know why. CHUCK: [Laughs] It’s because you are in hell? Or XMHell fighting demons? JAMISON: [Laughs] Yeah its good metaphor for using XML. CHUCK: All right. Any other picks Jamison? JAMISON: That’s it. No time for the picks. CHUCK: No more music? Aww. JAMISON: The music to Diablo 3. CHUCK: [Laughs] They have a soundtrack? JAMISON: No. the music is great. Everything is great. It’s incredibly polished until it shines like a diamond. It’s so good. CHUCK: Yeah. You can even get like the flawless diamonds, right? You can still collect the gems? JAMISON: Yeah. Still have those. CHUCK: All right. AJ? AJ: So I’ve been having some trouble with my VPS. I’ve been using Thrust VPS and when I first was using them, they were really good company and I think there maybe bought by someone else or something. And so I personally haven’t had good results with them, and a friend of mine has had some trouble too. So last night, I started looking at Amazon EC2, and although its very corporate and enterprise — so lots of menus, it’s a little bit difficult to navigate through – but once you spend a couple of hours wrapping your head around what it actually is, it’s really simple. And I think I may switch to using the cloud service and if you are willing to pay like 3 years in advanced, they are cheaper than anyone else I’ve looked at. CHUCK: Pay three years in advance? AJ: Well, it’s kind of difficult to explain. You’d have to read it, but basically you reserve an instance for 1 year or 3 years. And if you reserve the instance, then your hourly rate is lower. So for your standard VPS,  that would be like better than what you would get with say, Rhino or Slicehost. They are the most basic one you get in like I think it’s 1 GB RAM, 160GB of storage space and 1 compute unit, which is like 1 GHz processor, and you pay $300 for 3 years plus 1.3 cents/hour. And so it comes out to about $420 or $12/month. CHUCK: Oh, Okay. AJ: So you get a heck of a lot more discs space and a heck of a lot more RAM if you are willing to pay for that 3 years to reserve it. And if you look at some of the other services to get that same amount, you’d be paying like $40/month anyway. And if you don’t reserve it and you don’t wanna pay in advanced, then the other services are cheaper like the Rackspace Cloud Hosting is cheaper than the non-reserved instance on Amazon. CHUCK: Cool. Good to know. Any other picks? AJ: So far, I’m interested in this Iced CoffeeScript. This might be a pick. CHUCK: Well pick it next week if you like it. All right. So yeah, the last few days I have been spending a lot of time writing my conference talks and stuff and so I haven’t had the chance to play with a lot of things either, but last night, I just, I got to a point where I was just done and I needed to just unwind. And usually, when I do that, I’d pull out one of my games like Skyrim or something and I’d like started Skyrim, but that was about all I had done. I hadn’t actually really gotten in and played it much. And so, I played it for like 2-3 hours last night and I really actually when, I first played it, I was like, “Ehhh… it’s okay.” But now that I’ve been playing it, I’ve really gotten into it. I really, really enjoy it. So my pick is actually going to be Skyrim. And I know I’m the big game on the market behind because the big one now is Diablo III, and that’s something that I really want, but I’ll probably just let my wife get it for me for father’s day and I’ll just keep hinting. “Gee, I’d really like it for father’s day.” I guess I do have another pick and this is something that I got for my wife for Mother’s day, besides getting her a gift certificate to get her nails done — which she loves doing — I also got her a Roomba and I have to say they are really, really cool. I got her a little bit older model, I guess the newer models are a little bit smarter and you know, do cool stuff. But you know, the little bit older model is really nice. You just push the button and then it just goes around and follows the walls and vacuums everything up and then it will go across the room and vacuum everything up. If you are used to doing vacuuming and you like cutting all the lines that go the same way in the same place yeah, the Roomba isn’t so much like that. It kind of hits the wall and then says, “Okay I’m going to turn this far and go that way.” And so you get these lines going all over across the floor. But if you have kids that drops cereal on the floor in the morning when you feed them breakfast, then the Roomba really nice for going over and picking it up. And it’s probably a little more sanitary than letting your dog or your 9 month old go over and clean them up. Anyway, those are my picks; Skyrim and Roomba. And I’ll have links to those in the show notes as well. So let’s go ahead and wrap this up. Just one more time, I just wanna remind you that I am going to be doing the JSON APIs live online training. I’m also going to be doing a Beginning Ruby and Rails online training as well, I’m also going to be it looks like putting together the CoffeeScript course for Lynda.com. So keep an eye out for that as well and I’ll let you know when it’s up. Is there anything else that we wanted to go over guys before we wrap this up? JAMISON: I don’t think so. CHUCK: All right. Well, thanks for listening. If you have any feedback for the show, go to javascriptjabber.com and leave us a comment. We do get comments every so often and I need to go play with Node.js so that I can fall in love with it the way you guys have. But anyway, we’ll wrap this up and we’ll catch you all next week. JAMISON: See ya! AJ: Peace!

x