(01:20) Jon ran over to the talk when he heard (via Twitter) that Gary was (or will be, it’s all so confusing) mentioning Singularity.
(02:20) Jon asks about Gary’s references to the performance improvements gained by turning off hardware protection. Gary and Jon discuss how Singularity and the (yet to be developed) Asm language offer high performance due to this approach.
(06:30) Jon asks what we’re writing our code in, now that it’s compiling to Asm. Gary doesn’t specify that – it’s not really necessary to pick one, and he doesn’t need to alienate anyone unnecessarily.
(08:54) Jon asks if Asm is perfect, or just good enough. Gary talks about how both Asm and the HTML DOM (which also has become universal in 2035) are full of flaws, but they’re better than fragmentation. Jon and Gary talk abouthow
(10:45) K Scott says this all sounds plausible, all that’s needed is time. So, why 2035? Gary talks about his reasoning… it could happen faster. He talks about some core services moving into operating system kernels, and Jon and K Scott agree.
(12:55) Jon applauds Gary’s 25-30 minute talk length.
(13:15) Jon mentions some of the interesting audience questions at the end of the talk. Gary talks about some of the most interesting. All of them were pretty easy except for the question of parallel execution.
(15:20) There’s a discussion about the limitations of x86 architecture and parallelism.
(16:10) Jon asks about some of the other things Gary’s up to – there are the Destroy All Software screencasts and a consumer product Gary’s working on but isn’t ready to announce yet.
(16:40) K Scott asks Gary about relaxation and recreation. Gary says that he’d become really preoccupied with things that were bad in software, and it was stressing him out. He’s made three changes: intentional social interactions, crossfit and playing guitar. All three have helped him be less angry about the state of software… which is all hacks on x86, when we get down to it.
That’s just bad, and it’s not specific to node.js. You should use the short circuit in the || operator to assign default values to your parameters instead of relying on ordinal indexes in the args pseudo-array in my opinion.
It has the same effect, but in my opinion it’s a little easier to understand.
When I first saw these words written on Twitter I thought, “No way, Agile can’t be dead. There is too much money invested. Too many groups, conferences, books, and tools to be sold.” Turns out, I was right. People weren’t saying that “Agile” is dead, but that the term has been diluted so much as to be meaningless.
I have been thinking about that idea for some time, I actually thought that “Lean” bit the dust long before “Agile” did. Lean was dead as a meaningful term once “Lean startups” started to spring up. So do I really care that “Agile” as a term referring to the Agile Manifesto is dead? Not really.
So what next? Does the over-abundance of money-changers in the Agile temple mean that we give up on Scrum? Lean? Kanban? That we don’t value “Individuals and interactions over processes and tools”? No, we can continue to use these tools if they provide value. I hope that this discussion around the word “Agile” causes teams and individuals to reflect and evaluate what kind of return they are getting based on where most of their energy is spent. I’ve found that most Agile tools are centered around providing feedback and reports to managers (Who, in the Chicken & Pigs store are often Chickens. Often they are just farmhands to really bury the metaphor).
“Why do we need to point all of our stories in Super Frumpy Agile Tool 2.3?”
“So we can measure your velocity.”
“Why do we need to measure our velocity?”
“So we can estimate how long it will take you do finish”
“But velocity doesn’t really tell you when we will finish, only how many points we can get done, on average, in a sprint?”
“blurrggghhhh bar charts!”
Note: There’s a little bit of background noise due to the conference recording.
Intro to Superscribe
(00:20) Jon asks Pete to explain what Superscribe’s graph-based routing means. Pete explains how traditional routing needs to check each route for a match, one at a time. Graph-based routing stores using a structure, so there are some performance gains due to only matching routes with a matching structure rather than using string matching.
Extensibility due to strongly typed route nodes
(02:37) Each node in the graph is a strongly typed entity, so you can use an activation function for each node in the graph to determine if it’s a match rather than just using a simple regex match. You can write custom activation functions for any node. For parameter matching, Superscribe uses TryParse rather than regex matches.
(04:22) There are three guiding principles behind Superscribe: composability, efficiency and extensibility.
The OWIN connection
(05:22) Jon asks where Superscribe can be used. Pete says it’s currently usable in Web API and OWIN, with NancyFx and possibly MVC on the way.
(06:02) In addition to activation functions, you can also define an action function which says what should happen when a node is matched. This allows running different OWIN middleware based on route matches. This means you can hook up authentication middleware using an action function which will only operate on a specific node.
Graphs vs. Trees
(08:16) You can hook up optional nodes, which would allow things like an optional /debug/ route prefix which would hook up tracing middleware. Pete says this is something that wouldn’t be possible with tree-based routing (available in NancyFx).
(09:00) Jon asks what the difference is between tree-based routing and graph-based routing. Both are connected nodes, and trees are a type of graph in which the node connections branch out and ever reconnect, whereas in a graph any node may connect to any other node.
API options: Different ways to define route graphs
(09:53) Jon asks how developers will define nodes in Superscribe. Pete talks about the difference between economy and expressivity: economic design has fewer options but is easy to learn, while expressive design offers many options but a steeper learning curve. Superscribe is currently more expressive, using a domain specific language using operator overloads. It overloads the / symbol to add segments and the | operator to allow defining multiple routes (or the entire graph) in a single line.
(12:28) Jon says that you can always add an economic API layer over an expressive one. Pete agrees and says that since everything’s strongly typed underneath, you can configure it explicitly or fluently as well (if you don’t like the DSL).
(13:14) Jon asks about how to hook in action functions or activator functions. Pete says they’re currently not available in the DSL, so you’d need to build those notes out by hand at this point.
Miscellaneous questions and pretend ending
(15:08) Jon asks about using routes for localization. Pete talks about some options for doing that.
(16:28) Jon asks what’s next on the list. Pete lists some features: syntax improvements and OWIN middleware ideas.
(19:12) Jon asks how people can learn more and keep up, Pete talks about Superscribe.org.
Update on the 0.4 release (follow-up phone call)
(22:11) Jon asks what’s new in the 0.4 release. Pete starts by describing some improvements to the routing syntax.
(23:02) You can now combine Web API replacement routing, traditional routing, Attribute Routing and Superscribe in the same application, so you can pick and choose.
(23:24) You can wire it up with an IOC container, so you can compose different components based on routes. You can also use route information in OWIN middleware.
(23:56) Everything about the new release is up on the Superscribe.org site.
(00:18) Brock gave two presentations on security at NDC, as well as a two day pre-conference workshop with Dominick Baier (also on security).
Brock’s contribution of CORS support to ASP.NET Web API
(00:35) Jon asks Brock about the CORS support he recently contributed to ASP.NET Web API. Brock tells the history of how he built a CORS implementation at Thinktecture and how he went about contributing it.
(01:21) Jon asks Brock about what was involved in his CORS implementation. Brock describes the limitations browsers place on cross-origin requests and how CORS solves that. It’s defined in the HTML5 specs and is supported by all modern browsers.
(02:12) Jon asks what’s required on the server for CORS to work. Brock explains how servers respond to browsers to tell them they support CORS and which other servers they want to allow communications with.
(02:45) The most common form of browser communications for CORS is via an OPTIONS request from the browser, to which the server responds using predefined headers.
(03:14) K. Scott asks about the process of getting his CORS implementation added to the ASP.NET Web API codebase. Brock explains the process, including his big pull request and the month of work he and Yao put in to getting the code "Microsoftified." Brock’s implementation was pretty broad, the shipping version was targeted just at Web API.
Thinktecture Identity Model
(04:59) Jon asks if there’s any reason to use the Thinktecture Identity Model version now. Brock explains the other areas that Identity Model supports, and that many of the features of Thinktecture Identity Model have been removed as ASP.NET Web API has added a lot of these features to the core.
ASP.NET Identity and Membership Reboot
(06:09) K. Scott asks how the identity features in Thinktecture Identity Model compare to the new features shipped in the new ASP.NET Identity system. Brock describes the problems that the ASP.NET Identity system was designed to solve.
(07:02) Brock describes the membership system he wrote as an alternative to the ASP.NET provider model system, called Membership Reboot. His Membership Reboot system includes things like password resets and e-mail account verification which are not in the initial version of ASP.NET Identity, but he thinks that the new system is well architected to add these in, since it’s just a NuGet package.
(07:42) Jon asks Brock about the other features Membership Reboot covers. Brock says that was the subject of one of his talks – how he implemented features like password reset, e-mail verification and two factor authentication without opening up attack vectors.
(08:27) K. Scott asks about the other talks Brock did at NDC London. His other talk was on ASP.NET Core Security – he focused on teasing apart the membership and forms authentication parts so they’re understood as separate components.
(09:20) Jon asks Brock how he got interested in security. Brock talks about his background in programming, and how he thinks it’s interesting to see how the different parts work together.
(09:48) Jon talks about cases he sees where developers decide they want to write their own security implementations for speed or other reasons. Brock says that was one of the key points of his talk: you don’t want to implement those things yourself.
(10:19) Jon asks about common security issues that developers commonly forget to consider. Brock lists several: proper implementation of SSL, password management, etc.
What’s Next For Brock?
(11:09) Jon asks what’s next for Brock. He’ll be busy: he’s got a lot of course rework for recent updates, Identity Server v3 (with OpenID Connect).
(11:46) Jon asks how OpenID Connect affects him as a developer.
(13:15) K. Scott asks what Brock does to relax. Brock does Tai Chi and Kung Fu.
(00:18) Jon welcomes Paul back – he’s been on a few times before, talking about GitHub for Windows and Reactive UI.
(00:28) Paul has a dream: he’d like to write applications in C# and have them run everywhere: iOS, Android, Windows Phone maybe even WinRT. He’s not interested in sharing everything (views or designer code), but there’s plenty of other code that developers shouldn’t need to rewrite for every platform.
(01:16) Jon asks if Xamarin doesn’t help with this. Paul says that Xamarin’s intention is to give you direct access to the native platform, which is good when developing for a specific platform, but not when you’re working on cross-platform applications.
01:32 Paul’s been on a crusade, writing a lot of small, cross-platform libraries.
(01:48) splat is a library that lets you share certain things in cross-platform viewmodels, the biggest one being images. It allows for the simple load-and-display scenario. Each platform hast its own image types; splat gives you a common abstract image type that you can then cast to a native image. This allows you to write cross-platform viewmodels and just have native views. splat also gives you System.Drawing on platforms that don’t have it, e.g. WinRT by providing common types for primitives like colors and rectangles.
(04:08) Jon asks if portable class libraries will help with this. Paul explains the PCL operations for splat.
(04:45) Jon asks about support for high-DPI / Retina images. Paul talks about how the different platforms handle high DPI images.
(05:44) Paul says that HttpClient is implemented on Xamarin using HttpWebRequest. This has some problems: it doesn’t use 3G on iOS, and it’s a blocking call. That means if you make several web requests, you end up with a bunch of waiting threads and the app slows down.
(06:45) There are better APIs available on each platform, so Paul’s taken the most popular HTTP libraries on each platform and made them HttpClient compatible. HttpClient allows you to specify an HttpMessageHandler, so in your portable library you can just drop in the handlers provided by ModernHttpClient .
(08:33) In the latest version, Paul’s done work to make sure you can cancel requests. This lets you cancel a request based on headers (e.g. status codes or ETags) which can make a big difference on mobile network usage.
(09:23) Jon asks how it works in the Windows platforms. Paul says that on WinRT it’s already built in, and on Windows Phone there’s no way to do anything better than HttpWebRequest.
Jon asks a bit more about how you use it. Paul explains how platform-specific factory methods can provide the different handlers.
(11:00) punchclock lets you make multiple web requests; it queues them up and makes the requests for you so there are a maximum of four web requests at a time. It’s based on an Android library called Volley.
(12:20) punchclock is a priority based scheduler. You can then make things like analytics low priority and user initiated requests high priority.
(13:12) It’s not just specific to network requests, you can use it for anything that’s awaitable.
What’s Paul using these on?
(13:35) Jon asks Paul what kind of mobile applications he’s building that are pushing him to build these libraries. Paul says he’s been working on some internal applications at GitHub. One example is a support application called Halp. It lets customer support people use @mention style messages to developers, allowing developers to respond quickly from mobile devices.
Reactive UI documentation
(15:10) Jon asks Paul what he’s been doing when he’s not writing cool code. Paul says he’s been working on documentation for Reactive UI by writing one big article per day.