Category Archives: podcast

Herding Code 216: Bash on Windows, Angular 2, Surface Book, Kindle Oasis, Windows Phone

Kevin, K Scott and Jon talk about Bash support in the new Windows Insider builds, their thoughts on Angular 2, K Scott’s new Surface Book, some general apathy on Kindles, and whether Windows Phone is alive, dead, or undead.

Download / Listen: Herding Code 216: Bash on Windows, Angular 2, Surface Book, Kindle Oasis, Windows Phone

Show Notes:

    • Bash on Windows and Windows Insider stuff
      • (00:44) Jon mentions the Bash on Windows announcement at Build and asks if Kevin or K Scott have played with it. This devolves into a discussion of Windows Insider previews. Jon likes it and talks about the steps for enabling Windows Insider preview builds. K Scott has been scared to try it, but it sounds like he’s convinced. Kevin is put off by the Insider term – Windows Insider, Visual Studio Code Insider previews, etc. K Scott adds “Windows Insider” it to his e-mail signature.
      • (05:15) Jon talks about the steps for enabling Bash on Windows. or Windows Subsystem for Linux (Beta), to use the official terminology.
      • (07:08) Feel the excitement of listening to someone type commands into a console window as Kevin asks questions about what’s installed and Jon tries to apt-get it all. K Scott and Kevin wonder about how things like filesystem and processes work, and Jon tries to make up answers.
      • (09:50) Kevin says it feels like an admission of defeat to add *nix support to Windows. Jon says it feels practical to him – developers are building for multiple operating systems (especially including mobile), so it’s nice to have it supported.
      • (11:19) Kevin’s ready for Cygwin to die in a fire, and Jon’s excited about ssh working less horribly on Windows. Kevin says the race is on to get Wine working on Bash on Windows.
    • Angular 2 and React
      • (12:55) Jon worked on a hands on lab for Build that had master-details using Angular 2 and ASP.NET Core. He said Angular 2 seemed a lot simpler than Angular 1 now. K Scott said the component model is simpler, but he’s seeing some resistance to the ECMAScript / TypeScript updates, new binding syntax, etc. The Angular 1.5 release also includes a component model that’s a much easier programming model. It almost feels like some older Microsoft component-based programming frameworks going back to Visual Basic 6: you’re working with components that have simple properties and events. The guys speculate on how soon someone will build the big visual editor for Angular 2.
      • (16:21) Kevin says TypeScript seems like a barrier. K Scott says it’s not strictly required. He rejected TypeScript for a while, but when he was working with Angular 2 and tools and editors supported it he decided he liked it. Jon and K Scott talk about how a lot of things that throw people off about TypeScript are really just modern JavaScript syntax.
      • (18:50) The guys discuss how Angular 2 and React mindshare will play out. Jon likes React as long as he never views source. Jon thinks the unidirectional flow is really simple, and Kevin agrees – after years of lower level Backbone, the simpler flow in React saves some mental energy.
      • (20:29) Jon mentions that React Native recently came to Windows, too.
    • Devices: Surface Book, Kindle and big batteries
      • (20:56) K Scott got a new Surface Book (after waiting to make sure nothing new was coming out at Build). He says it’s the best piece of PC hardware he’s bought in years – the build quality is good, the keyboard is good, he gives the trackpad of 9 out of 10. He says that the detachable tablet is a bit large as a tablet, so he’s using an older Surface for reading.
      • (23:58) Jon jokes that K Scott’s not likely to buy a Kindle and says he gradually stopped using his Kindle when he moved to Audiobooks, and kind of associates reading with work now. Kevin says that’s sad. They talk about Kindles for kids’ books.
      • (27:07) Kevin says the two big things he picked up for the new Kindle are physical page buttons and a three month battery. He says the main thing he likes about Kindle for both him and his kids (as opposed to a tablet) is that it forces you to read instead of getting distracted. The guys decide that tripling the life of an already one month battery isn’t a huge win.
      • (29:20) Jon says he recently bought a portable battery that can recharge his laptop, which is handy for long flights. (note: he said it was iPad size, it’s a lot smaller but is 1.2 pounds)
      • (31:15) Jon asks Kevin about new Apple hardware. Kevin says the iPad Pro screen is apparently astounding – he’s expecting them to be amazing in a few generations. Same for Apple Watch – he doesn’t have one yet, he’s waiting for version two. Jon says the improvement from Microsoft Band 1 to Band 2 was pretty nice, especially in the industrial design.
    • Lightning Round: Will Windows Phone be dead in one year?
      • (33:40) K Scott asks if Windows Phone will be dead in a year. Jon hopes not, as he just bought a Lumia 950 XL. He’d had a budget Blu Windows Phone since September, and the Windows 10 Insider builds were nice, but the camera wasn’t very good. He really likes Windows 10 as a phone operating system and thinks it’s sad that so few people will actually see it.
      • (35:55) K Scott got a Lumia 950 XL in January (when he dropped something on his previous phone). He got the docking station, too, and said it worked surprisingly well. The guys discuss how useful docking a phone is; Jon postulates that it could be useful for someone who does everything on their phone and occasionally needs to write a long email or edit their resume – especially if it can be hooked up to a TV.
      • (38:30) Kevin says that Windows Phone isn’t dead. it’s undead. It will linger on in a zombie-like state indefinitely.
    • Scott Koon sends us out with a request for further information by e-mail.


Herding Code 215: Jon McCoy on .NET Security and Defensive Patterns

At NDC Oslo, Jon talked to Jon McCoy about .NET security and defensive patterns for building enterprise applications.

Download / Listen: Herding Code 215: Jon McCoy on .NET Security and Defensive Patterns

Show Notes:

    • Security Patterns
      • (0:15) Jon Galloway (henceforth in this post JG) mentions the last time Jon McCoy was on the show and asks him about his talks this time around. This time, he and Topher Timzen did a hands on attack class followed by talks on defensive patterns for enterprise applications (video: Hacking .NET(C#) Application: Building and Breaking Layered Defense).
      • (00:54) JG asks Jon if he showed off any scary hacks. Jon describes an attack in which they made an executable editable both on disk and in memory, then edited both the IL and assembly code to do things like inject direct database attacks (bypassing . He describes how that could be defended using enterprise defensible architecture by talking to databases through services which can implement security layers. The goal is to prevent an attack at one layer from moving through the rest of the enterprise.
      • (1:59) JG says that often hears that major hacks occur by web application attacks that are then escalated to database attacks, often through password reuse. Jon says that’s true, since web applications are often deployed to the same server as a database or authentication server. He recommends using a service that’s locked to a single port, with security unit tests.
      • (2:43) JG asks which patterns he’s describing are unique to .NET development. Jon says that he’s emphasizing patterns that are easy on .NET – for example,  REST services are easy to implement on .NET as compared to C++. He’s advocating architectural changes that are relatively easy to implement in .NET applications provided you start with them early on (rather than trying to retrofit security later).
    • A specific example: Protecting a medical record
      • (3:33) JG asks for some specific examples. Jon says they talked about security unit tests and user stories and gives and example from his talk about a medical record that’s being sent through an enterprise securely. To do that, you’d need to encrypt it on an edge node, so the web server and database don’t have decrypted data or decryption keys. Instead, you use a key server on a segmented network. Because of this, at no point could a sysadmin have gotten access to the record because it was encrypted at all steps.
    • "Above Admin"
      • (4:49) JG points out that Jon is talking about preventing access to sensitive data by sysadmins. Jon says that you should consider your attackers to have more power than a sysadmin – they refer to attacker privileges as "above admin" because they’ve taken over your AD infrastructure, passwords on routers, dropping new firmware, etc.
      • (5:50) JG refers to James Mickens’ keynote from the previous night (Herding Code interview here) and asks if there’s any hope. Jon says you need to plan, you need to minimize pivot points to prevent an attacker from moving between servers. He discusses potentially using static HTML that calls into secured REST services rather than web applications with direct database access, because building security around a REST service is much easier than securing a web application and web server.
    • Mobile and desktop application security
      • (9:03) JG asks about mobile application security, since he frequently hears about mobile apps that are supported by unsecured (or very poorly secured) backend services. Jon refers to Amazon and Twitter as examples of companies with published patterns for secured backend services.
      • (9:52) JG asks if for some tips on how different systems on the network should be secured, referring to desktop applications. Jon says that each system should defend itself from the other systems, so in this case the other systems should assume that the desktops could be compromised, the desktop applications should assumed the database can be compromised, there needs to be thought about defending the outgoing APIs, etc. There needs to be a plan for how to take things down and respond.
    • What do you wish you’d done?
      • (10:35) As a thought exercise, assume that your database or web server has been compromised: what do you wish you’d have done? Do that for different pieces of your application architecture. Jon says that you can make it a fun exercise, pit dev teams against each other, etc. Security should be fun and easy if you’re doing it right.
    • Wave 3D: A 3D operating system front end
      • (12:07) JG asks Jon about the 3D operating system he’d mentioned before the call. Jon describes Wave 3D, a cross platform front-end to multiple operating systems (Windows, Mac, Linux, Android) that gives the same exact experience for all backend systems. It can be connected to Amazon, Google and Dropbox document storage.
      • (12:56) Jon says it’s running on Mono and Unity and says it compares pretty well with 3D operating systems in the movies, and they’re looking at launching it via Kickstarter. It provides a simple, install-free environment with a document viewer, movie player and more on every platform instantly.

Note: This is our last podcast from NDC 2015.

Herding Code 214: Todd Gardner on Tracking JavaScript Errors with {Track:js}

At NDC Oslo, Jon talked to Todd Gardner about {Track:js} and some of the difficulties in diagnosing JavaScript errors.

Download / Listen: Herding Code 214: Todd Gardner on Tracking JavaScript Errors with {Track:js}

Show Notes:

    • What’s TrackJS?
      • (0:20) Jon asks Todd to explain TrackJS. Todd said it’s something he built to help with difficult JavaScript debugging issues a few years ago. JavaScript applications were difficult to debug because it was hard to define the different failure states of his applications. Over time, they worked to add in diagnostic state (e.g. shopping, checkout, etc.). Over time, they added in network state and user state. Over time they came up with telemetry, which defines states and state changes, which can be a lot more helpful than a stacktrace in diagnosing and fixing an error.
    • Why context is more important than stack traces
      • (2:34) Jon agrees, saying that it’s really frustrating to try to reproduce an error as a developer, and context is really important. Todd says that stack traces are limited because applications are so asynchronous in nature now – an error may be from a timeout which was a response to an Ajax event which was a response to a user click.
      • (3:44) Todd says they also track a lot of general information like browser, operating system, and things like date and time information. He once spent a really long time on an error one user was experiencing on a calendaring application because they were stuck in the ’70’s (literally).
    • How TrackJS gathers and exposes data
      • (4:34) Jon asks how developers integrate TrackJS into their applications. Todd says it’s a simple JavaScript include.
      • (4:56) Jon ask more about how he gets access to the reported information when he’s troubleshooting an error. Todd says there are three problems to solve.
        • The first problem to solve is alerting: you get daily rollups on top errors and trends.
        • Second, when you log in, you need to see which errors are which important (filtering out background noise like unsupported useragents, strange Chrome extensions that modify the DOM, etc.). You need to know which errors impact the most people, which cause users to leave, and which are top browser-specific errors.
        • Third, you need to need to be able to dig into and diagnose a specific error.
      • (6:45) Jon asks more about how he’d diagnose a specific error. Todd describes the contextual information TrackJS provides for an error (including things like browser, screen size, user information). For example, one issue they diagnosed recently only occurred at a specific screen size due to a responsive design which modified the page so certain elements were only displayed in a range of screen widths.
    • Common problem: Partial Load Failure
      • (8:14) Jon asks Todd what running the service has shown him are common problems that developers aren’t considering in building JavaScript apps. Todd says it’s partial loading failure – cases where most of the JavaScript assets on a page load, but just one fails. In one instance, they saw everything on a page but the Stripe library load, which caused payment data to be insecurely posted.
      • (10:35) Jon asks about the best way to test for and handle partial load failures.
    • Common problem: Same Origin Policy
      • (11:36) Todd explains same origin policy restrictions in loading loading libraries from other domains, and using cross-origin headers to handle that.
    • Business model and subscription overview
      • (12:30) Jon asks about the business model for TrackJS. Todd explains that they offer free service to charitable and open source projects. For paid accounts, they bill based on page views rather than error count because he feels billing based on errors creates counter-incentives for users.

Herding Code 213: Sean Trelford on Composing 3D Objects with F# and OpenGL

At NDC Oslo, Sean Trelford did a lightning talk on composing 3D objects using F# and OpenGL. Oh, and he’s 8 years old. Sean (and his dad, Phil) talk to Jon about learning coding with Small Basic and F#, and how it’s fun to learn coding by building video games.

Download / Listen: Herding Code 213: Sean Trelford on Composing 3D Objects with F# and OpenGL

Show Notes:

    • Hello
    • Sean’s Talk
      • (1:13) Jon asks Sean whether he showed slides or did live coding.
      • (1:39) Sean made an army from one 3D man model.
      • (2:09) Jon asks how difficult it is to call OpenGL from F#. Sean’s dad, Phil, explains how Sean used a domain specific language – about 50 lines of code. You can use it to create shapes like cubes and spheres, color them, transform them, etc.
      • (3:30) Phil explains how Sean used the F# REPL to create and modify 3D objects interactively, then used functional composition to put the parts (head, arms, legs) together to build the army man, the used functional composition and aggregation to create the army.
    • Learning Small Basic and F#
      • (4:37) Jon asks Sean if F# is his first computer language; Sean says he started with Small Basic. Jon asks if he found it difficult to move from Small Basic to F#, Sean and Phil explain how F# is actually a pretty natural step from Small Basic. Small Basic has no functions with parameters, so when they had a project that ran into that limitation they just moved the code from Small Basic to F# and used the Small Basic library to construct 2D shapes (leveraging WPF).
    • Fun Basic
      • (7:02) Phil said that last year he and Sean rewrote Small Basic as Fun Basic (available free in the Windows Store). It’s an IDE with IntelliSense, code completion, etc. It’s got backward compatibility with Small Basic, but includes function with arguments, pattern matching, etc.
    • Learning programming with video games
      • (8:02) Jon asks about what next for Sean. Recently they went to a game jam and made a platform game. Phil says the REPL environment is huge for game building.
      • (9:04) Jon mentions the IoT lab at NDC and asks Sean if he’s done anything with IoT; Sean says no. Jon says it seems like people try to get kids interested in coding with IoT, but maybe games are more fun to get started. Phil says that Sean’s got a Minecraft channel on YouTube. Jon asks Sean about making videos about making games.
      • (10:38) Phil says he got started on computers with games – he made his first game when he was 11, but his first commercial game was when he was 14 – Flint Eastwood.
      • (11:44) Jon asks Sean if this is his first time in Olso, and his first conference. It’s his first time in Oslo, and his first "speaking" oriented conference.
      • 11:28 Jon asks if they’ve got any last messages, maybe to encourage kids to get started with coding. Phil recommends the Hour of Code, as well as other resources online. Phil says his older son got into programming by adding levels to games, then writing scripts for AI’s, etc. Phil says that’s how he got started – looking at other peoples’ code and going from there. Don’t necessarily get hung up on fancy coding concepts, just script something and have fun!

Herding Code 212: Steve Sanderson on Web Development in 2020

While at NDC Oslo, Jon talked Steve Sanderson about Web Development in 2020 – future JavaScript features, adventurous optimizations, and constraint-based styling.

This week we’ve also got a full transcript (thanks to Damian Guard!).

Download / Listen: Herding Code 212: Steve Sanderson on Web Development in 2020

Show Notes:

    • Hello
    • ES 2015 & 2016
      • (0:52) Jon asks if ES 2015 and 2016 is the new name for ES 6 and 7
      • Steve explains how the standard body are going with yearly updates
      • (1:25) Jon asks what some of the new features are
      • Steve talks about how it looks so different and how the import and class features help
    • Polyfils & transpilers
      • (2:14) Jon asks if he can use those features today
      • Steve explains the polyfills and transpiler options
      • (2:46) Steve talks about the Babel transpiler open source project and why people should write ES 2015 code today
    • What about Typescript?
      • (3:19) Jon asks if Typescript is still an option
      • Steve explains how Typescript is a transpiler and provides some similar features as well as strong typing
    • Web Components
      • (4:05) Steve talks about web components, how they’re not implemented in browsers today and the polymer.js project that can bridge that gap
      • Steve talks about scoping, the Shadow DOM and how components are encapsulated from the rest of the page
    • Async & await
      • (06:04) Steve talks about his interest in the upcoming async/await support and how it goes further than promises in order to clarify the flow of success and errors
      • Steve mentions that Babel can polyfill async/await support today
    • Generators
      • (7:30) Jon asks for an explanation of generators
      • Steve compares generators with the yield function of C# and explains how the function is marked with an asterisk to signal it is a generator
      • (8:08) Jon asks if this is the end of promises
      • Steve explains that generators are built on top of promises and how they can chain waiting for multiple ones sequentially
    • Emscripten
      • (8:53) Jon asks about Emscripten
      • Steve talks about the Emscripten bytecode format and how it can make Javascript faster as well as providing the foundation for new web languages
      • Steve talks about the LLVM bytecode converter and how it only really works with languages like C and C++ that don’t have a runtime like Swift, Rust, Go etc.
      • (12:06) Jon asks about the demo compiling SQLite
      • Seve talks about why SQLite works when others don’t.
    • Shared Array Buffer
      • (12:48) Jon asks about the Shared Array Buffer
      • Steve talks about how Javascript took an isolated approach to parallelism and how Shared Array Buffer allows the breaking of this boundary to enable some high-performance parallelism
      • (14:05) Jon mentions how the ASP.NET 5 team are doing similar things for performance
    • Grid Style Sheets
      • (15:00) Jon asks about Grid Style Sheets
      • Steve points out the "Grid" in Grid Style Sheets refers to the company behind it and not the approach which is a rule, constraint and solver layout system like Auto Layout in iOS
      • (17:14) Jon points out it’s Javascript and so people can use it today
      • Steve talks about where it might go and explains how variables are much different to typical variables
      • (18:34) Jon asks about the animations in the demo and Steve reveals it’s a CSS transition
      • Jon and Steve discuss how GSS and CSS might not mix well together
      • Steve warns GSS is really cutting-edge
      • Jon asks about debugging constraint rules and Steve agrees this is a challenge right now
    • Goodbye
      • (20:30) Jon says goodbye as Steve heads off for his plane.




Jon: Hello and welcome to Herding Code. I am sitting here at NDC speaking with Steven Sanderson or Steve Sanderson, sor ry.

Steve: Either’s fine with me.

Jon: Either’s fine, great. I caught the tail end of your talk yesterday. It was fascinating, you were talking about future Javascript features or browsers features.

Steve: That is right – I was trying to predict the future of client-side web application development. I don’t know how accurate my predictions will be but some of them are fairly safe bets like we’re going to start using ES 2015/2016 stuff pretty soon and then there’s a whole raft of other features coming towards us.


Jon: Ok. So that was actually the first time I’ve seen ES 2015 and 2016. I think I’ve heard in the past ES 6 and 7.

Steve: Yeah, it’s just a bit of new marketing really. The folks behind the standards there have basically committed to bringing out a new update every year. So we’ve got this annual cycle rather than up until know it’s been every five years or every ten years in one case. So given that it’s going to be annual it it sort of makes sense to give the name a year.

Jon: Right, yeah, definitely. Kind of like Visual Studio has done.

Steve: Exactly.


Jon: So what are some great features there in 2015/2016?

Steve: Yeah OK so ES 2015 was previously known as ES 6 has got to be the biggest set of changes that have come in Javascript since it was first introduced. If you look at something that’s written with ES 2015 syntax – if you’ve never seen that syntax before you would probably not even guess it was Javascript. It looks really different. So you’ve got import statements – which give you a clean alternative to having loads of script tags. You’ve got actual classes which are the same at runtime as regular Javascript prototypical inheritance but gives you a nice syntax for declaring that you can remember.

Jon: We’re finally taking advantage – class has been a reserved word in Javascript forever, right?

Steve: Oh, yeah, I think that might have been the case.


Jon: Can I start using those features? I know there’s some poly-fills and transpilers or whatever.

Steve: Yeah, I’d say if you want to start using ES 2015 today it’s really not as difficult as you might think. Assuming you want to target all browsers since, let’s say IE 9, then you can basically use almost all of the ES 2015 features. You just need to use a transpiler.

The one that everybody seems to be most into at the moment is called Babel (BAY-bel) or some people call it Babel (BAB-bel). I don’t know what the right pronunciation is.

Anyway it’s an open source project that will take your ES 2015 code and produce an ES 5 equivalent of it. It’s really fast, easy-to-setup and to be honest with you I can’t think of any good reason not to be doing that. If you’re not doing that you’re sort of just keeping yourself in the past really because this thing is a fully ratified standard now. We know this thing is definitely landing – all the browser makers are committed to bring this in. There isn’t really a good reason to not be using this today.


Jon: I’ve looked at using Typescript for that kind of class support in the past. Is there any kind of downside to continuing with that or are they similar?

Steve: No there’s certainly no downside to that. If you’re getting benefit out of Typescript then absolutely use it. Typescript in a way is a transpiler because it is taking some syntax that is a lot like ES 2015 – it just adds some additional features on top of that to do with strong typing. So if you’re getting some benefit out of that strong typing then yeah definitely use Typescript. On the other hand if you don’t want to use the strong typing then you’ll find that something like Babel will do the compilation, like an order of magnitude, faster.


Jon: So that’s kind of a no-brainer as far as a future to dig into. What else did you talk about that’s more forward looking?

Steve: I was also looking at web components which is sort of all tied up with ES 2015. It’s kind of a part of this package of things arriving at the moment but unlike that making that work across all browsers is not quite as guaranteed today. So the best known polyfill for web components is polymer.js but in terms of IE that’s only IE 11 onwards. But it’s a really good feature. Web components is a way of combining together a bunch of scripts and markup and styles to make a reusable package of UI features that you can put in your application and you can assign them to a custom element name so you can have something like sales-chart as an element and when that goes into your application your custom sales chart appears and it has all the behaviors your want. And it can be, to some extend, encapsulated from the rest of your page as well. So this is a feature called Shadow DOM and it’s a way of telling the browser that a certain element should be abstracted away as far the page that contains it is concerned. Code running outside it won’t see the elements inside. If, for example, you were using jQuery and you were using a selector and it happened to match something inside that component it won’t actually match it because it’s considered to be like a separate document. So you don’t get accidental leakages of behavior into your component or out of it – it just makes reuse easier.

Jon: And the same for stylesheets as well?

Steve: Yeah, that’s right. If you bring a stylesheet into your web component and it’s certainly going to apply inside that Shadow DOM root it won’t apply outside it.


Jon: And I believe you mentioned polymer.js is the polyfill for that?

Steve: Yeah, it’s the best known polyfill but Polymer is only the way of doing something like web components. If you’re going to use something like React or Knockout or Angular any of those kinds of things they’ve all got their own kind of concept of reusable components with custom elements so if you’re using any of those things you probably can pretty much do this anyway in a fairly cross-browser way.


Jon: Right. Ok. So then what other features did you cover?

Steve: I was interested in the upcoming await/async support. 

Jon: That’s always been kind of a challenge in Javascript.

Steve: It so is isn’t it. Yeah. So Javascript for the long time was plagued by this everyone’s got a slightly different way of doing callbacks thing which is quite troublesome and then it all got formalized around promises. Promises is a fantastically elegant concept that gives you a really clear way of working with callbacks and chaining them and combining them and so on. So promises are brilliant and they’re now a native browser feature but there’s still a lot of opportunity to get confused with promises because there’s so many way you can chain them together and not necessarily even understand how success and error values are flowing through that chain that you can still get things wrong by mistake. I find this happens all the time in my work. Not me, of course, but other programmers get very confused.

Jon: Right.


Steve: I might do sometimes. Whereas as any C# programmer knows with await and async keywords you can write your code as if it was synchronous.

Jon: It’s so obvious what’s going to happen.

Steve: You can’t get that wrong really. That’s part of the ES 2016 proposal and if you want to do that today you can either use Babel which will transpile async/await just directly or you can use the generators feature which is in ES 2015. Slightly different syntax but it gives you the ability to do something almost exactly the same.


Jon: Can you explain generators a bit?

Steve: A generator for a C# programmer is exactly like the yield keyword that came in with C# 2. So you can have a function that returns an infinite number of values. Like every time that you ask it for the next value it will give you the next thing and it will never stop doing that. That’s yield in C# and generators in ES 2015 do the same thing. So you can have a function and you put a little asterisk after the keyword function to say that it’s a generator and then inside there you can have yield, return, whatever. You can do that inside a while(true) loop or something like that and then the thing that calls it will receive each of these values. 


Jon: Do I just throw away promises now?

Steve: No, you still need to use promises. The way you can use this to make promises feel synchronous is by having some other that invokes your generator that gets back the sequence of values. Each time it gets back a value it will say "well what kind of thing is this? If it’s a promise then I’m going wait for that promise to complete before I ask you for the next value." And so, if you are yielding a series of promises in effect it’s like your promises are being called sequentially one after the other. Which is why your code ends up looking synchronous. It’s not very easy to understand verbally but when you see it written down it’s quite straight-forward and nice.


Jon: So then there was Emscripten?

Steve: Yeah, that’s right. So just yesterday or the day before depending on timezones there was an announcement from Brendan Eich that there’s going to be a new bytecode format coming to the web. So instead of Javascript just being expressed in plain text as it always has been it will be possible to describe your code in a binary format. The idea with that really is just to take all of the good work that’s been done with Emscripten which compiles native code to Javascript and Asm.js which is a special subset of Javascript that can be optimized very well and say "Okay, we don’t need to write out Asm.js as legal Javascript any more we can just write it out as binary code and that saves the browser a lot of work in terms of parsing." Asm.js is very fast at runtime but it still imposes a high parsing cost on the browser and that’s particularly noticeable on mobiles where people complain that say a large game might take multiple seconds to start during which the browser CPU is just 100% parsing so it would be nice to eliminate that cost altogether. Also, you get smaller use of network traffic because it’s very compact and also even though the semantics of web assembly are the same as asm.js initially they are open to adding additional web assembly only features in the future. So it might be possible to have new types of parallelism for example that’s only possible in web assembly. If they decide that it would be inappropriate to have it in Javascript it might still be appropriate for there to be a low-level feature that other languages can compile down to.

Jon: Ok.


Steve: So yeah, that’s all about performance really. And you can kind of do it today you know. We’ve got Emscripten today, you can compile pretty much arbitrary C code. You can get your asm.js – it will be very very fast in Firefox – the only browser that supports it today but other browser makers have committed to implementing that to. I know IE certainly has, I don’t know about all of them. I’m pretty sure they don’t really have a lot of choice these days.


Jon: Yeah.

Steve: That’s useful for a lot of things but one thing that you can’t really do very well with that today, but it’s kind of promised in the future, is compile some other language, that’s not C or C++, into Javascript. So theoretically you could do it because Emscripten takes LLVM bytecode and turns that into Javascript. So in theory anything that compiles to LLVM bytecode can be translated into Javascript but in practice it’s much more complicated than that. So if you take a Swift application for instance, and that uses the whole LLVM toolchain, it will produce LLVM bytecode and you might be able to get Emscripten to produce Javascript but it’s not going to run because you don’t have the Swift runtime there in Javascript. And it’s the same with Go and Rust and so-on and in certain cases people have managed to get little bits of experimental code working but really it’s not a realistic option today but in the future it’s quite likely with web assembly that they’ll be a strong reason for the makers of these other compilers to want to support web assembly.


Jon: Ok. I believe you had tons of great demos during your talk – this was one where you said it basically very difficult to get a demo working for it. Was it that one?

Steve: I gave a demo of compiling SQLLite – the embedded database – down into Javascript which is absolutely trivial. It works flawlessly and you need to do nothing clever at all. But SQLite is just written with C so it’s kind of the best case – a very easy thing to get working. The thing I struggled with was – yeah I did try and compile some Swift and some Go and some Rust and none of them would work. I checked all the mailing lists and nobody else can do it either.


Jon: Okay. Wow. So next there was shared array buffer.

Steve: Yeah. Shared array buffer. So one of the limitations that Emscripten faces today is that it can only use the features that are available to Javascript. Obviously. Because it’s running on a Javascript virtual machine. And that means that there are certain types of parallelism that you can’t do because Javascript has always worked hard to be single threaded. Now we’ve got web workers with Javascript but they are deliberately limited. With the web worker each of your workers is only allowed to access it’s own private memory space and when you wan’t to communicate between your application and those workers you have to post these serialized messages to say what you want them to do and they post a message back saying what they did. And that’s cool but they can’t really approximate the performance of native code that will spin up multiple threads that all just mutate the same memory simultaneously without any complicated message passing. So shared array buffer provides a way to pass a reference to a block of memory where you’re effectively saying "I opt in to having no control over timings here. I accept the fact that anybody can mutate my memory at any time with no guarantees." And when you opt into that for your shared array buffer then you can get much higher performance in certain cases.


Jon: It’s interesting we were talking to Damian Edwards yesterday about some of the server work that they’re doing optimizing serving ASP.NET 5 and that was something they ran into on the server side was this kind of shared buffer and passing and minimizing the transitions and all that kind of stuff.

Steve: It’s funny isn’t it. On one side of the industry we’ve got the move towards functional programming and no shared state and at the other end you’ve got this need for exploiting all the core of many core processors with as little amount of overhead as possible where you do need to mutate shared state. So we’re kind of straddling these two competing goals there and for certain applications like, for example, high performance games or something like that the shared state parallelism is clearly winning and other things like certain types of business applications functional programming seems to deliver much higher benefits than that.


Jon: Okay. I remember one of the other ones that I was actually really excited about because I’d looked at before and meant to play with and hadn’t yet was Grid Style Sheets.

Steve: Oh yeah, yeah. So that’s funny. The first thing to know about Grid Style Sheets is that it’s got nothing whatsoever to do with grids. It’s a company called TheGrid which, you know, is a cool name for a company but it’s a little confusing when you make a product called Grid Style Sheets. Anyway the idea with Grid Style Sheets is to kind of break free from all the layout limitations of regular CSS. Any web developer in the world has struggled with making things get vertically centered or shrink-wrapping to their content. You know, that kind of thing. It’s embarrassingly difficult for us, even when we consult on some of the hardest problems in the world, we can’t make something centered inside something else.


Jon: And it’s funny because you feel like I can describe the problem. I want this to be here and this to always be here but never bigger than the parent. Or whatever, right?

Steve: And that’s exactly what Grid Style Sheets does. It’s an example of a constraints-based layout engine and with a constraints layout engine you don’t necessarily care so much about hierarchy and padding and things like that you just make a rule that says something like "My popup menu needs to be left aligned with some other element and it needs to be vertically centered in a certain area and it needs to be big enough for it’s content" – that kind of thing. So it’s just a few constraints you give and then the constraints solver will choose the appropriate position for it. And it’s the same technique that’s used in some modern iOS applications. They’ve got a technology called Auto Layout and that allows iOS to have things like – you’ll see they’ve announced the Windows 8 style sidebar thing in iOS 9 I think. Well don’t Apple a good original idea that one. And the way applications can fit into arbitrary sized screens is by using technologies like Auto Layout where the developer just specifies a set of constraints and the operating system positions things. And Grid Style Sheets allows you to do precisely the same thing but on the web. It’s a cool, very cool technology. It’s a bit experimental at this stage, I don’t know of too many people really using it.

Jon: And it’s just Javascript right? So I mean I can start using it today?

Steve: Absolutely. I think that the people building that would aspire to it one day maybe even being a native feature. So you have your style type equals text/gss instead of css and then you have this alternate syntax for defining layout. Which is a heck of a lot more expressive and straight forward than regular CSS in certain cases. It’s also got some really cool powerful features that have got no equivalent in CSS. For example, well a simple example is that it has variables. Now of course if you’re using SASS or LESS you know about variables but these are cool variables. They don’t just have a specific value they have a value where you can define some rules. Like you can say this variable is positive, this variable is less than 250 but you don’t say what actual value it is. The constraints optimizer will choose the value in order to satisfy all the other constraints. Also, it supports if/else conditions so you can say something like "if this element is bigger than a certain size then I want this layout otherwise some other layout which is like media queries but, you know media queries are limited to querying just the window width or some other basic thing like that. Whereas with GSS you can query absolutely arbitrary things and it’s evaluated at run-time so if you mutate the DOM over time then it will update its layout accordingly.


Jon: One really nice feature I liked about it too is that it animated between. And so, I watched as you resized the window and not only would it apply the constraints but it would like really nicely smoothly move to it.

Steve: Yeah, so that’s not actually a natively GSS feature. I just put a CSS transition rule in. So like transition * 1 second or something.

Jon: Smart, I like that!

Steve: So in an application when everything to just instantly snap to the correct position you wouldn’t have that rule but it’s quite sweet as you say to see things so of fluidly slide into their correct position. Which is dead easy because GSS internally is using position: absolute or something for everything so all your animations just work.

Jon: Now, because of things like that it might be difficult to use some GSS and some traditional CSS together.

Steve: Yeah, I’m sure that’s probably true. Yeah. I think there’s a lot of reasons why if you are adopting this you should expect to be in for a slightly bumpy ride. You will definitely be one of the first adopters in the world if you pick this up today. You’ll be the one that’s actually figuring out what the best practices are, what stuff does and doesn’t work that well so yeah I wasn’t standing up there trying to advocate that everyone should take this on today but if you’ve got an interesting little side project and you want to try out some really cutting-edge possible future thing then yeah it’s a really fun thing to play with.


Jon: And one thing too I was all excited about it and kind of sold on it and you explained too that it can be difficult to debug. If something’s not working it’s like actually solving a constraint and you don’t get that clear understanding of what I did wrong.

Steve: I could imagine some future tooling that shows you visually how things have been anchored and laid out. But at the moment it’s a bit like if you give it not quite enough information it will just make some decision that might completely bizare like it chooses to position an element off the screen or something like that and it may not be obvious until you really think very carefully why it’s done that.


Jon: Great, well this is fascinating. I’m looking forward to watching the video again and digging into some of this stuff. I understand you’ve got to run off and catch a plane.

Steve: Yes, that is true.

Jon: So thank-you very much for your time and was great talking to you.

Steve: Cheers.

Herding Code 211: James Mickens on The State of Computer Security and Bitcoin and Thomas Jefferson and Internet of Terrible Things and Prawns and Oslo’s Terrible Secret

While at NDC, Jon talks to James Mickens about his terrifying computer security keynote presentation.

TLDR you are doomed.

Download / Listen: Herding Code 211: James Mickens on The State of Computer Security and Bitcoin and Thomas Jefferson and Internet of Terrible Things and Prawns Oslo’s Terrible Secret

Show Notes:

  • Hello
    • (00:24) All is lost. Listen to Danzig.
  • Stop putting your money in Bitcoin
    • (01:00) James says it’s not a good place to put all your money unless you want to be poor.
    • (01:42) Bitcoin is a commodity, not a currency. Investing in commodities is hard. It’s not a stable place to put money. When it’s going up, the smart people are taking money out.
  • The legal system – and specifically Thomas Jefferson – won’t help you
    • (03:56) Judges and lawyers are very far removed from modern technology. Analogies to older forms of communications doesn’t work.
    • (04:44) Emojis are not telegrams. They’re incredibly terrible, though.
    • (06:30) Thomas Jefferson wouldn’t help with issues relating to iPhones. If your phone broke, would you take it to a really old person for help? Because Thomas Jefferson is a really, really old person.
  • The Internet of Terror
    • (08:10) The internet of things is the new cool buzzword, but nobody wants to reboot their house.
    • (09:17) The security story for the internet of things world is cartoonish. When your refrigerator starts sending spam, James will laugh at you.
    • (11:52) The first several generations of IoT houses will be terrible. Things will get better on a relative scale, but will always be terrible on an absolute scale.
  • Node.js
    • (13:32) James knows he’s in danger for dissing Node.js, but he can’t help himself.
    • (15:08) We’ll see the rise of the JavaScript Full Stack Developer, which could be powerful, but it’s also what Sauron wants.
  • Oslo
    • (16:10) Oslo is a wonderful city. It never gets dark, which makes you feel safe but if James was a criminal he would be all over the extended working hours.
    • (16:54) Shrimps are prawns, and unlike American shrimp they have legs and heads.
    • (18:06) French fries cost approximately one mortgage payment.
    • (19:42) James speculates on whether Oslo harbors some terrible secret. The condos look like lairs for James Bond villains.
    • (21:11) Jon saw a building with a big sign that said Edderkoppen, which he had recently learned means The Spider. Perhaps that is Oslo’s terrible secret?

Show Links: