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: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
(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.
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.
(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).
(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!
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.
Jon: So what are some great features there in 2015/2016?
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.
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.
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: 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?
Jon: Okay. Wow. So next there was shared array buffer.
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.
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.
(0:48) Ian explains that "micro" doesn’t imply number of lines of code but "A bounded concept/business capability within your Domain" (put forth by Martin Fowler and James Lewis)
(1:20) Ian talks about breaking the domain problem down further and further for simpler testing, better fault tolerance and incremental releases.
(2:20) "If you can’t QA everything you need to be able to monitor and respond to issues rapidly."
(2:42) Scott Allen asks if Devops is a driver for Microservices rather than physical deployment or team size.
(3:00) Ian talks about the scale limits of developers and teams and how component based architectures.
Have we been here before?
(4:00) Ian talks about how Microservices is the next generation of component-based architectures after DCOM, CORBA, SOA and the importance of understanding what worked, what didn’t and why.
(4:49) Asking a component for a cup of tea vs telling something how to make tea highlighting the difference between Microservices vs RPC. RPC was very coupled to behavior which lead to fragile APIs.
Finding the "micro" sweet spot
(5:50) Jon asks how you manage the complexity of orchestrating many smaller pieces.
(6:15) Ian advises against going too small – Nanoservices – where the overhead of a service overshadows the utility value of it.
(6:30) "It’s really hard to get a feel in a new domain of where those points are that you can slice effectively" – one solution is to start exploring the domain in a traditional monolithic way and to break the parts apart at the seems to get the tradeoff right.
Tooling and support
(7:06) Jon asks what a good way to manage these services including profiling and monitoring.
(7:20) Ian recommends some tools to help:
New Relic for introspective monitoring and diagnostics.
Logstash or Splunk for log analysis and the usefulness of adding a GUID to a request that flows through messages and logs to correlate the activity.
(00:18) Jon asks Robert what his presentation was about. Robert describes his talk covering in-memory databases, comparing OrigoDB, Redis and Heketon.
OrigoDB and working with in-memory databases
(00:40) OrigoDB is Robert’s open source project. Jon asks why Robert decided to write his own in-memory database when there others available. Robert says that OrigoDB is unique, and that they’ve been working on it for a long time and there was nothing available when they started on it.
(01:18) Jon asks how it compares to relational databases. Robert says that when you move to in-memory, you’re no longer constrained by the need to structure your data in a way that can be easily stored on disk. You can take advantage of the random access nature of memory, and thing more graph oriented than stream oriented.
(02:07) Jon asks if the data is persisted and follows ACID principles. Robert says that the data is in memory in any form you like, and you log transactions when you make changes – writing the events to disk or a database.
(02:48) Jon asks how data is loaded when an application starts up. Robert says it loads the most recent snapshot and then replays all events that occurred after the snapshot. You can choose the serialization format – JSON, binary and Protocol Buffers (protobuf) are supported. Protocol Buffers fast, compact and interoperable.
(03:45) Jon asks what kinds of applications work best with OrigoDB. Robert describes the problem it solves: data access and databases are too slow, so we need to use caching to compensate for that. Traditional relational databases were a good fit when memory was scarce, but now your entire application’s data can fit in memory. Also, historically, relational databases reflected the entity model and allowing business users to run queries; now we’re mapping back and forth between models which don’t match. If you keep all the data in memory, everything’s in one place and the data access is incredibly fast. That allows you to do everything single-threaded, really quickly – on Robert’s laptop he can do 50,000 ACID transactions per second.
(07:35) Jon asks what the difference is between using OrigoDB and just using his own in-memory structures. Robert explains that’s how OrigoDB works – you use your own in-memory structures and do LINQ queries against them. OrigoDB adds in snapshotting, persistence, etc.
OrigoDB support for clustering
(08:22 ) Robert says that in addition to the embedded engine, they also have an out-of-process server product that supports clustering with replication, load balancing, and off-site backup.
(09:12) Jon asks how the clusters communicate. Robert says that it’s via TCP, inspired by SQL Server clustering.
(09:50) Jon asks what happens when the master goes offline. Robert says that there’s no automatic failover, but you can do manual failover using the web-based UI.
Other OrigoDB features: Web UI, cross-platform, cached queries
(10:29) Jon asks about the web UI. Robert says there’s a web-based UI that runs in the engine using Nancy. It supports some nice features, including ad-hoc queries using Razor syntax
(12:35) You work with OrigoDB using commands and queries. You can also send in LINQ commands as text and they’ll be compiled, parameterized and cached.
How Much Memory?
(13:17) Jon asks how much memory it will take. Robert says over the past twenty years, the transactional workloads for the projects he’s worked on have all been under 200GB. You can offload your reporting data to a relational database if needed.
(14:18) Jon asks if the server product is commercial software. Robert said they’ve tried the revenue model but haven’t had any sales. In the next release, they’re pivoting to everything free and open source and trying to build a support business.
(15:15) Jon asks what kinds of projects he’s built with OrigoDB. Robert talks about a consulting job for a large healthcare company in Sweden. The customer was having really bad performance problems – each service would create business components, which would then create data components. Due to the business requirements, the data transactions were complex, and many were written using cursors. Robert said he traced some database use and found that a single transaction could make thousands of database round-trips. Robert did a proof of concept using simple C# collections in-memory and found they could do tens of thousands of transactions per second. Robert says that transactions in SQL Server require logging pages of data to disk, whereas logging an OrigoDB transaction is often just a few bytes since it’s just logging the command.
(18:18) Jon asks how many snapshots are maintained. Robert says he tries to avoid snapshots since they require a read lock. You can also use an immutable model (using multi-version cursor control).
(19:21) You can truncate events when you snapshot, but then you’re losing information. Robert and Jon discuss how this relates to event sourcing.
Other In-Memory Databases: SQL Server Hekaton, Redis, VoltDB
(20:02) Jon asks what Robert showed off in his talk. Robert says he normally does workshops that are a few days long, so squeezing everything into an hour is difficult. He does demonstrations showing OrigoDB, Redis and Hekaton, but his main message is that your application’s data probably fits in memory and memory is cheap.
(21:03) Jon asks about Hekaton. Robert explains how Hekaton works, pointing out that it supports a hybrid model in which only certain tables are in-memory. The advantage is that you can use your existing SQL Server tools, ecosystem and code.
(23:20) Robert mentions VoltDB, a startup that offers an in-memory, distributed relational database engine.
Redis is a key-value store. Most people use it as a cache, but the values in themselves are structures, so a value can be a hashtable, list, queue, sorted set, etc. There are predefined commands that kind of look like assembler.
(24:45) Jon says he remembers running into some objects that were difficult to serialize. Robert says that the default formatter for OrigoDB is the binary formatter, and you have to mark your objects as serializable. If you use Protocol Buffers require you to define a mapping.
(00:18) Jon says hi to Chris Klug and mispronounces his name and feels bad about it but Chris is understanding and lets it go.
SOLID principles and Pragmatism
(00:27) Chris has been doing SOLID talks for a while, but this time he spoke about when to use SOLID principles and when not to. However, open-closed and Liskov substitution principle are both examples that might not fit into all scenarios. Chris says if you go full-SOLID you might never ship anything… and shipping is a good feature, too.
(01:28) Jon asks Chris if he gets some pushback. Chris says he does, from both sides.
(02:20) K Scott asks Chris about how he applies the Single Responsibility Principle.
Migrating from Silverlight to Angular and TypeScript
(05:44) K Scott asks Chris if he’d always use TypeScript. Chris says maybe not for simple projects, since TypeScript makes things a little more complicated due to the transpiler step. But the type safety’s really nice for any larger project.
(06:28) Jon says he thinks that Silverlight was a good bridge to HTML5 since it let you get started with things like video on the web long before HTML5 supported them. Chris kind of agrees, but points out that HTML5 video still doesn’t support DRM, and he still prefers XAML to HTML and CSS.
(08:22) Jon asks what Chris would recommend to developers who are starting on the transition from XAML to HTML5. Chris says just jump in and get started – probably using Angular and TypeScript. It’s really not that hard once you get started.
Kite surfing and being a rock star
(09:00) Jon asks Chris what he does for fun in his free time. Chris says he’s a kite boarder, which is a little tricky because he lives in Stockholm.
(09:42) Jon asks Chris about his picture from the NDC speakers page, and Chris tells the story.
(10:24) K Scott asks Chris about the best spots he’s been kite boarding, and Chris mentions a few in South Africa.
While at NDC Oslo, K Scott and Jon talked to Damian about ASP.NET 5, running DNX cross-platform (including Raspberry Pi), the exploratory work he and the team are doing to make ASP.NET 5 run really fast, TagHelpers, and his favorite Redmond craft beers.
(00:18) K Scott asks about the general status of ASP.NET 5 and what Damian’s been up to. Damian mentions the work the team’s been up to and the two talks and two days of workshops he and Jon just completed.
ASP.NET 5 – portability and cross-platform
(01:16) K Scott asks about the advantages of running ASP.NET 5 on the Core CLR. Damian says the big advantages are portability (bundle the runtime with your app) and cross-platform – anything beyond that is secondary. It is lighter, more compact, etc., but that’s not the main goal.
(03:04) Jon talks about how he went through a depressing smackdown trying to talk managers into letting him upgrade corporate apps to ASP.NET 2.0 (when it first came out) and the "one framework per server" monster shut him down. Damian points out that you do lose some things in translations – there are some Windows abstractions and API’s that will only be available in the full CLR. So if you have a requirement for Windows-specific functionality (COM, directory services, etc.), you’ll need to run your application on the full .NET Framework.
(03:59) K Scott asks about the experience of bundling the runtime with your application. Damian describes how he demonstrated this during his presentation, bundling multiple runtimes (e.g. Linux, Mono, Mac, Windows) with an application.
(04:38) K Scott asks hosting on Linux. Damian describes Kestrel, the web host for ASP.NET 5 that runs on libuv (used by Node and other servers).
ASP.NET 5 HTTP Performance, Pipelining and HTTP 2
(05:50) K Scott asks how Damian expects ASP.NET 5 to perform relative to Node.js. Damian describes the performance testing testing he an his team have started looking at using the TechEmpower benchmarks. He lists several abstractions and implementations they’ve looked at, starting with the simplest benchmark that just tests plaintext response.
(10:15) Damian explains how pipelining works. K Scott asks about how HTTP 2 fits it. Damian talks about how both enable higher HTTP throughput.
(12:17) Jon asks if the useful the HTTP plaintext test is and Damian talks about this test focuses on efficiency in speaking HTTP, there are a lot of other tests and features they’ll need to look at as they move up the stack.
(12:55) K Scott asks why the ASP.NET 5 stack is nearly twice as fast as ASP.NET 4.x for plaintext responses. Damian talks about how legacy compatibility in ASP.NET 4.x extends all the way back to classic ASP, whereas ASP.NET 5 only pulls in specific features as needed by the application.
(14:44) Damian says they’ll also be looking at massive concurrency (important for realtime applications) and asynchronous background work.
(15:32) Jon incorrectly guesses that async background work will be important for pipeline scenarios. Damian says that since pipelining only works over the same connection, so this is more relevant for HTTP 2.
Minimizing Kernel / User Mode Transitions
(16:56) Jon asks about the importance of switching between kernel and user mode. Damian explains why that transition is necessary and the performance impact it has. He talks about how some of the memory management techniques they’re looking at.
(21:12) Jon asks about some newer APIs Damian had previously mentioned to him. Damian talks about Registered IO (RIO) in Windows 8 and Windows Server 2012 R2. K Scott asks about HTTP.SYS kernel mode caching.
(24:07) Jon asks if there are some performance impacts he should pay attention to as a web developer. Damian talks about the process ASP.NET MVC pipeline and how content could be double or triple buffered in some cases as it moved through the pipeline. That’s an issue when you’re looking at client-side optimization, because bytes aren’t flushed to the client as early as possible. In ASP.NET MVC 6, it’s now possible to explicitly flush content, and the double and triple buffering has been removed.
(27:14) K Scott asks about the baseline KB allocated per request. Damian said that previously it was 15-40 KB per request before your application code did anything; now it’s under a KB. There are some other buffers they can probably pool as well.
(28:22) Jon asks TagHelpers. Damian explains some of the problems with HTML Helpers, especially when you need to control the HTML that’s being output. TagHelpers allow you to call HTML Helpers using an HTML-like syntax (tags and attributes) so you get all of the benefits of working in the HTML editor.
What do you do for fun?
(30:33) K Scott asks Damian what he does for fun. Damian talks about craft beers in Redmond and his new espresso machine. K Scott asks Damian about some of his favorite craft breweries; Damian talks about Kilty MacSporran and Hogus Maximus from Postdoc Brewing and Black Raven Brewing Co.
(00:18) Jon starts by asking Rachel what aspects of accessibility she addressed in her talk. Rachel overviews some aspects: visual, auditory, motor and cognitive needs.
(02:20) Rachel describes how increasing font size on a page is a really quick change that helps a lot of people, pointing out that eyeglasses are an accessibility technology.
(02:50) Using HTML semantic tags and ARIA attributes help people who are using screen readers to navigate your site – otherwise screen readers have to read through ads, page headers, etc. for every single page.
(03:45) There are 1.4 billion people with some kind of accessible needs.
(04:06) K Scott asks how well modern screen readers handle things like semantic HTML markup. Rachel says yes, and also mentions alt tags for images. Jon and Rachel discuss how easy it is to just rename divs to semantic tags like header and nav.
(05:13) Jon asks what ARIA is. Rachel says it stands for Accessible Rich Internet Applications and describes how ARIA attributes can give hints to screen readers for things like required fields and validation errors.
(06:44) Rachel recommends that listeners download a screen reader like NVDA or WebAnywhere, blindfold yourself and take some time navigating their sites to understand the experience.
(07:28) K Scott asks about building SPA sites with technologies like React, Angular, Ember. Rachel says that ARIA elements still work, and there are ARIA and semantic elements that indicate to screen readers that navigation is occurring. K Scott asks if navigation within a SPA causes the screen reader to start over; Rachel says that it does and recommends using skip links. Rachel recommends visiting the accessibility site webaim.org, which shows a good example of using skip links.
(09:25) Jon asks how Rachel got interested in accessibility. She’s worked on a lot of government sites which require accessibility standards, but she’s just personally interested in making sites that are easy to use. She describes some of the frustrations in browsing websites with ads and modals, then points out that it’s even worse for users with accessible needs. Users with accessible needs make up 20% of the population, so you can easily justify any extra work as worthwhile just in expanding your user base by 20%.
(12:30) K Scott asks if Rachel has any other resource recommendations. She recommends using the WAVE scanner on the WebAIM site, which indicates a number of issues including contrast.
Jon asks about color blindness considerations. Rachel says that it’s also important – Facebook is blue because Mark Zuckerberg is colorblind. She recommends using a tool called the Color Oracle. Rachel and K Scott discuss a number of considerations to make sure your sites and applications make sense to users with color blindness issues.
(15:55) Rachel gave another talk about testing with ASP.NET MVC. She covered xUnit for testing application code, qUnit for front-end testing, and UI automation testing. She recommends starting with unit testing, then adding in front-end and automation testing.
(16:50) Rachel thinks UI automation testing is kind of a hidden gem – Visual Studio has coded UI tests, which can emulate user actions, which just records your UI interactions so that it can play them back later. K Scott asks about timing issues and Jon asks about use with single page application. Rachel says just consider coded UI tests as a user – you can even have a QA or actual users click through the site and record their actions. K Scott asks what versions of Visual Studio support it. (ed. note: the recorder is only in Visual Studio Enterprise).
(18:50) K Scott asks what Rachel does to relax when she’s not testing and calling people out for accessibility issues, and Rachel tells us her upcoming travel plans.
While at NDC Oslo, K Scott and Jon caught up with Udi Dahan to discuss his experiences in building a distributed company (Particular Software) to offer support and services for NServiceBus and related technologies.
(00:18) K Scott introduces Udi Dahan, whom we last spoke to in 2010.
Growing from an open source project to commercial product: how and why
(00:41) Udi describes why he started a company to better support the NServiceBus community. On his own, he wasn’t able to both support himself doing NServiceBus training and the NServiceBus project. He decided he was doing his users a disservice by continuing the free open source model, but he wasn’t sure it would work since there weren’t really precedents for taking an open source project commercial in the .NET world.
(03:17) K Scott asks Udi about the global reach of his distributed company.
Commercial Software and Licensing Are Hard
(04:10) Udi describes the learning curve to start selling a commercial product – complications with contracts, legal issues, etc. Pricing is complicated, too, because companies are structured so differently.
(06:43) K Scott asks if each customer requires a separate license.
(07:11) Jon asks what commercial model they settled on. Udi explains that the "call for a quote" model is common for large customers, but for "normal" customers it’s generally $25 per month for a developer machine.
(08:15) Jon asks what changed with respect to the license and code availability. Udi explains that the code is still on GitHub, the license just changed for cases where it’s being used commercially and developers don’t want to release their code. The code is now under the RPL – the Reciprocal Public License.
(09:12) Jon asks about the difference between the RPL and the AGPL licenses. Udi explains that AGPL explains that AGPL only requires releasing your code to your users in order to use the code for free, so there’s a loophole for cases like large intranet deployments. RPL requires releasing your code to the world for free use, not just to your users.
(10:37) Jon says he’s happy to see open source as a thriving business model. Udi clarifies a bit – the common approach is a service based open source model, but this it really pushes you towards working with a few very large customers. The problems with this approach is that you’re both subject to large risk if you lose your giant customers, and you’re competing with enterprise vendors who have deep pockets.
Running a Distributed Company
(13:44) K Scott asks Udi how he manages a growing, distributed company. Udi says that it’s good that the growth doesn’t happen all at once.
(15:15) Jon asks how they handle communications. Udi says it’s important to write everything down and to make use of lots of web conferencing. All web conference meetings are recorded so people can catch up later. Jon says says he thinks that writing everything down makes things easier for your company over time. Udi says he wouldn’t say it’s easier, it’s more of a maturity forcing function – if you’re able to get through it, you’re able to do a lot more and get new employees up to speed a lot faster.
Surprise Lightning Round!
(18:43) K Scott springs a surprise Lighting Round on Udi!
(22:03) Event Sourcing
(26:43) K Scott asks what Udi does to relax in his spare time. Udi says he’s got four kids, which isn’t necessarily relaxing but definitely occupies his free time.