At NDC, Jon and K Scott sat down with Tom Dale (co-founder of Ember.js) and Rob Conery to recap their cage match battle, compare Ember.js and AngularJS, and hear from Tom about where Ember.js is headed.
Download / Listen:
Herding Code 169: Tom Dale and Rob Conery on the Ember.js / AngularJS Cage Match at NDC
- (00:18) K Scott and Rob asks Tom and Rob to introduce themselves and recap the Cage Match.
- (01:22) Tom describes the challenge and thanks Peter Cooper for moderating. Rob describes the scenario – start with installation and creating a new project, then move to routing and navigation between views.
- Demo vs. Reality
- (02:28) Rob says it’s fun to do a demo with Angular, but once you need to do more structured things you have to start over and reimplement with modules, etc.
- (02:43) Tom says that seeing the TekPub screencast about AngularJS informed a lot of their design for Ember.js. The result is a framework that gives you the same simplicity in getting started, but also grows with your application pretty easily.
- You Just Don’t Do That
- (03:22) K Scott asks if they pretty much match up if you’re looking at a feature checklist, and if it’s more about how you implement things. Rob says AngularJS is much more component based and talks about some things that came up during the cage match which were tricky in Angular, because "you just don’t do that".
- (04:18) Jon asks if there’s an overall effect to how you build your application because it’s just not how the framework works. Tom says it’s unacceptable when your designer comes to you with a user interaction design for you to tell them it’s just too hard to do in your framework, so you won’t do it. As framework developers, they spend a lot of effort on composability. Rob says that he sees Ember.js as more prescriptive, while AngularJS provides more building blocks. Rob says it seems like Rails to him, in that it just goes a lot better for you if you give in and go with the framework’s opinions.
- (06:13) Jon asks about how customization works in Ember.js, compared with Angular’s use of directives and filters. Tom says that’s done via helpers, referencing an example from the cage match.
- Client-side MVC implementation and The Importance of URLs
- (06:34) Rob asks Tom if it makes sense to say that "if you can think of it in a server-side framework like ASP.NET MVC or Rails, you can think of it in Ember.js". Tom says it’s not the same, because server-side MVC requests are short-lived compared to client-side applications. The real challenge is how you manage that state over time.
- (07:17) Tom says that they think URLs are really important. Their challenge has been how to marry the concepts of desktop MVC with the fact that they have a URL, and he thinks they’ve nailed it. Jon asks how that compares to Angular; Rob says that it’s not a primary concern in AngularJS or Backbone.
- (08:37) Tom says he considers your web application broken if he hits refresh and doesn’t see the same thing he saw before. Everyone screws this up, not because they’re idiots but because it’s hard, and if you don’t have this built into the framework you’re using you’ll mess it up. (09:06) K Scott asks what kinds of applications are the sweet spot for Ember.js. Tom says his first real professional programming gig was working on MobileMe / iCloud apps. They were big apps written in SproutCore. He says it’s important to be able to add features without breaking old features. Functional reactive programming and strong conventions help support this.
- State and Scope
- (10:38) Jon asks about the difference in maintaining state between Ember.js and AngularJS. Tom talks about how the Ember.js controller is similar to Cocoa and explains how the the controller presents the model to the template. Rob describes the $scope in AngularJS and compares the way AngularJS handles things more explicitly, whereas Ember.js is more conventional.
- Testing, testing
- (13:54) Jon asks Tom about his comment on testability. Tom says that Angular’s Karma test support is really nice, and they’re working on catching up in Ember. Rob says that in AngularJS you’re just working with basic objects, which is really nice when you’re testing.
- (16:08) Tom says Ember.js requires you to do things correctly from the beginning; they won’t give you any foot guns to make things easier. Helpers help.
- (16:42) K Scott asks how change detection works. Tom explains the differences – AngularJS uses dirty checking against the DOM, while Ember.js uses accessors (like Backbone). Tom says that the performance is better in Ember.js. Angular’s situation will improve when they get object.observe, which ironically will happen at the same time Ember’s situation improves due to support for object proxies.
- (18:37) K Scott says he’d like to be able to conventionally wire up events. Tom talks about event delegation in Ember.js.
- The SEO Elephant in the Room
- Using Ember.js When You’re Not Tom
- (22:28) Jon says that one issue with highly conventional frameworks is that it can be hard when you’re getting started and don’t know the conventions. Tom agrees and says that you’ll be frustrated if you experience learning difficulty before you feel the power and says the solution is documentation and good tooling. He mentions a coming Chrome extension that will show you what controller and model are backing content on the screen when you hover over it. K Scott says he’s pretty impressed with the Ember.js documentation.
- What’s Next? How about some Prollyfills?
- So who won? Any missed opportunites?
- (29:45) K Scott asks who won the cage match and Rob admits to having been destroyed. K Scott asks why Rob keeps challenging framework authors to cage matches.
- (30:52) Jon asks Tom about the curveball that he threw at Rob during the cage match. Rob and Tom agree that coding a directive on the fly is not easy.
- (31:42) Jon asks Tom if there’s something that Rob could have asked Tom that would be hard in Ember. Tom says that they just added a competitor to filters using bound helpers, but if Rob had thrown list sorting at him he’d have had a hard time.
- (32:54) Jon asks about a viewer question on the emphasis on getting started vs. maintainability. Rob says that they’d first focused on composability, but nobody wanted to use it until it was easy to get started. Framework libraries don’t get the luxury of forcing a difficult learning experience on developers – if he can’t show value in 5 – 10 minutes, you’ll leave.
- (34:42) K Scott asks Rob and Tom what else they’ve got going on. Rob plugs some TekPub videos (listed below) and Tom plugs some upcoming classes he and Yehuda will be offering (also listed below).
This week on Herding Code, the guys talk to John Sheehan about the recent launch of his new API developer tools company, Runscope.
Download / Listen:
Herding Code 168: John Sheehan on Runscope
- (00:30) "What is Runscope and why should I care?"
- (00:55) Runscope is the ultimate API integrator developer’s toolbox. It helps you solve the problems you encounter in dealing with API’s from a consumption standpoint. It takes invisible API traffic and makes it visible, then helping you do all sorts of things with it: debugging, sharing, retry a request from the website, testing features like response playback without hitting the API, webhook debugging, etc. When you rely on an API, you’re not just taking on a service dependency – it’s code code that’s running on someone else’s service, and you should treat it like it’s code that’s under your control. You should apply the same testing rigor and should have the same debugging facilities.
- (03:25) Jon asks about the launch. Anyone can try it out now at runscope.com. John talks about the internal preview (shoutout to Kevin Dente, the first beta tester) and the launch at GlueCon and press at TechCrunch and TheNextWeb.
- (04:35) Overview of features:
- Traffic Inspector
- (04:55) In your code, instead of calling an API directly, you create a Runscope URL by including a Runscope bucket key and replacing dots with dashes. Essentially you’re pointing your API calls at Runscope, which then extracts the hostname and makes the API request for you. A lot of other tools require you to change your API calls by modifying your authentication, adding parameters, etc. Runscope doesn’t require any changes outside of the hostname, and all of your original headers and request parameters stay intact. This means you can just flip it on by changing your hostname and turn it off when done. You can then view all your requests in the Runscope website, filter to only show errors, All your requests show up in
- (07:45) Scott says this is essentially a reverse proxy. John agrees that’s technically correct, but they avoid the term because they’re doing a lot more.
- (08:13) Scott asks if Runscope adds headers to allow filtering or other things. John says the only modification they make is to add a Runscope message id header to allow lookup. They’re thinking of some things in the future like caching credentials to apply to a lot of requests and other features that benefit performance, security, etc.
- (09:27) Jon asks about the security concerns, as Runscope is kind of like a man in the middle. John says they’re very concerned with security, and points to https://www.runscope.com/docs/security for a lot more information about their security practices. They’re looking at future things like encrypted storage, and currently if you make an SSL request to Runscope they will forward it over SSL to the API provider.
- (11:45) Jon asks about cases like multi-legged auth. John says everything just flows through Runscope, with one exception – if a response comes back with a location header then Runscope will modify the location to a Runscope url so if the client follows it it’ll be captured.
- (12:40) Scott asks about how geolocation works, since Runscope is making the request from a different location. John says that currently they’re making requests from US East Coast, but in the future they want to allow requests from specific geographic areas.
- (14:10) Scott asks about a current app he’s working on which requires a custom certificate to connect to an API and asks if that would be supported. John says that they’re looking at both support for custom certificates as well as on -premises installations to support those scenarios.
- (15:35) Scott asks about support for non-standard ports. John says they support that using a Runscope request port header.
- Request Editor
- (16:09) Jon asks about the Request Editor. John explains that they really wanted to make it possible to edit and create requests as easily as any other code. Their original inspiration was the hurl.it site. Jon interjects that he loves using hurl.it to see where shortened or dodgy urls will take him before clicking on them. John says they’ve taken the idea of hurl.it and really filled it out to include storage, advanced editing, etc. They also built in some helpers for basic auth, digest authentication, OAuth 1, OAuth 2 token generators, etc.
- (19:45) Scott asks if they’ve looked at integrating OWASP tests to run some automated security inspection for things like SQL injection, XSS, redirect attacks, etc. John says he’d like to let people create collections and share them with others.
- Shared Requests
- (21:11) Jon says that when he was testing during the beta and hit a question, John just had him share the request with him. John says that he really wanted that feature when he was at Twilio, and they currently use it all the time internally.
- (22:39) Jon asks if there’s a way to download or otherwise privately share a request. John says the best way to do that now is use team account, which allows for privately share requests within the team. They’re also looking at allowing redacting some fields in shared requests, so you can share a request without revealing your password or other sensitive information.
- (22:48) Passageway was based on the localtunnel project. It installs an agent on your local machine which forwards requests to a specific port to Runscope, and Runscope then creates a public URL. You can use Passageway to show off code running on your local machine, but you can also use it for debugging webhooks and testing API’s used in a mobile application (by pointing it at the public Runscope URL). Scott says he sees this as being useful in a continuous integration environment, and John says that a current customer is already doing this.
- (27:33) Jon asks about the installation via pip, and John explains how pip relates to other package managers. They plan to provider other installers, and later the agent will do more than just Passageway – right now it also supports automatically creating Runscope urls for requests.
- (29:27) Jon says that Passageway is the first place on the site where he sees something about paid accounts and asks John how they’re going to get rich. John says there are three reasons (access to passageway, team sharing and volume) to upgrade from a free account to a starter or team account. Jon asks about the naming of the starter account, and John says that naming and pricing are really hard. Scott offers some advice on enterprise friendly pricing.
- Starting a business
- (32:47) Jon asks about the experience of moving from being a developer to founding a company. John says he’s started several small companies, and writing software has always been a way to solve problems for businesses. He tells his recent job history at Twilio and IFFT and how he and his co-founder Frank got really fed up with the lack of good API developer tools and how they got started, funded, and launched. Getting funded was both a finish line and a starting line.
- (41:33) Scott and Jon talk about positive response they saw to the GlueCon launch: John spent the majority of the time describing the problem, then unveiled the solution. Scott compares John to Steve Jobs.
- What’s next
- (43:05) Jon asks what’s next. John says they’re first focusing on dev-time troubleshooting. Next they’ll be focused on production use, especially high volume use cases. Long term they’re thinking about mitigating problems – handling or proactively monitoring for problems.
- (45:14) Jon asks about John’s experiences building Runscope in Python and how he compares it to .NET. John says he’s really come around to significant whitespace and standard
- Runscope vs. other network tools like Fiddler and Wireshark
- (49:19) Scott asks why you’d use Runscope rather than use things like Fiddler, Wireshark, etc. John explains proxies and applications modify the way the application works and doesn’t work well on servers – it’s cloud-native. It’s also social – sharing is built in. Thirdly, it’s not a desktop application.
- (52:30) John says he’d like to write a Fiddler plugin to make the two work well together. Scott says that there’s one advantage to desktop applications – it can interact directly with the network stack. John agrees that developers need tools that work at all layers of the stack. Scott recounts a harrowing tale in which Fiddler had to be installed on a server for an application to work.
- (55:20) Jon says he was wondering about integrating with Glimpse but that would require an API – does Runscope have an API? John says one’s on the way soon.
- Lightning Round inspired by John’s Traffic and Weather podcast (with Steve Marx)
- (57:00) Jon says he’s really been enjoying the Traffic and Weather podcast, and the John and Steve have convinced him that API’s really can be interesting.
- (57:50) JSON API – what is it, and is it good?
- (59:34) What are webhooks, and why have you been talking about them?
- (1:01:52) Should we stop writing REST SDK clients?
- (1:04:29) Where is API security going? Is it OAuth 2 from here on out?
- (1:05:21) Eric Williams (@motowilliams) asks "Ping Pong or Foosball? #gooooooaaaaaallll"
- (1:06:17) Where are you speaking next (answer: API Days and API World, both in San Francisco)
- (1:07:32) Do you support the HTTP 418 teapot response?
This week on Herding Code, the guys talk to Glenn Block about scriptcs.
Download / Listen:
Herding Code 167: Glenn Block on scriptcs
- (00:10) K Scott asks Glenn if he’s still working with Node at Microsoft. Glenn says he’s moved from command-line tools for node and is focused on Azure Mobile Services, but he still owns the Node SDK and the Node story for Azure.
- (01:56) K Scott scriptcs is another way to write C# code outside of the IDE as script files. It’s inspired by Glenn’s work with Node.js. It leverages Roslyn, NuGet, and some conventions to simplify scripting, such as automatically pulling in NuGet packages.
- (03:58) K Scott comments on the ability to reference assemblies using the #r directive. Glenn says it’s even easier than that – you can use #r to reference GAC’d assemblies, but assemblies in the local bin folder are automatically referenced. K Scott asks about the hooks to support that, and Glenn explains how Roslyn supports a lot of scenarios; since it ships it as NuGet packages it can be used outside of Visual Studios. Roslyn allows for code to exist outside of a class.
- (06:33) Jon talks about his initial experiences, and how the REPL made it really easy to get started. Glenn explains how that works and explains how, using Chocolatey you can quickly install scriptcs and a NuGet package like MongoDb and then just start writing code in the REPL.
- Dependence on Roslyn
- (09:35) Kevin points out that Roslyn is still in CTP and asks how that impacts scriptcs. Glenn says that since it’s a CTP Roslyn you can’t ship the binaries, but that’s not a problem for scriptcs since it pulls in the public NuGet packages. Roslyn is still evolving, it doesn’t yet support async / await or dynamic, for instance.
- (11:13) scriptcs no longer takes a dependency on Roslyn. It uses a pluggable script executor which can use Roslyn but can potentially also use other script engines.
- Example uses of scriptcs
- (12:33) K Scott asks for some common use cases. Glenn says that it’s possible to build apps because you can have one script that includes other scripts, then talks about the WPF calculator sample in the scriptcs-samples repo.
- (14:18) Glenn says another use he’s seeing is automation – basically as a replacement for PowerShell. He talks about the Fluent Automation sample which uses script-cs to automate Selenium tests.
- (15:18) Glenn talks about a real world example at a large trucking company who is using scriptcs to automate data processing jobs.
- (16:05) Octopus Deploy has added support for scriptcs. He used a loader script that passes configuration to user-written scripts.
- (17:42) Glenn says it’s useful to tinker and play with libraries or services and give an example of interacting with Azure Mobile Services in the REPL.
- (18:38) One other example is extensibility – creating hooks and allowing end users to just drop in a scriptcs script to extend behavior.
- (20:03) Jon says that the PowerShell syntax is different enough that he can’t remember it. He talks about the idea of using scriptcs for installation and initialization scripts in NuGet rather than PowerShell. Glenn says there are kind of ways to use C# with PowerShell, but it’s not the same. He mentions a sample from @beefarino which lets you talk to scriptcs from PowerShell.
- (23:01) Kevin asks what the migration process is to move from scriptcs to a C# project. Glenn says it depends on how much you take advantage of scriptcs features like Script Packs. Script Packs bring a node-like require module syntax into scriptcs. Glenn talks about the Web API script pack which adds in proper usings and gives you an API that’s very easy to use in script, without IntelliSense. They’ve talked about creating a project exporter which could set up a project and bring in your Script Packs, etc.
- (26:25) Kevin asks if the Script Pack / Require experience could be brought into standard C#. Glenn says the general concept could work because it’s just a DLL, although there are some incompatible things like import statements. They’ve looked at writing Script Packs as script, which could make this more useful.
- (28:40) Kevin talks about how the Node module system handles conflicting dependencies and asks if scriptcs handles that. Glenn says not yet, but .NET is now able to handle that so it could be added in. The general idea of script modules depending on other script modules makes sense, but conflicting dependencies might not be very useful. They’re thinking of NuGet packages with no assemblies, just does as content, and talks about some implications.
- (31:32) Jon talks about how Glenn had told him that a lot of his bizarre feature requests wouldn’t fit in the core but could be useful as extensions, then asks about the extensibility points. Glenn runs through what you can do: change the engine, use Script Packs, bring in NuGet packages, possible later REPL extensions via global NuGet packages. He says they’re following the Node team’s principles of keeping a small tight core and pushing features towards extensions.
- Questions from Twitter
- (34:14) Jeff Schumacher (@codereflection) asks Glenn to compare scriptcs performance vs. compiled code. Glenn says that there can be a short startup impact and potentiall
- (35:58) Akim Boyko (@AkimBoyko) asks if it’s possible to run scriptcs without Roslyn, async/await support and in sandbox mode. Glenn talks about the Mono impact of running without requiring Roslyn support. Roslyn will be getting async/await support at some point, but it could also be added via CodeDom if people implement that. However, CodeDom doesn’t support the classless system that Roslyn does.
- (38:04) Simon Cropp (@SimonCropp) asks if scriptcs support plugging into the build pipeline? Eg if I wanted to plug in Fody (https://github.com/Fody/Fody/).
- (39:41) Several questions on how scriptcs compares to Snippet Compiler, LinqPad and csscript.
- (41:12) Dan Vanderboom (@danvanderboom) asks if scriptcs let us run a .cs code file by itself anywhere in the file system? Glenn says no and explains why he’s not sure that would be useful.
- (42:55) Tomasz Janczuk (@tjanczuk) asks When will integration of scriptcs and edgejs be done? ;) Glenn talks about how the projects have both grown up together and how the two would be useful together.
- Debugging and IntelliSense
- (45:29) Jon talks about how he messed something up in the samples and debugged it and asks about debugging support. Glenn points out that you can directly debug an EXE in Visual Studio and explains how to debug scriptcs code in Visual Studio. He also talks about MDbg which Glenn (and apparently everyone else) didn’t know existed. He also mentions a Script Pack for debugging.
- (48:15) Jon says the REPL is great, and yet he’d sometimes like IntelliSense. Glenn talks about a lightweight WPF editor that’s in progress, but says if you get to a point where things are getting complex it’s probably time to move to move from scriptcs to a project. Jon says that for the most part Script Packs seem to really simplify the code to the point where you don’t really need IntelliSense, and Glenn agrees.
- (50:45) Glenn calls out the two other coordinators on the project, Filip Wojcieszyn (@filip_woj) and Justin Rusbatch (@jrusbatch) as well as some other top contributors.
- Shell capabilities, TSR scenarios
- (52:03) Kevin asks if there are possible changes to make it more shell-like with things like piping. Glenn says they currently have a poor story for arguments, but it’s coming. You can currently pipe text, but he’s not sure about piping objects.
- (54:30) Jon says he’s got some AutoHotKey scripts and asks if scriptcs could handle that kind of thing.
- Future plans
- (56:10) K Scott asks where things are going in the future. Glenn mentions scriptcs modules, aliases, a better Visual Studio experience, export project, and saving DLLs.
- (1:04:25) Glenn talks about some interesting ideas on GitHub, like a command to break execution into the REPL. They’ve got 20 active contributors, so things are moving fast.
- (59:54) Glenn says he’s got a personal interest in seeing some adoption in Microsoft – such as adding scriptcs scripting to other projects.
- (1:00:25) Glenn talks about one question that comes up: should the Roslyn team have tackled the scriptcs scenario?
- Wrap up
- (1:01:10) K Scott asks about Glenn’s upcoming plans, speaking engagements, etc.
- (1:02:27) Jon makes a last minute sales pitch to try it out – you can install in seconds from Chocolatey and just start playing at the REPL. Glenn points one gotcha – scripts which run servers need to be run as admin.
This week on Herding Code, the guys talk to Tomasz Janczuk about running .NET code in Node.js using Edge.js.
Download / Listen:
Herding Code 166: Tomasz Janczuk on Edge.js
- Intro and background on Edge.js
- (00:40) Tomasz has been focusing on Node.js at Microsoft for the past 3 years. He’s been working on making Node.js run well on Windows. He’s also worked on hosting Node.js on Windows Azure with IISNode.
- (02:08) Jon asks about Edge.js’s original name, Owin. Tomasz explains how that made sense with the original scope – connect middleware and express handlers – but it’s grown since then so it needed a more generic name.
- (02:45) Edge.js lets you run Node.js and .NET code in one process and provides interop mechanisms between the two.
- (03:05) Jon asks why that’s useful. Tomasz says you can do pretty much anything in either Node.js or .NET, but some things work a lot better on one platform. He gives examples like using ADO.NET to connect to SQL Server and running CPU bound computations as multi-threaded .NET code from the single-threaded Node.js event loop. There are two classes of scenarios: things that work better on one platform, or writing native extensions to Node.js without having to drop all the way down to raw C and native OS mechanisms.
- (06:11) Jon brings up two questions from Twitter about Mono support (Jason Denizac @_jden "when’s mono support coming?" and Kevin Swiber "Mono support? Can we do legit Node modules in C#? Are grilled hotdogs really better than boiled?" Tomasz says not yet, but it’s high on the list. There are some complications to implement that support since Edge.js uses C++ CLI, which isn’t available on Mono.
- Getting started and samples
- (07:57) Jon asks what’s involved in setting it up. He says he ran npm install edge, then npm install edge-cs. Tomasz explains why he didn’t need to install edge-cs – C# support is built in, other language support plugs in.
- (08:43) Jon asks about the samples. Tomasz explains the different ways of integrating CLR code into Node.js and talks about how the samples show these approaches.
- (10:36) Jon says he liked how the samples progressed from very basic to pretty complex. Tomasz says you can do just about anything in Edge.js, but there’s a specific interface you need to follow in order to work smoothly between the Node.js async model and many synchronous operations in .NET. Every function in Edge.js uses an async function delegate, so you end up using small wrapper functions in some cases.
- Marshalling and interop
- (13:08) Kevin says this reminds him of COM / .NET interop and issues with object lifetime, garbage collection, etc. Tomasz says that that the async function delegate solves the threading models. Object lifetimes are controlled because everything is marshalled by value.
- (16:22) Kevin asks if the marshal by value prevents working directly with the CLR object. Tomasz says that you can handle this using function proxies to create closures over CLR states.
- (21:25) Jon says he thinks this sounds useful for using a NuGet package in a Node.js application and asks if there’s support for pulling in a NuGet package. Tomasz says that at this point it’s up to you how you’d get the assembly downloaded and set up, but that there’s an open issue to get script-cs integration going and that would handle this.
- Overhead and performance
- (23:06) Jon asks about the overhead of running two virtual machines and marshalling. Tomasz says there is some overhead, but it’s better than running two different processes. Edge.js is built for solving some specific scenarios, and it’s fast in those
- (24:55) Kevin asks if there’s a delay when Edge.js spins up. Tomasz says that happens when you require Edge, but it’s not really noticeable.
- Misc questions
- (25:55) Jon asks what was the hardest part of implementing Edge.js. Tomasz says the function proxies to handle lifetimes and reconciling threading models.
- (27:45) Scott says this sounds useful for authentication or using a legacy .NET library. Tomasz lists several more.
- (29:20) Kevin asks how exceptions are handled. Tomasz explains how the exceptions are marshalled and thrown across VM boundaries.
- (30:15) Kevin asks if it’s tied to specific Node.js versions. Tomasz says it works on all current stable versions.
- (31:30) Question from Twitter: @jeremydmiller "I’ve seen a lot of samples of hosting . Net in node, but how about running node in a .net process?" Tomasz talks about an open issue, Mission Double Edge which would handle that. He explains that the challenge is that Node.js doesn’t have a hosting model.
- (33:20) Jon says he saw several of the samples had the C# script named with .CSX extension and asks about that. Tomasz says that this is partly done to follow Roslyn conventions, including specifying assemblies as references in code using #r.
- Future plans and next steps for listeners
- (34:25) Jon asks what’s planned going forward. Tomasz talks about Mono support and adding support for additional languages, including F# (note: this has been added http://tjanczuk.github.io/edge/#/3) . Jon asks what’s involved in adding language support.
- (36:30) Jon asks about the relationship with OWIN. Tomasz says there’s a separate module which allows you to plug any OWIN compatible .NET application and plug it into an Express.js pipeline. Jon says this reminds him of the Edge name and Tomasz explains that the idea is that mathematically an edge connects two nodes, so Edge.js connects differe.
- (38:25) Jon asks about next steps for people to get started.
- (38:55) Jon asks if this is a Microsoft project. Tomasz says it’s his own separate open source project that’s inspired by his day job, and this allows him some more flexibility to work with the community. He lists some of the community contributions they’ve seen so far.
While at the Danish Developer Conference in Copenhagen, Jon sat down with Mark Seemann to talk about AutoFixture and Unit Testing.
Download / Listen:
Herding Code 165: Mark Seemann on AutoFixture and Unit Testing
- (00:44) AutoFixture is an open source library that simplifies the "Arrange" part of the standard Arrange / Act / Assert steps in unit tests.
- (01:20) Jon asks about anonymous variables. Mark says he got that terminology from Gerard Meszaros’ book, xUnit Test Patterns. Anonymous methods and variables are necessary for a test, but their implementation doesn’t matter.
- (02:23) Mark describes the test data builder pattern, from the book Growing Object-Oriented Software. The pattern works well, but it gets to be repetitive and mechanical to write and maintain, so he wanted to automate it. AutoFixture uses reflection to create the needed instances.
- (04:00) Jon asks about the usage pattern for AutoFixture.(04:16) Jon asks about the different values returned for strings, ints, etc. Mark explains how that’s changed over time – numbers no longer just return sequential values, they now return random small numbers.
- (05:20) Mark explains equivalence classes. Jon says "Okay" a lot. You can use AutoFixture in cases where you don’t care about the value; in cases where you do, you can configure what you want to. Mark explains some of the different ways you can use the AutoFixture API to set specific values when needed.
- (09:15) Jon asks how AutoFixture works with mocking. Mark says there are NuGet packages which will interface with Moq, Rhino Mocks, FakeItEasy and NSubstitute.
- (10:25) Jon asks Mark what his talk said about equivalence. Mark explains identity and value objects with an example with overriding the equals operator on a money value object. The more you can model your domain as value objects, the easier your tests become. Jon asks if this is an example of TDD driving a good design. Mark says that he tried letting tests completely drive his design a few years ago, but he found that it alone didn’t drive a very good overall design.
- Testing philosophy, Testing Trivial Methods
- (15:56) Jon asks Mark about his recent post advocating testing trivial methods. Mark says that his post was in response to Robert C. Martin’s post, The Pragmatics of TDD. Mark makes a case for testing getters and setters – if you decide to use a property rather than a field, that decision probably warrants a test to verify the property is maintaining the behavior that drove the original decision.
- (20:38) Jon asks how this applies to the example of testing ASP.NET MVC controller code. Mark says he’s in the habit of testing everything, and has written a lot of tools to make writing the tests easy enough that it’s not a concern. The question is, how much does it cost you if a unit of code doesn’t function as designed? Mark explains how a controller action models the data flow in an MVC application, and decomposing the flow allows you to write smaller, simpler, more targeted tests.
- (25:03) Jon asks how this relates to outside-in testing using tools like Selenium. Mark says that testing at the external boundary is fine if you can, but most applications become complex enough that boundary testing would require an impractical number of test cases.
- Wrap up
- (26:04) Mark says that many of these concepts are covered in more detail in Mark’s Pluralsight course.
This week on Herding Code, the guys talk to Louis DeJardin about OWIN – the Open Web Interface for .NET – and Katana, an open source OWIN implementation for ASP.NET and IIS.
Download / Listen:
Herding Code 164: OWIN and Katana with Louis DeJardin
- (00:44) Scott and Louis explain what OWIN is.
- (01:33) Louis explains the difference between OWIN (the community standard) and Katana (actual bits – an implementation of the OWIN standard for ASP.NET).
- (03:18) Jon asks if this is similar to the distinction between HTTP / HTML standards and browser implementations. Louis explains what’s required for an implementer to participate in a request. Each request calls a simple func with an IDictionary<string> which returns a task.
- The killer app: middleware
- (04:54) Scott talks about how the pipeline might not sound like much, but it can support a lot of really useful middleware scenarios like static caching and domain splitting – especially in a way that’s common across frameworks.
- (06:05) Louis talks about the challenge they’ve had in describing the benefit of OWIN in non-academic terms, and that it’s not until you want to apply cross-framework concerns like authentication that OWIN really shines.
- (07:52) Scott says that previously these kinds of concerns – logging, etc. – were wrapped up in System.Web, and they had performance implications regardless of whether you used them. The pipeline model lets you avoid those hits unless you explicitly want the features.
- (10:03) Scott mentions some of the frameworks which have implemented OWIN, including NancyFx, Fubu, ServiceStack.
- (10:50) Kevin says that the current implementation examples are full web frameworks rather than middleware. Louis says that probably because ASP.NET and IIS already had pipeline implementations so there’s less of a forcing function than there was with Node and Ruby. Scott says that since the current implementations already have full stacks, there’s less need to plug in modular solutions. Jon says he thinks that the late arrival of NuGet and other open modular systems like this mean it’ll take a while to get traction.
- (14:40) Louis says we’ll need a killer app, and HttpListener hosting alone isn’t that. Jon asks if you’d host Katana under IIS to manage the process. Louis says yes, and until there are other hosts than IIS he doesn’t see the hosting as a big draw – he thinks auth is probably it.
- 1640 Scott says he could see auth frameworks and scaling middleware. Louis says that David Fowler updated JabbR to run on OWIN, and was able to move some of the scale pieces into OWIN middleware.
- (18:25) Jon asks if he can take an existing ASP.NET application to start taking advantage of middleware without rewriting the application. Louis says that if you add the Microsoft.Owin.Host.SystemWeb NuGet package, you can put an OWIN pipeline on the route table. You can also use an IHttpHandler to plug in middleware. They’re looking at third option – an integrated pipeline module which will delegate to the application if an OWIN handler doesn’t pick it up.
- (22:22) Jon asks Louis has some other ideas for middleware, and Louis lists several (static file handlers, authentication, etc.) and points to Rack and Node as examples. He lists another example – anti-bot protection that returns an HTTP 200 for a URL pattern.
- (23:50) Jon asks if it’s possible to plug things in at runtime. Louis talks about the Startup class – it’s a POCO class so you can easily work with it via IoC, plug things in whenever – it’s just code.
- (25:05) Scott says he looked at implementing URL rewriting in middleware. Louis explains how this works perfectly with the pipeline and describes how you could also use this to monitor 404s.
- (26:45) Scott says hosters could implement middleware to set ETAGS, enforce things, etc.
- (27:40) Louis explains why it’s really powerful to have middleware that’s not coupled to a specific implementation like ASP.NET MVC.
- (28:35) Jon asks if it’s possible that some of this middleware could run on hardware. Louis says it is, and gives an example with a reverse proxy.
- (29:57) Scott talks about breaking middleware into application and networking uses and talks of some optimizations that could be done in middleware.
- (31:48) Scott asks where we go from here – are done? What’s the next goal? Louis says the current 1.0 version of Katana has IIS hosting; the 1.1 version will add production grade HttpListener and self host story, and after that it’s about supporting emerging standards and looking for synergies. Louis says documentation would be nice, but Scott says that the model is so simple that there’s not a lot to document.
- (34:50) Scott and Louis talk about how this will affect the ecosystem in general, with an example of how smoothly the SignalR implementation worked.
- (35:25) Jon asks about the future for hosters like Azure, AppHarbor, etc. Louis talks about an example for supporting zip file based deployment, Mono hosting.
- Getting involved
- (37:05) Louis talks about what’s available in the Katana Project, including sample code and pre-release packages. The Google Group – net-http-abstractions – is the best place to discus OWIN.
- (38:15) Jon asks if the Katana project takes pull requests. Louis says it’s run under the MS Open Tech organization and is clear to take pull requests from developers who have signed a contributor license agreement. Jon asks for areas where they’d like help. Scott says he’d like to see lots of middleware; Louis he’d love to see an OWIN Contrib project emerge.
- Questions from Twitter
- (41:05) Sean Massa (@endangeredmassa): Is it possible to use the DLR?
- (41:45) Eric Hexter (@ehexter): what do MVC and Web Forms look like on OWIN. Louis says there are two exciting things there – you can have an Owin pipeline running in front of your application, or you can use self hosting to put an application inside of your own process (not supported but fun!).