text:
159 JSJ Why JavaScript Is Hard
02:54 - Everyone Gets It But Me
04:06 - Tools You "Need" to Know
06:29 - Clojures
07:39 - JavaScript as "Object-Oriented" vs "Event-Oriented"
Object-Oriented Programming
09:30 - Code That Can't Be Serialized or Deserialized
10:49 - Clojures (Cont'd)
14:32 - The DOM (Document Object Model)
[YouTube] Angular + React = Speed by Dave Smith @ ng-conf 2015
19:52 - Math Is Hard
IEEE754 (Floating-Point Arithmetic)
22:39 - Prototypes
Sebastian Porto: A Plain English Guide to JavaScript Prototypes
25:43 - Asynchronous Programming
Gregor Hohpe: Your Coffee Shop Doesn't Use Two-Phase Commit
How Do You Learn It?
32:23 - Browser Environments
34:48 - Keeping Up with JavaScript
35:46 - Node
Context Switching
42:48 - UTF-8 Conversion
44:56 - Jamison's Stack
io.js
Webpack Check out and sign up to get new on React Rally: A community React conference on August 24th and 25th in Salt Lake City, Utah!Picks
Jason Orendorff: ES6 In Depth (Aimee)Cat Strollers (Aimee)Stephano Legacy of the Void (Joe)A Gentleman's Guide to Love and Murder (Joe)Gregor Hohpe: Your Coffee Shop Doesn't Use Two-Phase Commit (AJ)Firefox OS (AJ)Flame (AJ)OpenWest 2015 (AJ)801 Labs Hackerspace (AJ)Stack Overflow Careers (AJ)Dota2 (Jamison)Beats, Rye & Types Podcast (Jamison)JS Remote Conf Talks (Chuck)Workflowy (Chuck)
JAMISON: Now what have y'all been doing lately with JavaScript? JOE: Let's see. CHUCK: Ignoring it.[This episode is sponsored by Frontend Masters. They have a terrific lineup of live courses you can attend either online or in person. They also have a terrific backlog of courses you can watch including JavaScript the Good Parts, Build Web Applications with Node.js, AngularJS In-Depth, and Advanced JavaScript. You can go check them out at FrontEndMasters.com.]**[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco, New York, and L.A. bid on JavaScript developers, providing them with salary and equity upfront. The average JavaScript developer gets an average of 5 to 15 introductory offers and an average salary offer of $130,000 a year. Users can either accept an offer and go right into interviewing with the company or deny them without any continuing obligations. It's totally free for users. And when you're hired, they also give you a $2,000 bonus as a thank you for using them. But if you use the JavaScript Jabber link, you'll get a $4,000 bonus instead. Finally, if you're not looking for a job and know someone who is, you can refer them to Hired and get a $1,337 bonus if they accept a job. Go sign up at Hired.com/JavaScriptJabber.]**[This episode is sponsored by Wijmo 5, a brand new generation of JavaScript controls. A pretty amazing line of HTML5 and JavaScript products for enterprise application development in that Wijmo 5 leverages ECMAScript 5 and each control ships with AngularJS directives. Check out the faster, lighter, and more mobile Wijmo 5.]**[This episode is sponsored by DigitalOcean. DigitalOcean is the provider I use to host all of my creations. All the shows are hosted there along with any other projects I come up with. Their user interface is simple and easy to use. Their support is excellent, and their VPS's are backed on Solid State Drives and are fast and responsive. Check them out at DigitalOcean.com. If you use the code JavaScriptJabber you'll get a $10 credit.] **CHUCK: Hey everybody and welcome to episode 159 of the JavaScript Jabber show. This week on our panel, we have AJ O'Neal. AJ: Yo, yo, yo, coming at you live from a west-facing basement in Provo, Utah. CHUCK: Aimee Knight. AIMEE: Hello. CHUCK: Joe Eames. JOE: What's up? CHUCK: Jamison Dance. JAMISON: Hi friends. CHUCK: I'm Charles Max Wood from DevChat.tv. And this week we're going to be talking about some of the things that are hard to grasp about JavaScript. Not that there's anything that hard, right? JOE: No, not according to Douglas Crockford. CHUCK: That's right. We should just make everybody feel dumb if they struggle with it. JOE: [Chuckles] The answer is nothing and then it's 30 minutes of silence while everybody that listens to the podcast is like, "Aww." AIMEE: [Chuckles] Aww. [Chuckles] JAMISON: This is what I'm doing in my head right now, is like, "Aww. I struggle." CHUCK: So, does anyone have anything they want to start off with talking about? JOE: I would like to mention that feeling that I frequently get when I'm in a room, and people talk about something either about JavaScript or something else. And everybody in the room is like, "Oh yeah, totally." And they all know what they're talking about, and I don't. That happens actually on this podcast sometimes. And then I hide silently in the corner and think, "I better google that." [Chuckles] CHUCK: [Laughs] AIMEE: So, that feeling doesn't go away. JAMISON: [Laughs] JOE: No. This is 20 years in and it only gets worse. You do more things. As time goes by you start doing more things. And people expect you to know more stuff. AIMEE: Yup. JOE: I will say that I met this guy who was an architect once, and he didn't know who Martin Fowler was. And I got kind of upset. AIMEE: [Chuckles] JOE: So, if you've been in the industry for 20 years and you've been an architect, although I think it's a stupid title, and you don't know who Martin Fowler is, then I think it's okay to be ashamed. AIMEE: Wait, was I listening to, maybe it was Adventures in Angular, where you were saying that you feel that you should at least understand a little bit of the history? Or was that a different podcast? JOE: I have said that. AIMEE: Okay. JOE: A couple of times, probably on this one or that one. AIMEE: Okay. JOE: So, sorry I just bogarted into an entirely different subject. AIMEE: [Chuckles] JOE: Let's go back to JavaScript. AIMEE: Okay. JOE: Jamison, what were you going to say? JAMISON: This is a meta-list, or a meta thing that I think is hard about JavaScript. As abstractions around frontend and backend development in JavaScript have increased, the list tools that you "need" to know has gotten longer and longer. Need is in air quotes there. But if you ask 20 different people what you need to learn to become a frontend developer or backend developer, there are going to be 20 different versions of the same list. And you put them all together, and you end up with this incomprehensible to a beginner, and even to an experienced person who's maybe new to JavaScript, list of things you "have" to know. JOE: Yeah, I'll bet that's 60… JAMISON: Grunt and Gulp and Node. JOE: 60 items. JAMISON: Yeah, and IO and Angular and Ember and… [Chuckles] JAMISON: Bower and Webpack and Browserify and Sass. And there are just eight million billion things that you need to learn. AJ: Jamison, you're making it too complex. It's just IO.js, Bower, and LESS. [Laughter] JOE: Wow, what an arbitrary list. JAMISON: Yeah. That's… CHUCK: Yeah. JAMISON: You're now number 21 on that list. CHUCK: Okay, go build an app. Those are the only tools you get. Go ahead. JOE: This is the exact opposite of an episode we had where we talked about the things you should know. CHUCK: Right. JOE: To be considered a senior developer. Remember that episode? JAMISON: Yeah. Well, I want to go back in time and just scold myself and say, "You should know that you don't have to know all the things that we say you have to know." CHUCK: [Laughs] JAMISON: That's the main thing that you should know, that you can become an amazing developer by knowing only a handful of things that everyone is talking about, or that it seems like everyone is talking about. CHUCK: I felt like we set the bar high for a senior developer. It's like, look if you're going to be a complete well rounded expert… but yeah. JAMISON: But how many people really are well rounded experts in every frontend technology? There might be some. CHUCK: No one? JAMISON: Well, almost everyone that I know, even if they're fantastic developers, are still very specialized in some specific technology. They just pick up new ones faster than other people. But they still are very focused on the ones that they're using right then. JOE: It's really just Merrick Christensen. That's the only one. JAMISON: Yeah, yeah. He's in a class of his own. JOE: He's [really the worst]. JAMISON: He knows everything about everything. JOE: [Chuckles] Yes. JAMISON: But I don't. I know React. I used to know some other stuff and learning React pushed all the stuff I used to know out of my brain. AJ: [Those were all] important. JOE: The Sherlock Holmes brain theory. It's an attic. JAMISON: Yeah, yeah. CHUCK: So, one thing that I remember seeing when I was first getting started with JavaScript, and I can never remember the exact trick which tells me that I still don't completely understand it I guess, but it was the trick where it was demonstrating closures with the for loop. And… AIMEE: [Chuckles] CHUCK: You would use a function. And you would get the wrong answer. And I don't remember exactly how it went. But do you guys know what I'm talking about? It seems like it's this classic example. JAMISON: Yeah. AIMEE: Yeah, I remember that. JOE: Yeah. AIMEE: Or it's like the classic example of attaching a click handler. AJ: I don't know that example. JAMISON: Yeah. You end up attaching… AIMEE: Yeah. JAMISON: You end up closing over the wrong data or something like that. CHUCK: Yeah. And I know that it took me a while to really get my head around closures. Because most people come from sort of a more classical object-oriented or procedural language where functions aren't a first-class language feature. And they don't, they just don't behave the way that you expect them to because you're thinking, "Okay, this is a code block or an executable block." Or you don't realize that it's actually doing that. And the funny thing is that in the other languages that I work in like Ruby and Swift, they are closures and they close over stuff. It's just that for some reason, it's not as dangerous. AJ: I want to say that I don't like that people try to classify JavaScript as object-oriented. It is event-oriented. It is in its own class. It is unique. Maybe Go is also kind of event-oriented. It's more message-oriented. But JavaScript is not object-oriented. If you try to use object-oriented patterns in JavaScript, you're going to screw it up. JOE: Now, that just makes me feel dumb, this whole list. Because I know what an object-oriented language is and a procedural language and a functional language. But when you say an event-oriented language, I don't get it. AJ: Well, I don't know what else to call it. I don't know what the official name is because there's only one language that's that way and it's JavaScript. JOE: [Chuckles] AJ: JavaScript is event-oriented. Is there any other language you can think of that you focus on events? It's not this happens and then this happens. It's this happens and if that triggers an event, then this might happen. JOE: Isn't that like every UI technology like C# Windows forms and Java UI forms? And they're all truly event… you load up and then you just sit around and wait for the user to tell you to do something. AJ: I guess… JAMISON: I think that's more of a platform than the language. CHUCK: Yeah, I was going to say. I've done event-centric programming with an event loop in several languages. JOE: But I will back up AJ on this whole thing that if you try to do your typical OO stuff in JavaScript, that I think especially if you're not thinking about how best to adapt it to JavaScript, then things can really fall apart, whether they put classes, whether you have ES 6 classes or not. CHUCK: Yeah, but classes in that case are a way of managing basically data instantiation and managing behavior. And so, it's just another place to put stuff. AJ: Okay, that's something I think is hard in JavaScript. When people write code that can't be serialized and deserialized. Because so much is network-oriented in JavaScript because you're looking at the browser and the server. And the page could refresh and you might have to put something in local storage. It's such an unpredictable environment that if you ever end up with an object that can't easily be serialized and deserialized meaning you can put it out to a string and then read it back and then get the exact same object with the exact same state, then you can get really messy stuff really fast. JOE: You're getting way meta on me. CHUCK: I know. And I have to disagree here, too. Because ultimately you have objects in JavaScript. And they're basically like JSON structures, right? But you can assign different attributes to have different functions. But if you're using prototypes then you can effectively initialize with the data and use the prototypes to build the behavior back in. AJ: That would be a great pattern. That is a good pattern to use. I'm AJ O'Neal and I approve of that pattern. CHUCK: Yeah, but then you serialize and deserialize by extracting the data and then using the same prototype to rehydrate. AJ: Yes, that sounds good. Yes. JOE: Okay, time. I want to go back to closures. Aimee. [Laughter] AIMEE: Well actually, I was just going to say from a new person's perspective, that's a very popular junior interview question. And prepping for my interview it seems there's so many very technical answers to that question. And I feel like the best way to explain it or to understand it as someone new is to actually use it for information hiding. And that's the best way that I was able to explain it, is by actually having a practical example. CHUCK: That makes sense. And I have to say that that's one of the examples when I was reading books. Of course, I had been professionally developing for five or six years before I understood closures. And it was because I started talking to people about JavaScript. And yeah, it was that example and a couple of others that really clinched it for me. Oh, okay. I get what's going on here. JAMISON: So, we mentioned in the beginning of the show the topic was things that are hard about JavaScript. I think we should amend that to, and what do you do about it? So, Aimee talked about a solution with closures being [a little confusing], is you just use them a lot. AJ: [Chuckles] JOE: Well, that's the solution to everything, right? [Chuckles] JAMISON: Yeah, I guess yeah. CHUCK: [Chuckles] JAMISON: I guess Aimee solved it. Podcast is over. JOE: Podcast over. [Laughter] JOE: Besides, I think it's way better than just present a whole bunch of problems and no solutions. [Chuckles] CHUCK: That's right. JAMISON: I do that at work all the time. It's great. [Chuckles] AIMEE: I was going to touch on one other thing from a beginner's perspective, as long as we're close to that. And that was, this is what I was saying before the show that I thought I had, I don't know, some decent thoughts on this. So, when I initially started to learn to program the very first language I chose was JavaScript because it's so easy to just do it in your browser. Which is great, but as you get more advanced from a beginner, teaching myself and teaching myself in a vacuum where I didn't have a whole lot of people around me to ask for help, you start getting into… naturally they want you to do OOP in JavaScript. It just was like, "Oh my god. I have no clue what's going on" And so, you look at all this documentation and tutorials on how to learn. And it's always trying to compare it to a more object-oriented language. And without that context as a beginner that was really hard. So, for JavaScript I think it really helped me to learn the basics of just UI interactions. And then go back and learn a more object-oriented language. I chose Ruby. And then I came back to JavaScript and it helped solidify things. JAMISON: So, you're saying that JavaScript is kind of a tool to see the effects of your work faster, maybe? AIMEE: Yeah, JavaScript was really good yes, as a beginner immediately. You don't have to set up an environment like you would for Ruby or learning Rails or something like that. It's just very overwhelming for someone new. But then having the context once I got into a more object-oriented language of, oh, this is what object-oriented programming is in an easier language that shows that, then going back to JavaScript, it was a lot easier to understand the prototype chain and how inheritance is working there. You're reading all these words and terminology and stuff and you just don't have the context, because JavaScript's so different. AJ: Yeah. It is a very difficult language. It's beautiful because it's in the browser. But it's ugly because it's JavaScript. [Chuckles] CHUCK: No, it's ugly because it has all that punctuation in it. [Chuckles] CHUCK: Says the Ruby guy. [Chuckles] AJ: I think that it is… JOE: Hello, CoffeeScript. AJ: A beautiful language. But it does have parts that are definitely [inaudible]. AIMEE: So, that's what I was going say. When I got done with the bootcamp and I had to decide what I wanted to do, the fact that JavaScript's so different and is powerful in that way, that's why… I don't know. I wanted to have more of a challenge and it seemed… because it's so different, it was more of a challenge. And I really like that. JOE: Alright. I want to talk about my next item that I think is hard in JavaScript, which isn't actually in JavaScript. It's the DOM. AIMEE: [Chuckles] JOE: It's one of those… CHUCK: Dom-do-dom-dom. AIMEE: [Chuckles] JOE: One of those things that I do not know well enough. I'm going to tell you a little anecdote. I went and interviewed at Facebook. Just by pure chance I went within a week of when Merrick Christensen went and interviewed at Facebook. We both flew out to Facebook within a week and interviewed there for the same team, interviewed the same position. And they offered Merrick Christensen a job and not me. And the reason was as they were doing their 'Here, program this on the board,' Merrick was able to do it all in just raw, vanilla JavaScript. Manipulating the DOM, he did some complex thing on the board. And I'm like, "Man, I would never be able to do that," especially off the top of my head, trying to remember the raw DOM functions for selecting nodes and stuff, because I'm so used to being a stupid jQuery idiot. [Chuckles] AJ: Hey, there's nothing wrong with doing it in an efficient way that works. JOE: [Chuckles] Well, jQuery is a great abstraction over the DOM. There's no doubt about it. But there is value in knowing and understanding the DOM. And just having to constantly get onto the MDN and look up the DOM functions when I'm trying to do some DOM work, it just drives me insane. It makes me feel like an idiot. CHUCK: Well, the issue that I have with the DOM is that if you look at the HTML, that's what it derives the DOM from initially. But it's actually another layer on top of that. It's an object that, well it's a document object mapping, is what I think it stands for. JOE: Model. CHUCK: Model. But basically what it is, is it's an in-memory representation of what the HTML told it to be until something else told it to be something different. And so… JOE: Yes. Angular 2… CHUCK: So, it's this abstract thing. You don't actually… you know, yeah. And so, it's not something that you can actually look at and quantify well. Even the developer tools aren't perfect at telling you what's there. JOE: Right. So, Angular 2 is doing this thing where it's embracing the actual DOM. And in your HTML you reference the DOM properties and not the HTML attributes, which I think is actually really cool. Because just even screwing around with it a little bit I'm learning more about the DOM than I would have known otherwise, just screwing around with Angular 2. Even though I've been working in the frontend for a long time and dealt a lot with the DOM. So, one of the really cool features I like about Angular 2 is you're actually starting to work directly with the DOM in Angular 2 rather than the HTML representation of it. AJ: That seems weird to me because I thought the whole thing we learned with React was that the DOM is ridiculously slow and JavaScript is faster. JOE: Well, it's not a performance… in this particular case it's not a performance reason you do it. It's binding. And the DOM is definitely slow. But I'm not… go watch Dave Smith's talk about Angular and React. Angular 2 and React are pretty comparable on performance. But that's, it really has nothing to do with the DOM, which is funny. It's all about data binding that's the reason that it's slow. CHUCK: The thing that's interesting about it is that you're then working at the abstraction layer that the browser is working at, as opposed to the markup which… anyway. JAMISON: So, on the one hand you could say, "Well, why do you even have to know the DOM if stuff like jQuery or now libraries like Angular that…" AJ: Or Node. [Chuckles] JAMISON: Yeah, well if you only do Node, then you probably don't [need to know it]. AIMEE: [Chuckles] JAMISON: But if you do frontend stuff, at some point something is touching the DOM. Otherwise nothing's happening on your page. And it can be really useful to know what the abstractions you're using use underneath. Because it can help you reason about what's going on in weird situations. I think if you're on the happy path and everything is working fine, and you're not finding bugs because you're the best and you didn't make any, then you can get away with just using jQuery. But if weird stuff is going on, then sometimes it helps to be able to if not use the code, at least model what it's doing in your head underneath. So, I don't know. I don't think it's the worst to not now the DOM APIs very well. But it can be helpful to learn them. I actually like it for doing demos that don't depend on anything. If you're just showing someone how to code a button or something, it's really nice to not have to go to jQuery. You just add an event listener to a button. That's neat. AJ: I think that sometimes the DOM is difficult because people want to learn JavaScript and then they start getting confused by the DOM when it's not JavaScript. It doesn't return JavaScript objects. It doesn't have JavaScript methods. And I think an important part of learning a programming language is learning the language itself and I think sometimes with all the tutorials out there, with document.write and that kind of nastiness, it's hard to learn JavaScript itself, the language. AIMEE: I agree. JAMISON: Me, too. AJ: And that's one of the nice things about the Chrome console is you can just open it up and start tinkering with JavaScript. And you could go through a JavaScript tutorial without touching the DOM, without touching Node, just the language, right in the console. That is a beautiful thing. I also wanted to bring up math is hard in JavaScript. And that's not unique to JavaScript, because we have a standard that guarantees that everyone who follows the standard will get math wrong. Good old IEEE754. But one of the things that's difficult with math, and part of this is the DOM and part of this is JavaScript, because it's APIs that use math that make the math hard. But when the value has to be between zero and one instead of say zero and the largest possible integer in JavaScript which I think is, depending on who you ask and what day of the week it is, 2 to the 32nd or 2 to the 48th or 2 to the 64th. But anyway, because if you want to decrement… let's say you have a volume control and you want to decrement that volume which is in the DOM API in increments of 100, you do subtract zero, one and you do that and you expect that at some point you're going to get zero. Because if you subtract .01 a hundred times you should have nothing left over. And then your application goes into an infinite loop and crashes. And that's hard. And that's effective in some of the JavaScript native stuff as well as DOM and Node and lots of libraries. You guys have experience with that or other math problems? CHUCK: You're talking specifically about the floating point stuff, right? AJ: Yeah, just the inconsistency where you can add one to something and then it'll actually not increment if it's in that specific range of values that don't increment above 32 bits. And floating point where if you subtract numbers you don't get the mathematical value that you expect. JOE: I just try to avoid using numbers in my coding. And then everything's okay. AIMEE: [Chuckles] JAMISON: Yeah. [Inaudible], everyone. AJ: I try to convert back and forth to integers. JAMISON: I just type them out in English. [Laughter] AJ: So, [inaudible] CHUCK: I use Greek letters. AJ: That's an interesting idea for a big int library. [Chuckles] AJ: One hundred minus one… AIMEE: [Laughs] JAMISON: Yeah, it's like you're writing a check. AIMEE: [Laughs] AJ: That's good. JOE: Every time I have to do math, I make a REST call to a server I wrote in C and do the math there and then return the result. AJ: Question… JAMISON: That sounds real safe. [Laughter] AJ: Is C actually any better at math? JOE: I have no idea. [Laughs] JAMISON: It's faster. CHUCK: Yes. JOE: It's faster at math, that's true. JAMISON: [Inaudible] AJ: Especially with the REST call. That's an optimization technique. [Chuckles] JAMISON: Yeah. JOE: I do all my math through bit shifting. JAMISON: I do it all through HTTP calls. [It has] better speed. [Laughter] JOE: For speed. AJ: Not through bit shifting. JAMISON: [Chuckles] AJ: Not through bit shifting. JOE: Alright. JAMISON: Is anyone going to talk about prototypes? JOE: Why? They're easy. JAMISON: Oh. CHUCK: [Laughs] Yeah, sure. JAMISON: Well, yeah. Yeah, I mean, that's… JOE: That's what you meant? JAMISON: Me, too. Yeah. No, I think prototypes are a famous hang-up in JavaScript. CHUCK: Yeah. JAMISON: Haskell has its monad tutorial blog post that everyone has to write. And JavaScript has its prototype tutorial blog post that everyone has to write. AIMEE: [Chuckles] JAMISON: [Inaudible] other version of it. So, the prototype chain is fairly straightforward. There are weird things with the magic underscore, underscore proto stuff. AJ: Yeah, don't touch that. JAMISON: That's different from the prototype that you use to create classes and I don't know. Especially if you come from other languages, it can be a big hang-up for people. But it turns out you can get a lot of stuff done without knowing in depth all the ins and outs of prototypes. CHUCK: So, here's part of it that gets me hung up is the new keyword. I don't quite understand what it's doing when it's assigning the prototype off of another function. AJ: Yeah… AIMEE: I have a blogpost that I used to learn this stuff. And of all the ones I read, I'll have to link it in the show notes, it was incredible. So, I'd have to try to dig it out. JAMISON: I remember one time I had to, I couldn't call new on something but I had to fake like I did. And I can't remember why. But that was the only time I knew in my head word for word what new actually did. I kind of forgot it now. But I knew it at one point, so that counts, right? AJ: Have you ever had to add an asynchronous something or other into a constructor? JAMISON: Yeah. AJ: And then you have to rewrite the object and all the code around it because you can't call new on it anymore. JAMISON: Why not? AJ: Because you can't return the object because it doesn't exist yet. JAMISON: Oh, yeah you can. You just change it. AJ: Well, but then you start using it and the async call hasn't finished so it's not initialized. JAMISON: Yeah, you just have, I don't know. I think it's pretty common to have libraries that have, like when you create connections or something there's a callback. And those might be using constructors underneath but they're not returning to the callback outside of that until stuff is fully initialized. I think there are ways you can get around that. AJ: Well yeah. Yeah, there's definitely ways you can get around it. What I'm saying is if you have an object where initially for whatever reason it's not, there's nothing asynchronous about it but then for some reason you need to add some async call. And you were doing that logic in the constructor. You have to then move it out to an initialize function and then you have to return a promise or a callback or whatever on that initialize function, which then means that you have to change more code up the scope, [up the chain]. JAMISON: I think that applies to anytime you introduce asynchronicity where it didn't use to exist though. It always bubbles up. AJ: Yeah. So, I think the solution there is just always assume that every function's going to be asynchronous. Then you never have a problem. CHUCK: Speaking of asynchronous stuff, one thing that's hung me up in the past is debugging it. So, just figuring out where something broke because it doesn't bubble up the same way all the time. AJ: A call stack? CHUCK: And give you a stack trace that you can follow. Yeah. AJ: JQuery, line 1. [Laughter] AJ: Column 10,836. CHUCK: Yeah, exactly. AJ: Ajax return [inaudible] error. CHUCK: Or even better, it's on line 3 because it minified it. AJ: No, it's on line 1. You missed that. It's line 1, column 13,002. CHUCK: Yeah. JOE: Right. JAMISON: So, some of these things are still definitely problems. But they can be less of problems as tooling has gotten better. Chrome supports asynchronous call stacks if you check a little box in the dev tools. It'll… AJ: I need to check that box right now. [Chuckles] JAMISON: Yeah, it keeps track. It still fails sometimes but I don't know what causes it exactly. But it seems like it's helped a lot in keeping track of the call stack. AJ: Is it a performance issue? Is that why it's an optional checkbox? JAMISON: Yeah, yeah. They have to… I think it uses more memory because they have to keep track of more stuff. If you're using source maps as well, then oftentimes the locations in code of the stack traces will be a lot more specific and easier to understand. If you use promises everywhere, then those can give you better stack traces as well. But also then you have to use promises everywhere. So, there are… AJ: Which is good. That's a bonus. JAMISON: It's a double-edged sword. So yeah, there are some solutions to that. But I still find times where either I don't have access to any of those things or for some reason they didn't work. And I don't understand why. And then I just sit and think about what I've done and get sad. This is my punishment for creating a bug. I just have to sit here. CHUCK: [Laughs] JAMISON: Try and debug it in my brain. [Chuckles] I don't know. Yeah, so debugging asynchronous stuff, I think the way you get better at that is you use tools that help that, that make that easier. CHUCK: I thought you were going to say, do more of it like we [inaudible] before. JAMISON: Yeah, there are skills you can develop at it. But I think those skills apply to any kind of debugging. And the tools might be more helpful than the skills. Maybe not though. I don't know. AIMEE: Someone once gave me a really, and I think I read it on Stack Overflow, a really good example of, or a really good analogy for understanding that. And they explained it as you go into a restaurant and you don't have a waiter who is servicing one table. The waiter takes your order and then he puts it into the kitchen and then he goes about doing other things. So, he's just doing multiple things at once. I don't know. That analogy really helped it stick for me. JAMISON: Yeah, I like that one a lot. AJ: So, I'm going to link in the show notes the canonical example of that which is the article 'Your Coffee Shop Doesn't Use Two-Phase Commits'. Yeah. JAMISON: So, we've kind of moved onto talking about asynchronicity in general. Not just debugging it, but understanding it. I agree that that's a huge hang-up for people new to programming and also people new to the asynchronous… wow, that's a tautology. Asynchronous programming is hard for people new to asynchronous programming. [Laughter] JAMISON: I don't know. If you're language blocked by default then it will throw you for a loop when you send off stuff to be done and then your code will happily continue on without waiting for it to finish. AJ: I guess one of the things that helped me with the asynchronous stuff is the way that I came into it. I was working in Ruby when I discovered jQuery. And so, I did make rookie mistakes in jQuery with asynchronous stuff. But I was also, that was probably at the time that Event Machine was coming out and event loops in general were catching on all across the board. Python's Twisted, Ruby's Event Machine, whatever. Every language was getting one. JAMISON: Doesn't everyone in Ruby hate Event Machine though? CHUCK: No. It's not a tool that a lot of people use. But no, they don't hate it. JAMISON: Oh. CHUCK: They just don't use it. AJ: When I went from Event Machine to JavaScript to Node, it was like, "Wow, this is easy. Oh my goodness." But I'd also been learning asynchronous stuff in jQuery simultaneously. So, it was like I was coming from both ends. Like Aimee said, Ruby is kind of a little bit easier sometimes to learn. And even with the asynchronous stuff it was interesting to learn it that way because you can do the things you do in JavaScript but you encapsulate it in a class instead of just passing a single function around. And then C# and Java are the same way. You can do asynchronous stuff like you can in Node and in browser JavaScript. But it's more 'classical'. JAMISON: If you're new to asynchronous programming, how do you learn it? CHUCK: Pain. AJ: So, first… JAMISON: Pain. [Chuckles] AJ: Do an echo chat server tutorial in Python. Then don't shoot yourself. AIMEE: [Chuckles] AJ: That's the important next step, because you won't get any further if you do that. Then maybe try doing it in Node. Just start with that echo chat server type example. And if you try it in any other language and then you try it in JavaScript, you will immediately understand why JavaScript is superior for that type of programming. JAMISON: I don't know. I think it can be valuable to do it the hard way. You can even say you should drop down to kqueue or epoll or whatever and do it in C. I don't think you have to do it that way to learn it. And some people might be much better off by just learning it the easy way instead of having to learn it the hard way first. AJ: So, you're saying just jump straight into the Node example. Don't look at… JAMISON: Sure. Yeah, I don't know. AJ: Yeah. I don't know. Sometimes people ask 'why is this better?' It's so confusing for some people to learn how to do something the easy way when they don't understand what the problem is. Does that make sense? JAMISON: That makes a ton of sense. I felt that a lot lately, actually. I did SQL at the very beginning of my programming career but before I really knew what was going on. And I've been doing NoSQL for most of the time. And I'm coming back to SQL and it's really… AJ: Awesome. JAMISON: It makes me appreciate the things NoSQL does and also makes me appreciate SQL a lot better. Because I know what the tradeoffs are in a way I didn't before. And so, just yeah, you just stick a document in the store. You know why people wanted to do that and why some people hate it, too. I don't know. I understand why people rage against NoSQL. AJ: Well, it's really a right tool for the right job kind of thing. NoSQL is the best tool for some jobs and SQL is the best tool for some jobs. JAMISON: Anyway, sorry. That was a digression. It made me think of that, your points about learning stuff the easy way can sometimes shortcut some understanding about why it is the easy way. CHUCK: I want to bring one other thing up that I've struggled with, with JavaScript, and that is just different browser environments. AJ: Ugh. CHUCK: Yeah. That's what everybody says, right? And I've had several people mostly in other language communities, they're just like, "Well I hate coding in JavaScript because I'll get it working one place and then it has a memory issue on another browser." Or, "It has some security issue in this other browser." Or, "It just doesn't work in the other browser." Of course, that other browser is usually some version of Internet Explorer that they're required to support that's wicked old. But the thing is that yeah, it's really frustrating, especially when you come from other languages where you have some kind of benevolent dictator or something. Somebody like that that is more or less driving the feature set forward, how they envision it. AJ: Oh. CHUCK: So, instead of having the canonical interpreter. I'll use Ruby as an example. You have the MRI interpreter, Matz's Ruby implementation. And then you have things like JRuby and Rubinius. But they all implement the same API and they base it off of the canonical Ruby implementation. With JavaScript, you've got the different browser implementations that all pick and choose what they're implementing next from the current standard. And so, you get these different states of the world, depending on which browser people are going to use. And you have no guarantee that it's going to work. So, JavaScript isn't the same JavaScript everywhere. And that's one thing that was really both frustrating when I learned it and confusing before I learned it. AJ: Yeah, because there's not a benevolent dictator like in Python and in Ruby. Most frameworks have some sort of company or some organization, a group that's well-defined and JavaScript is like… there's Firefox wants to do it their way. And Google wants to do it their way. And Node wants to do it their way. And TC39 wants to do it the Java way. CHUCK: Yeah. JAMISON: We all want to do it the Java way. CHUCK: That is the better way. JAMISON: It is. AJ: Why is it called JavaScript, guys? Duh. CHUCK: I know, right? JAMISON: I wonder if people will ever not make that joke. I hope it continues forever. AIMEE: [Chuckles] AJ: Oh, it's kind of frustrating. JAMISON: It's like comfortable now, a comfy joke. AIMEE: So, even in addition to just browsers, I think JavaScript the language, it is like a wild west. And because there's not one set way to do things, there's always all this new stuff coming out. And that's a challenge trying to figure out… I think we were talking at the beginning what you need to learn. And keeping up is intense because there's just tons of stuff coming out 24/7. JAMISON: Yeah. It's really exciting but it's also kind of exhausting. Because there's cool stuff happening. AIMEE: Yeah, yeah. JAMISON: But also because I'm always, I just have this fear in the back of my mind… AIMEE: [Chuckles] JAMISON: That I'm trying to learn the wrong thing. AIMEE: Yeah. JAMISON: Or that I miss something cool. Or I don't know. AIMEE: Yeah. JAMISON: It's good and bad. AIMEE: It is. it is. It's totally good and kind of bad at the same time. I'm the same way. I'm just so excited to learn all the stuff. But then again, I need to have a little bit of a balanced life too. And it's hard. [Chuckles] JAMISON: [Chuckles] Yup. CHUCK: I have another one I'm going to jump on, and that is Node in general, is kind of this… I've played with it. I've used it in my workflows. I've tried writing apps in Express. Not… I haven't tried very hard. The thing that really gets me though is that I try and include an npm module and I guess I'm just used to Ruby gems. But npm, there's a lot of stuff going on there that I just don't completely get. And then on top of that, I think part of it's because it's both from the Ruby [inaudible] both Bundler and RubyGems in the same. AJ: Yeah. CHUCK: So, you can npm install and it pulls everything in, including the dependencies. But I've gone through dependency hell with it. And the other thing is that sometimes it pulls in libraries in Node that are browser-specific. And so, then I need some kind of virtual DOM or it just doesn't work. Or it's like, "No, this really was designed to run in the browser." And I've gotten confused with that before, too. JAMISON: So, I believe that that's a problem. I've heard other people talk about it, too. I've never encountered this specific problem of using things in Node that are supposed to be used in the browser. AJ: Yeah, I haven't… JAMISON: I'd love to talk to you more about that sometime. CHUCK: Yeah, I haven't run into it for a while. So, it might have gotten cleared up. But npm confused me for a long time before I kind of, "Okay. I think I know what's going on here now." AJ: The nesting of the modules was a poor choice. JAMISON: Those fighting words. AJ: Well, no. I mean, a much clearer solution would have been root level, XYZ at 1.5, not six levels deep XYZ without a version number. That's where the version hell is introduced. It solves part of Ruby version hell. But then it introduces a new type of Node version hell. CHUCK: There are tradeoffs. AJ: I think that we could have a perfect system. It's just… eh. It didn't work out that way. CHUCK: Yeah. I mean, the nesting is problematic for some things. But knowing that I'm just going to use the version of whatever library that I included and knowing that it's going to work instead of worrying about what version is installed globally, there are definite tradeoffs there. AJ: Yeah. One of the things I don't like about the nesting is memory consumption. And a lot of people don't think about that, because they're like, "Oh, it's a server. I can just…" CHUCK: Yes. AJ: "Fire up something with 64 gigs of RAM," except for when you're running on a Raspberry Pi. And then it's actually important that you don't have 54 different versions of the my_module CHUCK: Yup. JAMISON: Man, I feel like I've just complained a lot in this episode. AIMEE: You stole the words out of my mouth. [Laughter] AJ: [Inaudible] It feels good to get out. JAMISON: I think JavaScript is great. And I am super excited to be working in it. And there are some hard things about it. But I think they are balanced out by the community being really awesome. And also being really excited to learn and discover new things. And by the cool things that you can make with it. AIMEE: No context switching is awesome. CHUCK: See, I haven't found that to be a huge barrier for me. But… JOE: I will actually say that I think that when I do MEAN stack stuff, that the context switching is just as significant as when I'm doing something else on the backend. I noticed that. I thought when I first started doing MEAN, "Oh, this is going to be great. I'll be doing JavaScript in the server and in the client." And you get over to the Node layer from doing some browser stuff and you're like, "Oh my gosh. This is so different. I can't do that. I can't do that. I can't do that." CHUCK: I actually want to agree and just point out that when I tried playing with MEAN stack I went in with the expectation that Express was going to look at lot like Angular because people were saying, "Oh yeah, the frontend and the backend, they're like the same." JOE: [Laughs] CHUCK: No. JOE: It's so not. CHUCK: No. It doesn't work that way. And the other thing is it's not straight vanilla Express from what I gathered. They do add a few more conventions so that it plays nicely with the frontend. And vice versa with the backend. So yeah, there was still a learning curve and there was definitely still context switching between the two. JOE: Well, I would like to back up what Jamison said when he was saying that JavaScript is awesome. I came from C# which is a really great language. It is. It's an absolutely wonderful language. And it's typed, strictly typed. So, it has all these things that everybody's like, "Oh my gosh. Why would you want to use JavaScript? It's such a crummy language. It doesn't have all of these things. It wasn't designed by some of the world's greatest language designers and maintained by some of the world's greatest framework maintainers." And I guess people could argue with that. But whatever. The point being, I came to JavaScript and starting doing it fulltime. And even though there were all these things that were better about other languages, I still found it to be just lots of fun and really enjoyable to do JavaScript. JAMISON: You can't argue with fun. JOE: No. JAMISON: You can argue about technical stuff. But if you're just enjoying it, I don't know. No one can tell you, you don't enjoy it. JOE: Yeah. There are challenges but I like the challenges. And I like the fact that it feels a little bit like the Wild West. So many unsolved problems that you can solve. And it's just fun to be here. It's cool new things happening and I like that everybody was doing Gulp and Grunt and Browserify. And now a whole bunch of people are saying, doing Webpack and saying "This is the new cool thing." And I just like that rapid change of pace. It makes me feel… AJ: It definitely is a lot of iteration. JOE: Yeah. It sure is. AJ: And there's a lot of good that comes out of that. JOE: Yeah. This could be funny because somebody's going to listen to this podcast in three weeks and be like, "Webpack? Oh my gosh, that was so long ago." [Chuckles] CHUCK: Yeah. JAMISON: I wonder if I'm just going to get fed up and be like, "I'm taking Webpack to my grave." [Laughter] JOE: That's it. I'm going to learn Fortran. JAMISON: I'm just an old fuddy-duddy now. JOE: And I'm sticking with that. [Chuckles] JOE: I'm just going to stick with Fortran. JAMISON: ES 7 for life. Who needs this ES 19 stuff? AJ: No. Seriously, I'm sticking with ES 5. I'm taking a couple of things. JAMISON: But yeah, that's... yeah, we have one of those among us. JOE: I'm going to do ES 5, HTML 4 and CSS. And forget the rest of it. JAMISON: No, yeah. Okay, no, all the numbers have to go down. So, ES 5, HTML 4, CSS 3. [Chuckles] JAMISON: I think there's a DOM 2. And then we need something with a 1 in it. AJ: Go. JAMISON: Yeah, yeah. Go [inaudible]. JOE: Backbone 1.0? JAMISON: Backbone 1.0. That's… CHUCK: There you go. JAMISON: And then we need a cool name for that stack and then it'll catch on like wildfire. [Chuckles] AJ: It does seem to be a lot more about the name of the stack than the technology sometimes. JAMISON: Yeah. AIMEE: How is that… JAMISON: Marketing's important. I don't know. That's not bad. JOE: Yeah, I was trying to think of some good acronyms for using RethinkDB instead of Mongo for some things that Mongo's in the acronym like MEAN. And REAN… [Laughter] JAMISON: What even is that? JOE: RethinkDB, Express, Angular, and Node. AJ: So, there are two things that bug me that maybe there's a solution for. So, I want to poll you guys. One is utf8 conversion. JavaScript has got to be so crazy because they went through and they added binary arrays and all this stuff. And they still haven't added a function that can just convert a string to binary and back. So, we can convert images back and forth to canvas. We can change format from JPG to PNG. How the heck do you get from a string to binary buffer? Anybody know? JOE: I don't know. JAMISON: I didn't understand your question, so… CHUCK: Pink! AJ: So, I have this… JAMISON: [Inaudible] problem. AJ: I type in var str = "I feel great today". I want to turn that into an array buffer or a buffer binary or a uint16. I just want to get it to be some sort of binary. And I want to be able to take some sort of binary and turn it into a string. And more importantly, it can't just be that string. It has to be a string that has a four-byte UTF8 character in it like the radioactive snowman. JOE: [Laughs] Wait, you left me. CHUCK: I'm lost. JOE: I'm lost. JAMISON: I think we'll appeal to the audience to answer that one. AJ: Back and forth between string and binary. That's the question. JOE: No idea. I don't know. JAMISON: I don't know. JOE: Avoid that situation. AJ: Never had to do that? JOE: Avoid it. CHUCK: I've had to do it in Ruby. JOE: Don't do it. JAMISON: [Chuckles] Just don't do it. AJ: Yeah, in Ruby you can do it, right? JOE: Go to a real language and do it. AIMEE: [Chuckles] AJ: Ruby has UTF8 encoding and all that. So, you can flip-flop. But JavaScript still doesn't have proper UTF8 support. There's no way to… JOE: RPC call to a Java instance and do it there. AIMEE: [Chuckles] AJ: Well, sure. But how do I transmit the data over? Because I'd have to get it… JOE: UTF… no, you encode it. AJ: Like, do the backslash thing with the backslash 'x'? JOE: [Laughs] Just throwing out random crap now. [Laughter] JOE: Alright. I want to… CHUCK: You light it on fire. JOE: I want to talk about something new. I want to talk about Jamison's stack. Tell us what your stack is at your workplace, Jamison. CHUCK: There's a left turn. JAMISON: Well, for now (who knows what it'll be next week when new cool stuff comes out?), right now we're using React. We're using Koa, the Node framework. We're using RethinkDB on the backend. JOE: Okay. This is April of 2015. So, this is only valid for this week and next week. JAMISON: Yeah. JOE: But that is so the cool kids stack. AIMEE: [Chuckles] JOE: Like, we're cooler than you stack. [Chuckles] JAMISON: I think that's how it was chosen. JOE: This is like the stack that we chose this so we can look down our noses at everybody else. JAMISON: [Chuckles] JOE: Without looking down. We can just say, "Oh, well I'm doing Rethink, Koa, and React." And everybody will be like "[gasps] Wow." JAMISON: It gets weirder. CHUCK: [Laughs] JAMISON: So, we're using Flow. And we're using IO.js, not normal Node. JOE: Of course. JAMISON: Because it's too [inaudible]. JOE: Are you using Webpack? JAMISON: We are using Webpack. AIMEE: [Laughs] JOE: Yes, yes. You restored my faith. JAMISON: Yeah, we check all the current boxes. [Laughter] JOE: That is so exactly what that is. JAMISON: Yeah. AJ: I'm pretty sure that Node is synonymous with IO.js now because you can't get a current version of Node. So, it's either IO.js or some two-year-old version of Node. CHUCK: Wow, you're just going to keep going after them for that. Aren't you? [Chuckles] AJ: No, I just… IO.js is not weird or new. It's just… we call it Node but it's IO.js and that's okay, kind of. I don't know. CHUCK: Alrighty. Well, let's go ahead and do some picks. Aimee, do you want to start us with picks? AIMEE: Yes. So, the first one that I was going to pick, there was a guy at the bootcamp that I went to who worked for Mozilla. And he would come and do talks. And he was absolutely awesome. And I just saw that he has an ES 6 blogpost series out. So, I know there's tons of other information out there on this. But I just know firsthand that he was really good. So, I wanted to pick that one. So, I'll include a link. And then the second one, because we talked earlier in the show and I had talked to Jamison about this a couple of weeks ago. My second pick is cat strollers. [Chuckles] AIMEE: Because I am not a mom to a human being, I am a mom to a cat. And I absolutely love my cat. And I think my husband bought this as more of a joke. So, it's a cat stroller. And the best thing about it is you can just go walking through your neighborhood and everyone comes over and says, "Oh, let me see your baby." And lo and behold it is not a… [Laughter] JOE: Wait, is it made to look like an actual stroller? AIMEE: Yes, yes, yes. JOE: Like fake people out, make them think it's an actual baby? AIMEE: Yeah. Yes, that is the best part of it. JAMISON: That's amazing. AIMEE: Everybody gets so excited that they're coming over to see your baby. And it's a cat. [Laughter] JOE: Does your cat stay? AIMEE: Yes, he likes it. JOE: There's a net in there, right, that keeps the cat in? AIMEE: Yes, yes, yes, yes. There is a net. And we actually have a jogging stroller because I like to run so much. [Laughter] AIMEE: So… [Laughter] AIMEE: Okay. And then I just have to add one more thing. The best part of it too is, because this is more of a joke, not for real. We live in Baltimore and there are all these pigeon birds out all the time. And we live right by the water. So, we will take the cat in the stroller down by the water with some bread and [chuckles] put the bread on the bench. [Chuckles] And put the stroller up in front of the bench and then just walk back and wait for the birds to come in and watch [inaudible] reaction. [Laughter] AIMEE: It's priceless. [Laughter] AIMEE: So, everyone… JAMISON: That's cruel. AIMEE: [Laughs] Well, the cat can't get… I guess it's cruel for the cat. JAMISON: Yeah, it's cruel for the cat. I don't know. AIMEE: Because [inaudible] exercise his instincts and he can't… JAMISON: That's fine. You can tell I'm a cat person because I'm like, "Who cares about those stupid birds?" [Laughter] AIMEE: Anyway, so my pick is cat strollers. And if you have a cat, you should get a cat stroller. And that's it. [Laughter] JAMISON: That's amazing. CHUCK: I can just imagine somebody coming up, "You don't even look like you were pregnant." AIMEE: Oh, that's exactly it. People, you bring it out for spring and they're like, "Oh, you had a baby." I'm like, "No." JOE: I had no idea. [Laughter] AIMEE: This is our furry son. JOE: Did you adopt? [Laughter] CHUCK: Yeah. And Aimee and I torture our kids. I get it. AIMEE: [Chuckles] JOE: I highly recommend that everybody listening google cat stroller pictures and just look at them. AIMEE: [Chuckles] CHUCK: Oh, no. AIMEE: Oh, I have a link. I have a link. JOE: It's kind of like cheeseburger. AIMEE: I have a link to Amazon for this, to the exact one we ordered. CHUCK: I want to see what the Amazon reviews are for these things. AIMEE: [Chuckles] CHUCK: Alright. Joe, what are your picks? JOE: Alright. I got two picks today. The first one is StarCraft II's Legacy of the Void is in its beta phases and soon will be out. And I love StarCraft II as an e-sport. There was this player named Stephano who was a Zerg player and he was the most well achieved non-Korean player ever in StarCraft II. He retired a couple of years ago. And he'll come back just a little bit. And so, he's planning some StarCraft II Legacy of the Void videos. So, my pick is this double pick of Stephano and Legacy of the Void because Legacy of the Void's awesome. And it's bringing back lurkers which I think is totally cool. And Stephano is freaking awesome. So, that's my first pick. My second pick is because I just spent the weekend in New York for my wife's birthday, we went to four Broadway shows while we were there. And the one that I saw that I really just absolutely loved was called 'A Gentleman's Guide to Love and Murder'. And if you ever have the opportunity to see it, I highly recommend it. I was laughing my head off the entire time. Great show. And so, that'll be my second and final pick. CHUCK: Alright. AJ, what are your picks? AJ: Alright. So today, I've got good ones. So, first of all we mentioned a little bit there's that article 'Your Coffee Shop Doesn't Use Two-Phase Commit'. I think it succinctly describes the issue of asynchronous programming and why event-oriented programming or whatever you want to call it because I don't know if it has a legit name, is and why. Because computer in theory operate in-memory, but in reality we're operating on things that are happening at times that we don't know when they're happening. And so, in-memory just doesn't cut it. And that's the article, explains the analogy of the coffee shop. I'm also going to pick the Firefox OS and the Flame developer reference phone. So, if you haven't had a chance to get your hands on one and play with one, I don't know if they're still on sale or if they're waiting until they come out with the next iteration of them before they sell them again. But if you can get your hands on a Firefox phone it's just so cool to be able to access native APIs and do everything native but JavaScript is native, rather than some other language being native. So, I'm really excited about that. And OpenWest. OpenWest has been a pretty local Utah conference but then they changed the name to OpenWest. And they're trying to get more people to come in to it, too. And it's a conference that has 500,000 different tracks to it. So, there's something for everyone. And it's three days long. And if you just google OpenWest and get a ticket and come out and say hi to me, that'd be cool. And I'm also going to pick another Utah thing, 801 Labs. They have this… and I'm sure there's hackerspaces in other areas that do this, but they just have a couple of free classes a month. And then they have a day where you can just come in and work from the hackerspace. And so, I was just burnt out from the work I was working on. And so, I went in to the hackerspace and did stuff that was just not really super productive. But it was fun. And this other guy, we were working together reverse-engineering something. And it was just fun. It was a nice break. So, if you have a hackerspace in your area that does some sort of casual Friday or casual Monday or whatever and you can work from there, try it out sometime. And then lastly I will pick Stack Overflow Careers, because sometimes people ask you for a resume and you're like, "Ugh. It's the GitHub age, duh." And so, instead of actually keeping up a resume I just use Stack Overflow Careers. And occasionally I update that. And if they want the pdf because they must have a pdf, they can just click the button and then it'll give them the pdf. And I don't have to do anything. And I like that. CHUCK: Alright. Jamison, what are your picks? JAMISON: I have two picks. My first pick is I play a lot of Dota 2. When the new Dota 2 patches come out it's like a whole new game. And people get really weird. It's a changelog, right? You see software changelogs all the time. But it affects the game in all these minute ways. So, new patches come out and then people spend hours trying to digest them to figure out what it means and what the new secret powerful combination of heroes and items is and stuff. So, my first pick is the new 6.82 patch. My second pick is a podcast called Beats, Rye & Types. It's by a couple of people that do a lot of stuff with distributed systems. But it's not about distributed systems. It's kind of about the intersection between some kind of humanities topics and computing. They talk a lot about, for example they had an episode about learning. And they talked about learning to cook and learning to code, and the intersection between those two and how their experiences crossed over. They had an episode with the CTO of Rent the Runway Camille something, I forgot her name. And she's an expert on this distributed system that does this thing called Consensus which makes different computers agree on stuff basically. But she's a manager too, so they talked about the computing idea of consensus and also the idea of consensus in teams. And how you get teams to agree on things and do things together. And it's really well done. It's kind of short but it's also from a perspective I haven't seen a lot before. So, just another reminder that React Rally is happening in August. It's a React.js conference. It's going to be in Salt Lake, August 20-something. If you go to ReactRally.com then there will be either a landing page or a website describing the conference depending on when you go there. So, sign up for the mailing list to get more info or check out the site to get more info as well. CHUCK: Woohoo! JAMISON: Those are my picks. CHUCK: Alright. I've got a couple of picks. The first one is JS Remote Conf talks are up and public. They're on YouTube. I'll put a link in the show notes for the playlist that has all the talks in it. So, go check them out. Each talk is about an hour long. And they were awesome. I will warn you. If you go look at the schedule, I haven't updated it. If you look on the JS Remote Conf site, so one of the talks is me instead of whoever was supposed to be there because they didn't show. But yeah, they were great talks. We had everything from marketing yourself with John Sonmez. We talked to him a week or two ago. I did an intro to freelancing. Jessica Kerr talked about complexity being outside the code. And then we had a whole bunch of fun ones. We actually had a Q&A with the Angular Remote team. We had Craig McKeachie talking about MV* frameworks. Brad Midgley showed off his cars where he used Firefox phones to drive them around. Aaron came and talked to us about ES 6. So, just a lot of stuff, WebRTC which I need to go watch again. So yeah, so come check it out. And then the other pick I have this week is Workflowy. I've been trying all kinds of different to-do lists. I used OmniFocus for a long time. And then I just faded off of it. And so, I've been playing with some other things. Workflowy is kind of an outline/to-do list. And so, you can actually mark things off in your little to-do list. You can collapse them and show them and stuff. And I'm really enjoying it. I think the pro version actually allows you to share parts of your outline with other people. So anyway, go check it out. It's workflowy.com. And yeah, that's all I've got for picks. That was a lot of fun, guys. JAMISON: Yeah, thanks. JOE: Yup. CHUCK: Let's wrap it up and we'll catch everyone next week.[This episode is sponsored by MadGlory. You've been building software for a long time and sometimes it's get a little overwhelming. Work piles up, hiring sucks, and it's hard to get projects out the door. Check out MadGlory. They're a small shop with experience shipping big products. They're smart, dedicated, will augment your team and work as hard as you do. Find them online at MadGlory.com or on Twitter at MadGlory.]**[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] **[Bandwidth for this segment is provided by CacheFly, the world's fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]**[Do you wish you could be part of the discussion on JavaScript Jabber? Do you have a burning question for one of our guests? Now you can join the action at our membership forum. You can sign up at JavaScriptJabber.com/jabber and there you can join discussions with the regular panelists and our guests.]**
Get JavaScript Jabber in your inbox


text:
David S. Evans
Chairman, Boston
Antitrust and Competition Policy; Labor and Discrimination; Financial Regulation
Ph.D., M.A., Economics, University of Chicago
Dr. Evans is the Chairman of Global Economics Group, LLC and based in its Boston office and the Co-Executive Director of the Jevons Institute for Competition Law and Economics at University College London where he is also Visiting Professor. A specialist in the field of industrial organization, he has authored 6 major books, including two award winners, and more than 100 scholarly articles, which have been widely read and cited. He has BA, MA, and Ph.D. degrees in economics, all from the University of Chicago.
A substantial portion of his research, writing, teaching, consulting, and testimony in the last 20 years has concerned multisided platforms. His most recent book on this topic, Matchmakers: The New Economics of Multisided Platforms, co-authored with Richard Schmalensee and published by Harvard Business Review Press, won the 2017 Gold Medal in Economics for the Axiom Business Book Awards. His academic work was cited extensively by the US Supreme Court in State of Ohio et al. v. American Express.
Dr. Evans have taught classes on antitrust economics, and related topics concerning industrial organization and intellectual property, at the University of Chicago Law School, University College London Faculty of Laws, and Fordham University Law School. He has taught specialized courses on multisided platforms since 2012 and on the digital economy since 2016 at the University College London, both of which are live streamed to competition authorities around the world for instruction of officials and staff.
Dr. Evans's expert work has focused on competition policy and regulation. He has testified in federal and state courts, and before arbitration panels, in the US and submitted oral or written testimony to courts in the European Union, China, and other jurisdictions. He has also made submissions to, and appearances before, competition and regulatory authorities with respect to mergers and investigations in the US, EU, China, and other jurisdictions.
• T-Mobile acquisition of Sprint. On behalf of T-Mobile and Sprint, submitted declarations to the FCC concerning the dynamic effects of the proposed merger on cellular data prices and capacity, the competitive investment of other carriers, and the likely value of 5G capacity. The FCC and US Department of Justice approved the merger.
• Apple v. Qualcomm. Testimony on behalf of Qualcomm related an antitrust and intellectual property issues arising from the licensing of standards essential patents subject to FRAND commitments. Expert reports and deposition testimony. Apple and Qualcomm reached a settlement agreement at the start of trial.
• Federal Trade Commission v. 1-800 Contacts. Testimony on behalf of the FTC concerning the competitive effects of agreements between 1-800 Contacts and other online sellers of contact lenses that restricted certain forms of search advertising. Expert report and trial testimony on the economics of search engines and search advertising, market definition, and competitive effects. The Administrative Law Judge agreed with the FTC and the Commission affirmed the ALJ's decision.
• NACHA's interchange fees for Same Day ACH system. On behalf of NACHA, an association of most banks in the US which sets rules for the ACH system, submitted reports and made presentations to the Federal Reserve Board concerning the economics of established a same-day ACH banking network in the US, and the role of interchange fees in doing so. The Federal Reserve Board approved the pricing plan.
• Comcast's Proposed Acquisition of Time Warner Cable. On behalf of Netflix, submitted multiple declarations to the Federal Communications Commission in opposition to the merger and made appearances before the Federal Communications Commissions and US Department of Justice. Comcast withdrew the merger following opposition by the FCC and Justice Department.
• Qihoo 360 v. Tencent. Written testimony in support of Tencent before the Supreme People's Court, People's Republic of China, concerning Qihoo 360's market definition and abuse of dominance claims against Tencent. This was the first antitrust matter decided under the Anti-Monopoly Law by the Supreme Court of China. The Supreme Court affirmed lower court decisions in favor of Tencent.
• European Commission v. Microsoft. Oral testimony and written submissions before the Grand Chamber, European Court of First Instance (now the European General Court) on behalf of Microsoft concerning economic aspects of the European Commission's Decision that Microsoft had abused its dominant position with respect to media players and server interoperability. Made several appearances, providing oral testimony concerning various topics, particularly with regard to abuse of dominance, over five days. The Court ruled against Microsoft.
HONORS AND RANKINGS
• Gold Medal Winner, Economics, 2017 Axiom Business Books Awards, for Matchmakers: The New Economics of Multisided Platforms (with R. Schmalensee)
• Winner of the Business, Management & Accounting category in the 2006 Professional/Scholarly Publishing Annual Awards presented by the Association of American Publishers, Inc. for Invisible Engines: How Software Platforms Drive Innovation and Transform Industries (with R. Schmalensee).
• A Top 2% of economists, IDEAS, based on average rank score (May 2017)
• Ranked 12th most downloaded economist and 15th most downloaded law professor, Social Science Research Network; ranked 243 out of 8000 economists and 16 out of 3000 law professors based on quality weighted citations (May 2017).
APPEARANCES IN COMPETITION AND
• In the Matter of 1-800 Contacts, Before the Federal Trade Commission, Office of Administrative Law Judges, Docket No. 9372. Testified in support of the Federal Trade Commission, concerning the competitive effects of agreements between 1-800 Contacts and other online sellers of contact lenses that restricted certain forms of search advertising. (April 2017).
• In the Matter of the Application of Securities Industry and Financial Markets Association For Review of Actions Taken by Self-Regulatory Organizations Administrative Proceeding File No. 3-15350. Testified in support of the Securities Industry and Financial Markets Association (SIFMA), concerning whether securities exchanges face significant competitive constraints in setting their fees for depth-of-book data products. (April 2015).
• Comcast Time Warner Cable Transaction, MB Docket No. 14-57, Federal Communications Commission, Economists Roundtable, January 2015, as well as several presentations to FCC senior staff and officials.
• Qihoo 360 v. Tencent. Written testimony in support of Tencent before the Supreme People's Court, People's Republic of China, concerning Qihoo 360's market definition and abuse of dominance claims against Tencent. (Written testimony filed for September 2013 trial). Also testified before the Guangdong High Court. (Written submission, April 2012)
• Presidential Emergency Board No. 243, National Mediation Board, Case Nos. A-13569, A-13570, A-13572, A-13573, A-13574, A-13575, and A-13592. Testified in support of the National Railway Labor Conference concerning wages, benefits, and work rules for railroad workers. (October 2012).
• Case T-201/04, Microsoft v. Commission of the European Communities. Testified in support of Microsoft before the Grand Chamber, Court of the First Instance of the European Union concerning the Commission's determination that Microsoft had abused its dominant position by refusing to license certain information regarding its operating system and by tying a media player to its Windows operating system. (April 2006).
• Case T-201/04, Microsoft v. Commission of the European Communities. Testified before the President, Court of the First Instance of the European Union in support of Microsoft's application for a suspension of remedies during its appeal of a Commission decision. (October 2004).
• Case T-201/04, Microsoft v. Commission of the European Communities. Testified before Hearing Officer of the European Commission concerning the Commission's determination that Microsoft had abused its dominant position by refusing to license certain information regarding its operating system and by tying a media player to its Windows operating system. (October 2003).
• I have also made appearances and submission to Australian Competition and Consumer Commission, Competition Commission of Singapore, Directorate General for Competition, European Commission, Ministry of Commerce, People's Republic of China, National Development and Reform Commission, People's Republic of China, U.K. Competition and Market Authority, U.S. Federal Reserve Board, U.S. Department of Justice, U.S. Federal Communications Commission, U.S. Federal Trade Commission, U.S. Securities and Exchange Commission
REPRESENTATIVE PUBLICATIONS
• Matchmakers: The New Economics of Multisided Platforms (Cambridge, MA: Harvard Business School Press, 2016). Published or pending translations in Chinese, French, Japanese, Korean, Russian, Spanish, Vietnamese. Gold Medal Winner, Economics, 2017 Axiom Business Book Awards.
• Invisible Engines: How Software Platforms Drive Innovation and Transform Industries, (Massachusetts: MIT Press, 2006), with A. Hagiu and R. Schmalensee. Translated into Chinese and Korean.Winner of the Business, Management & Accounting category in the 2006 Professional/Scholarly Publishing Annual Awards presented by the Association of American Publishers, Inc.
• Paying with Plastic: The Digital Revolution in Buying and Borrowing
(Massachusetts: MIT Press, first edition 1999, second edition 2005), with R. Schmalensee. Translated into Chinese.
• "The Antitrust Analysis of Multi-Sided Platform Businesses," (with R. Schmalensee), in Oxford Handbook on International Antitrust Economics, R. Blair and D. Sokol, eds., Oxford: Oxford University Press, 2015.
• "Attention Rivalry among Online Platforms and Its Implications for Antitrust Analysis," Journal of Competition Law and Economics, 2013, 9(2), 313-357.
• "Governing Bad Behavior by Users of Multi-Sided Platforms," Berkeley Technology Law Journal, 2012, 27(2).
• "The Online Advertising Industry: Economics, Evolution, and Privacy," Journal of Economic Perspectives, 2009, 23(3), 37-60.
• "The Microsoft Judgment and its Implications for Competition Policy towards Dominant Firms in Europe," (with C. Ahlborn), Antitrust Law Journal, 2009, 75(3), 887.
• "Designing Antitrust Rules for Assessing Unilateral Practices: A Neo-Chicago Approach," (with A. Padilla), University of Chicago Law Review, 2005, 72(1), 73-98.
• "Why Do Firms Bundle and Tie? Evidence from Competitive Markets and Implications for Tying Law," (with M. Salinger), Yale Journal on Regulation, 2005, 22(1), 37-89.
• "The Antitrust Economics of Multi-Sided Platform Markets," Yale Journal on Regulation, 2003, 20(2).
• "Some Economic Aspects of Antitrust Analysis in Dynamically Competitive Industries," (with R. Schmalensee), in Innovation Policy and the Economy, Vol. 2, A. Jaffe, J. Lerner and S. Stern, eds., Cambridge, MA: MIT Press, 2002.
Selected Viewpoints
The Antitrust Analysis of Rules and Standards for Software Platforms
The Impact of the U.S. Debit-Card Interchange Fee Regulation on Consumer Welfare
Why Apple Pay is Fizzling and What It Means for the Future of Mobile Payments
Interchange Fees: The Economics and Regulation of What Merchants Pay for Cards
Bitcoin's Roller Coaster Ride to Nowhere
Evans on How Proposed EU Payments Legislation Will Restrain Competition
Apple Pay, Now That We've Sobered Up
The Great Bitcoin Debate in Six Points
Bitcoin Isn't Ready for Prime Time
Our experts have worked on some of the most significant legal and regulatory matters of the last quarter century and have worked for many leading corporations and government agencies.

redpajama_set_name: RedPajamaCommonCrawl


The gaps between Festival events can be filled visiting displays and exhibitions. When refreshments are needed between events, there are many places to eat out in Chester, some in historic venues, even venues for festival events. See below a list of possibilities for minding the gap.


Congratulations to Shelby Vargo, Helena Gaifem and Yunqian Wei who all successfully defended their Master's work this month!
Congratulations to Dr. Silviya Zustiak who will be joining the St. Louis University Department of Biomedical Engineering as a tenure-track assistant professor in January 2013! We are so proud!
Congratulations to Alex Packard for winning a competitive Undergraduate Research Award!


This new development is just off the highway # 34 about 15 minutes from Jaco and 5 minutes to Playa Hermosa .
This is the perfect Retirement community with beautiful lakes throughout the grassy well laid out plan .
Water and electric are already in place along with new cobble stone streets .
The beautiful gated rock entrance is under 24/7 security along with the patrolled grounds .
This ideal location is just far enough away from any noise other than birds singing but close enough that a short 5 minute drive takes you to local restaurants .


text:
Angled Castor Colonises Ubin!
An Angled Castor perches on a blade of grass with its wings opened flat to sunbathe
Some time back in mid-Oct 2013, a solitary individual of the Angled Castor (Ariadne ariadne ariadne) was spotted in the Mandai forests in the northern part of the Central Catchment Area. Recorded as a re-discovery over 5 years ago, there were no further sightings of this species thereafter. Until recently, that is. Late last year, the Angled Castor was observed on Pulau Ubin.
A skittish Angled Castor beats a hasty retreat from its perch on a leaf of its caterpillar host plant, Castor Oil Plant (Ricinus communis)
Then there were more sightings of this species and the pristine condition of the individuals spotted suggested that they were not chance observations of seasonal migrants. This led to the theory that the Angled Castor had somehow managed to sustain a breeding population and that a colony of the species has established itself on Pulau Ubin.
A large grove of the Castor Oil Plant can be found on Pulau Ubin
Locating this colony was not too difficult, as the Angled Castor is not a rare species in Malaysia and Thailand, where the species can be locally common where it occurs. The key is to look for its preferred caterpillar host plant called the Castor Oil Plant (Ricinus communis). There is a site on Pulau Ubin where after clearance, the Castor Oil Plant grows in abundance.
An Angled Castor perched on a blade of grass in the early morning hours
When we visited this area on Pulau Ubin over the weekend, we found that a small colony of the Angled Castor had established itself in the vicinity of the host plants. A rough estimate of at least 30 adults and caterpillars were counted. Two adult female Angled Castors were even observed ovipositing on its host plant.
The leaves of the caterpillar host plant, Castor Oil Plant, reminds us of tapioca leaves
Firstly, let us consider the caterpillar host plant, the Castor Oil Plant. It has been described as an invasive species that colonises wastelands and cleared areas that have been neglected. It tends to form monospecific stands at the expense of other species of native plants and can displace other species due to its aggressive growth and the way the seeds can be distributed. In terms of plant biodiversity, it is considered an unwelcome "weed" that needs to be managed or eradicated.
Flowers, fruits and seed pods of the Castor Oil Plant
The Castor Oil Plant has a reputation of being a noxious weed and its seeds, if chewed and ingested, can have potentially fatal consequences to humans and animals. One deadly toxin, the notorious ricin is extracted from its seeds. Having been used as a terrorism weapon will not help its case! Furthermore, its commercial value of having the seed oil extracted for a variety of uses from cosmetics to lubricating oil and biodiesel does not exist in Singapore. Hence the plant faces the risk of being managed out of the eco-system in favour of other more useful plants.
A female Angled Castor ovipositing on the underside of a leaf of the Castor Oil Plant
Let us come back to the butterfly that depends on this plant of "ill-repute" for its survival, the Angled Castor. It is likely that a female of the species flew over from nearby Johor where it exists, and managed to oviposit on the host plants that grows on Ubin. That chance moment then started the next generations of individuals that now populate this area of Pulau Ubin.
An Angled Castor sunbathing on the top of a leaf
Besides the potential eradication of its caterpillar host plants, what are the other risks to the continued sustainability of the colony of this species in Singapore? Firstly, genetics should be considered. Will this very localised colony suffer from in-breeding and wipe itself out after a few generations? It is known that some species of butterflies are more vulnerable to in-breeding than others. If there are no new genetic material coming into Singapore from up north, can this colony survive?
Different instars of the Angled Castor's caterpillars found on the Castor Oil Plant on Pulau Ubin
What about predation? Given that the caterpillars and butterflies of this species are not known to be distasteful to birds and other predators, the delicate existence of this colony may also be wiped out by predation. The caterpillars are also in full view of areas with human activity and may be deemed as pests and eradicated.
Angled Castors appear to favour the flowers of this grass species for its nectaring source
Whilst observing the adult butterflies, they appear to be depending on their sustenance from the flowers of a particular species of wild grass. Several adults were seen feeding on the grass flowers. Other individuals were puddling on the damp muddy areas at the site. Whilst there are areas nearby with nectaring flowers, the Angled Castor has not been seen beyond the confines of this small area, nor to feed on other flowering plants so far.
The Angled Castor is the sole representative of the subfamily Biblidinae of the family Nymphalidae in Singapore. The butterfly is dark reddish brown with thin black squiggly lines on the upperside of its wings. There is a prominent white sub-apical spot on the upperside and underside of the forewing. The underside is a duller brown and similarly streaked with black lines but having a more 'banded' appearance in the darker areas between the lines.
The butterfly superficially appears like the Chocolate Pansy (Junonia hedonia ida) and is equally as skittish. Males of the Angled Castor have been observed to engage in 'dogfights', probably in their quest for territorial space. From our observations, the butterflies can fly for long periods of time with occasional stops to rest with their wings opened flat.
A newly-eclosed Angled Castor still hanging on to its pupal case
A puddling Angled Castor feeding on moisture along a footpath
At the Ubin site, several instars of caterpillars were found on a single host plant, suggesting that the eggs have been laid at different times over the past month or so. A newly-eclosed female was chanced upon, still hanging onto its pupal case. From the number of individuals observed this weekend - both pristine and tattered/weathered adults, it is obvious that the colony has been thriving at this location for the past few weeks, if not months.
An Angled Castor perched with wings folded upright, showing its undersides
For a species that is considered a "very rare" seasonal migrant to Singapore, it is now "very common" at this localised area on Pulau Ubin and from the breeding population, it can be now be assumed to be an extant species here. The status of various species can change from time to time, depending on circumstances and ecological and environmental changes that affect their existence in a country. It remains to be seen for how long this re-discovered species can continue to survive in Singapore, and whether natural or human-initiated threats affect this colony in the longer term.
Text by Khew SK : Photos by Khew SK, Loh Mei Yee and Tea Yi Kai.
Posted by Commander at 11:14 PM 1 comments


Cyber Safety is an issue relevant to all and this training offers best practice advice and support around how school communities can best protect themselves and deal with issues. The theme throughout all sessions concerns digital citizenship and what responsibilities that involves. Please note schools are welcome to request additional/amended content they deem appropriate to their student, parent and teacher needs. This can be helpful where a school has a concern around a specific issue to do with online behavior that a general workshop may not address.
The following is an outline of the content included for Parent, Student/Pupil, and Teacher/Principal workshops.
The workshops require few resources and can be delivered in a variety of room environments. Regards equipment a class data projector/interactive whiteboard is preferable together with a separate whiteboard/flipchart which allows for interactive work with the group. Please inform me if you need this equipment provided.


DisneyToysReview the toy channel presents another collection video: Today we have a collection of Fast Lane Vehicles! This bright blue car carrier is great!
DisneyToysReview the toy channel presents another toy unboxing video: Fastlane Rescue Station! Today we are playing with the Fastlane Rescue Station!
Fastlane fire city playset - Shaan's toys talk.


Home Briefings COP 23: Do the Paris climate agreements have a future?
Without any additional policy to regulate greenhouse gas emissions, it is probable that the world will face a temperature rise of 3°C or more in the coming decades – with catastrophic effects for the environment and for mankind.
However, the 'Paris Agreements', an international accord to tackle climate change, were signed by 195 countries in December 2015 following the 22nd United Nations Framework Convention on Climate Change's (UNFCCC) Conference of Parties (COP). The proposals shall come into effect in the year 2020.
Last week, the latest edition of the summit, the COP 23, took place in Bonn, Germany. The small island nation of Fiji oversaw this year's proceedings, which were less political – and therefore less well publicised – than the previous edition.
The COP 23 climate summit was held in Bonn, Germany, from 6-17 November 2017. Photo credit: Wikipedia Commons.
The COP 23's main aim was to begin the process of outlining the Paris rulebook, a technical document that will be finalised in 2018. With the worst possible outcome thought to be "ending up with empty pages", the summit was considered a success: some of the content for the document was outlined and agreed upon.
Another notable step forwards was the inauguration of the Powering Past Coal Alliance, which now has the support of 27 countries, is committed to quickly diminishing the use of coal – the fossil fuel that creates the highest level of CO₂ emissions per unit of energy generated.
Also for the first time, the UNFCCC recognised the role of indigenous peoples and local communities in climate change mitigation, establishing concrete mechanisms and funding to support them.
A troubling prelude to the Bonn summit was the decision of the Donald Trump's administration to pull out of the Paris Agreements earlier this year. This made the US – the world's second largest polluter – the only country that is not part of the accords.
However, this did not play a fundamental role in last week's negotiations: some European countries – and even some individuals – committed to increase their monetary contribution to make up for the loss of the US' funds. Some, such as UN's chief climate negotiator Christiana Figueres, went so far as to thank President Trump for having "shored up the world's resolve on climate action".
The only event at the COP to involve the US featured an executive of Peabody, a US coal company known most widely for having funded campaigns denying climate change. Having been sent by the Trump administration to promote fossil fuels, the majority of audience sung protest songs and walked out of the auditorium chanting.
One of the more fundamental issues raised during the summit was the apparent lack of commitment from developed countries to cut emissions to levels that can help poorer nations cope with changes in their climate. Additionally, the lack of specifications on the financial resources to be contributed by rich nations was also widely criticised.
Finally, there is concern over the lack of a clear pledge to reduce the usage of coal by some fundamental actors, such as Australia, India and even the hosts, Germany.
The developments of the COP 23 offer some hope for the future of the Paris Agreements. However, as stated in an open letter published last week and signed by 15,000 scientists from around the world, the future remains far from certain; and the world still appears to be on the brink of climactic and environmental catastrophe.
Indeed, levels of CO₂ rose again in 2017, having remained stable for three years, casting doubts on the reality of the objective of staying within a "safe" level of temperature rise of 2°C.
All eyes are now on next year's COP to be held in Katowice, Poland – a country with large, strategically important coal reserves. Before then, negotiators, scientists and decision-makers will have to work together to outline and agree on the remaining content for the Paris rulebook.
In the words of Laurence Tubiana, France's climate ambassador: "There is no time to rest on our laurels, we are not on track. If we are serious about tackling climate change, everyone will need to step up and put forward ambitious climate commitments".
This, as ever, will not be easy – and a lack of firm pledges in next year's meeting could sound a death knell for the accord. According to Corinne le Quéré of the Global Carbon Project: "it could already be too late".


Thursday. Adept, p. 37. Knave or Not, p. 56. Fawcetd & M R dine: call on Fenwick & Hays: sup at miss G's, w. L Jones.
Thursday. Two Emilys, p. #564, fin: Donamar, Vol. III, p. 128. Call on M Hays n. Chandler calls n. Irish War.
Thursday. Ovid, Ep. XIX: Julie, p. 118: Cellini, p. 194. Dyson tout le jour: theatre, Spanish Barber: call fin mrs Fenwick, w. Dyson; adv. Hays: call on F Ht.
Wednesday. Ovid, Fasti, p. 8: Julie, p. 234. Call on Johnson: tea Char Smith's: meet M R, M Hays & Underwood: Chandler calls n.
Saturday. Elfrida. Call on Ht, M, M Hays, & Dignum n: tea C Smith's.


This property offers an amazing opportunity to secure a solid full brick home in a cul-de-sac location. Positioned on a large generous parcel of park like grounds free of large trees. Rarely will you find an original home in such amazing condition, this home has been in the same family since constructed and has been fastidiously maintained.
The location does not get any better as you will enjoy the short level walk to the West Pennant Hills Primary School, Thompsons Corner Shopping Village and bus services within minutes.
Easy walking distance to West Pennant Hills shops, primary school and Pennant Hills High School and just a skip to local and express city bus services, day care centres and parks. A short drive will take you to Westfield Hornsby, Castle Towers and Macquarie Shopping Centre with easy access to M1 and M2/M7 motorways and a selection of desirable private schools.


I'm kind of late to the Kanye game (minus a two week stint where MY BEAUTIFUL DARK TWISTED FANTASY was on repeat while I lived in Portland ME) but I'm starting to understand everything. As a music fan, I think that it takes me quite a while to understand and like an artist. I like to see a fuller discography before I dive into things. If an artist "has it", the first three albums they release are usually powerful no matter what. It's that trilogy that most artists are remembered for. I like to wait around and see what else the artist has to offer. In Kanye's case, his "2nd trilogy"of albums are the ones that do it for me (808s & Heartbreak, My Beautiful Dark Twisted Fantasy, Yeezus). What a stunning body of work. The songwriting and production on these albums could clinch it for me, but Kanye's artistry and PUSH to get all of us living in the modern world thinking and doing makes everything perfect with these albums. This is all happening to me at a good time as well…Kanye's new album The Life of Pablo, comes out soon.
I don't know what to call it so we'll use the term "modern electronic music" but whatever it is I LOVE IT. I love the broad strokes that modern electronic composers make with their music and soundscapes. When you listen to these pieces closely, you hear slight nuances and motifs that will blow your mind. You start to hear the sound within the sound. Don't call it noise. Don't dismiss this music. Open up your soul and let the beauty come in.
This is the best Bob Marley song! What a powerful message coupled with a great, simple musical groove. You can't help but hear this song and feel like approaching life with a positive vibration.


text:
» Auricular Acupuncture
The Validation Of Auricular Diagnosis
Last Updated on Tue, 01 Jan 2019 | Auricular Acupuncture
The term auricular diagnosis was first proposed officially by Terry Oleson in 1980.1 His study, conducted at the department of anesthesiology at the UCLA School of Medicine in Los Angeles, belongs to the history of ear acupuncture. Its aim was to evaluate the claims by French and Chinese acupuncturists that a somatotopic mapping of the body is represented upon the external ear. Forty patients were examined by a physician to determine which of 12 reported areas of their body suffered musculoskeletal pain (Fig. 9.1). Each patient was then covered with a sheet to conceal any visible physical problems. A second physician afterwards carried out a blind examination of the patient's auricles for areas of higher tenderness or reduced electrical skin resistance. The ear points corresponding to body areas where the subject reported musculoskeletal pain were designated as 'reactive points', while 'non-reactive points' corresponded to areas of the body where the patient experienced no discomfort.
The results of Oleson's study were as follows:
1. The correct identifications summed to 75.2%. In 12.9% of the total the points were false-positive and in 11.9% the points were false-negative; the association was highly significant with W2 (P<0.001). In 37 of the 40 subjects there were more correct identifications than incorrect, which was rated as significant by the sign test (P<0.01).
2. Both mean electrical conductivity and dermal tenderness at ear points related to specific areas
Fig. 9.1 The somatotopic mapping of musculoskeletal pain on the auricle according to Oleson (with permission of the author).
of the body where pain problems were present were significantly higher with t-test (P<0.01).
3. As regards the laterality for ear points relative to the side of a body problem, the mean electrical conductance was significantly higher if the problem was ipsilateral (P<0.01); the mean tenderness of ear points, in the case of unilateral problems, did not differ between the right and left ear.
4. There were no significant differences in either auricular conductance or auricular tenderness between recent and old pain problems. Recent pain problems were defined as having occurred within the 6 months prior to the study, old problems as having occurred more than 6 months previously.
5. It was observed in 15% of the subjects that there was a localized region of white, flaky scaling of the dermis on the auricular areas corresponding to the part of the body where musculoskeletal pain was present. Oleson wrote on this subject: 'although infrequently observed, abnormal morphological characteristics on the auricular surface were highly predictive of the presence of pathology in the corresponding area of the body'.
The interesting conclusions of the article by
Oleson and colleagues were that:
this study also indicated that the auricular diagnosis technique is often sensitive to pathological problems of which the patient is only minimally aware. When some patients were told of their auricular diagnosis results, they suddenly remembered having a minor or old pain problem in that bodily area, a problem which they had neglected to mention during the medical evaluation. Since these post-hoc results were derived after the ear diagnosis had been made, these instances were not included in any statistical analyses. Nonetheless, such observations do suggest that auricular diagnosis may be effectively employed as part of a general medical evaluation designed to reveal all organic aspects of a patient's pain complaint. Since there are also ear points for abdominal and thoracic bodily organs, auricular diagnosis could also be utilized with standard diagnostic procedures for analyzing pathological conditions related to internal pain or referred pain.1
Since then Oleson's research has become the major reference study and has been cited in several articles on ear acupuncture. A recent paper, however, re-examined the question of whether auricular maps were reliable for chronic musculoskeletal pain disorders.2 Fortunately the authors had no intention of replicating Oleson's study but only of proposing a different method for validating auricular diagnosis by using a 250 g algometer. The main shortcomings of this study were the limited number of patients examined (only 25), the lack of importance given to the posterior surface of the ear, which was not examined at all, and the adoption of an arbitrary somatotopic arrangement of the auricular zones which does not faithfully correspond either to the French or to the Chinese map. For example the knee was reproduced twice on two different areas roughly representing it, according to the schools just mentioned. It is not reported in the article which of the two the blind assessor had to consider as corresponding to a painful knee, or whether both corresponded. In contrast, in Oleson's study the 12 different auricular regions chosen for the research were the faithful somatoto-pic representation of the body according to the Chinese map.
In my opinion the concept of parallelism between a topographical area of the body and the corresponding somatotopic auricular area expressed by Oleson has to be considered innovative. Actually, in the diagnostic process we need to speak about areas, especially if we are learning, or teaching beginners to select the most effective points for treatment within each area.
Fig. 9.2 The representation of the homunculus according to Bossy (with permission of the author).
Bourdiol in particular introduced the concept of somatotopic area early, but the most interesting interpretation of the body's representation on the auricle is probably that of Jean Bossy,3 former director at the Montpellier Institute of Anatomy and author of several books and articles on the neurophysiological basis of acupuncture. His representation of the homunculus on the auricle4 is probably more realistic and useful for the practitioner than the well proportioned fetus which we see on the common drawings of the ear. As in the homunculus sensitivus and motorius of Penfield, the hand and the thumb have a large representation as well as the lips, the nose and the jaws (Fig. 9.2).
Starting from Oleson's historical paper I tried to create a project for validating auricular diagnosis which could be acceptable and reproducible.
Acupuncture For Cynics
Have You Always Been Curious About Acupuncture, But Were Never Quite Sure Where To Stick The Needles? If you associate acupuncture with needles, pain and weird alternative medicine then you are horribly misinformed about the benefits of the world's oldest form of medicinal treatment.
Stop Migraine Headaches Forever
End Back Pain Forever
Building Abdominal Muscles Training Guides
Trigeminal Neuralgia On The
Laser Auriculo Diagnostic
Allergic Conditions On The Auricle
Point Zero And The Principle Of Alignment According To Paul Nogier
The representation of the ovary on the ear
Vorlagen Ausdrucken Mandala Sternzeichen