Herding Code 190: Rob Ashton on NodeJS vs C#, Clojure and Cooking Constraints

In our final interview from NDC London, Jon and K. Scott talk to Rob Ashton his cage match with Jeremy Miller on NodeJS vs. C#, some functional languages he’s been learning, and cooking just enough curry.

Download / Listen: Herding Code 190: Rob Ashton on NodeJS vs C#, Clojure and Cooking Constraints

Show Notes:

  • The NDC Cage Match: Testing! NodeJS vs. C#
    • (00:18) K Scott asks Rob about the cage match he just had with Jeremy Miller comparing testing in NodeJS and C#. Rob’s got a lot of good things to say about what Jeremy showed, but is pretty sure he won.
    • (02:40) K Scott asks Rob to explain why he doesn’t like monkey patching. Rob mentions how QuickCheck helps, then talks about how code structure obviates the need for monkey patching.
    • (05:16) Jon asks how he bootstraps his application to inject dependencies and explains how he avoids deep dependency chains.
  • Clojure?
    • (06:40) K Scott asks what led him to Clojure.
    • (07:39) Jon asks Rob what he likes about Clojure. Rob says a better question is what he likes about functional programming languagues, then explains.
    • (09:25) K Scott asks about some of the learning project Rob’s been working with to learn Clojure. Rob talks about some of the games he started with, then the RavenDb reimplementation he’s been building with Clojure called Craven.
  • What do you do in your free time?
    • (12:56) K Scott asks Rob what he does in his free time. Rob starts by talking about Clojure, then talks about some of the complicated cooking things he’s been working on. He talks about some of the similarities between cooking and coding, and some of the constraint he deals with in ambitions cooking projects.
  • The future
    • (14:58) K Scott asks Rob about some of his plans for early 2014.  Erlang away!

Show Links:

Herding Code 189: Gary Bernhardt on The Birth and Death of JavaScript

At NDC London, Jon and K Scott talk to Gary Bernhardt about his talk, The Birth and Death of JavaScript.

Download / Listen: Herding Code 189: Gary Bernhardt on The Birth and Death of JavaScript

Show Notes:

  • (00:15) The talk occurs in the year 2035. JavaScript is now pronounced differently, and there has been another world war.
  • (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.
  • (04:10) Jon asks why JavaScript has died, since Asm is universal. Gary mentions some of the problems – many historical – with JavaScript. And Gary should know, he’s famous for the "wat" talk showing several JavaScript insanities.
  • (05:37) Jon asks for some reasons why JavaScript had to die. Gary explains how it’s really just running on inertia now, and that it’d be preferable to use a better designed language like Clojure.
  • (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.
  • (07:45) Jon asks if Asm is a binary format. Gary clarifies that it’s the JavaScript subset that was proposed in 2012.
  • (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.

Show Links:

Modern Javascript Development:The arguments object, overloads and optional parameters

Reassign JavaScript Function Parameters In Reverse Order, Or Lose Your Params – In which Derek discovers that arguments object is a data structure with an identity crisis. ;)

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.

Modern Javascript Development: constructors and objects

The premise that someone would pass in b and c but not a is also weird. But, whatever. It does cause a problem due to the weird nature of the arguments object The big gotcha here is that JavaScript doesn’t support overloads.

In most languages that do support overloads, you would just define two different functions. One that takes three arguments and one that takes two arguments. But that won’t work since JavaScript is interpreted top-down. The last function definition clobbers the previous definition. So in the Fiddle posted above, the two argument function is the only one that exists.

Derek is correct that the arguments object is funky. It’s an array, but not really an array. It only has a “length” property. But it doesn’t have any really useful methods like pop or push. So assigning the variables in reverse order does work, for the reason you would expect knowing that JavaScript is interpreted top-down. I think a better way would be to convert the arguments objec to a REAL LIVE BOY ARRAY and access the values from that.

It has the same effect, but in my opinion it’s a little easier to understand.

Agile is dead? What’s next?

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!”

Herding Code 188: Pete Smith on Superscribe

At NDC London, Jon talks to Pete Smith about Superscribe, a library which brings graph based routing to ASP.NET, Web API and OWIN.

Download / Listen: Herding Code 188: Pete Smith on Superscribe

Note: There’s a little bit of background noise due to the conference recording.

Show Notes:

  • 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.
    • (02:17) Pete explains that graph based routing is language agnostic, so there’s also a JavaScript implementation.
  • 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.
    • (20:12) Jon asks about the use case for Superscript in JavaScript. Pete talks about how activation functions are really useful in single page applications and how he’s using this in a production application. He’s working on packaging this up as Superscribe.js.
  • 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.

Show Links: