While at NDC, Jon talks to James Mickens about his terrifying computer security keynote presentation.
TLDR you are doomed.
Download / Listen: Herding Code 211: James Mickens on The State of Computer Security and Bitcoin and Thomas Jefferson and Internet of Terrible Things and Prawns Oslo’s Terrible Secret
- (00:24) All is lost. Listen to Danzig.
- Stop putting your money in Bitcoin
- (01:00) James says it’s not a good place to put all your money unless you want to be poor.
- (01:42) Bitcoin is a commodity, not a currency. Investing in commodities is hard. It’s not a stable place to put money. When it’s going up, the smart people are taking money out.
- The legal system – and specifically Thomas Jefferson – won’t help you
- (03:56) Judges and lawyers are very far removed from modern technology. Analogies to older forms of communications doesn’t work.
- (04:44) Emojis are not telegrams. They’re incredibly terrible, though.
- (06:30) Thomas Jefferson wouldn’t help with issues relating to iPhones. If your phone broke, would you take it to a really old person for help? Because Thomas Jefferson is a really, really old person.
- The Internet of Terror
- (08:10) The internet of things is the new cool buzzword, but nobody wants to reboot their house.
- (09:17) The security story for the internet of things world is cartoonish. When your refrigerator starts sending spam, James will laugh at you.
- (11:52) The first several generations of IoT houses will be terrible. Things will get better on a relative scale, but will always be terrible on an absolute scale.
- (13:32) James knows he’s in danger for dissing Node.js, but he can’t help himself.
- (16:10) Oslo is a wonderful city. It never gets dark, which makes you feel safe but if James was a criminal he would be all over the extended working hours.
- (16:54) Shrimps are prawns, and unlike American shrimp they have legs and heads.
- (18:06) French fries cost approximately one mortgage payment.
- (19:42) James speculates on whether Oslo harbors some terrible secret. The condos look like lairs for James Bond villains.
- (21:11) Jon saw a building with a big sign that said Edderkoppen, which he had recently learned means The Spider. Perhaps that is Oslo’s terrible secret?
While at NDC Oslo, K Scott and Jon talked to Ian Cooper about Microservices and using the Brighter library for Command Dispatcher / Command Processor patterns.
Download / Listen: Herding Code 210: Ian Cooper on Microservices and the Brighter library
- Why Microservices?
- (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.
- Zookeeper or Consul for service registration and discovery.
- (8:28) Scott Allen and Ian talk about how Microservices take forward SOA principles such as autonomous services, not sharing types and stable interfaces.
- (9:00) Scott Allen asks what options for communications between the services are and Ian compares HTTP, Sockets and message queues like RabbitMQ.
- Ian’s Brighter .NET lightweight Microservices project
- (10:20) Basic two parts of Brighter are:
- Command Dispatcher/Processor – Maps a command to a processor with a pipeline where you can insert orthogonal operations like logging and monitoring
- Task Queue – Allows some commands will be handled asynchronously elsewhere
- Very simple for the developer – just write a command and a handler.
- Easy to embed in your existing Windows service if using something like Topshelf.
- Provides timeouts, retries and a circuit breaker inspired by Netflix’s Hystrix in a declarative manner.
- (12:45) Scott Allen clarifies how easy it is to get two services talking to each other using this via RabbitMQ.
- (13:00) Ian talks about future support for Azure Service Bus and the possibility of producing one for Redis – RabbitMQ and Amazon SQS are already supported.
- (13:30) Scott Allen asks if this is used in production and Ian explains how Huddle started with using RX on the server and had difficulties managing subscriptions.
- (14:20) Brighter is on ThoughtWorks Technology Radar and evangelized by ex-Huddlers at their new roles.
- (14:40) Ian talks about the importance of good documentation and welcomes feedback on theirs.
- (15:10) Ian mentions they facilitate hexagonal architecture.
- Scott Allen asks if you can use in-process and Ian explains the subtleties
- (16:00) Ian’s time is sucked up by being a a new dad, congratulations!
- (16:30) The one job of a parent is keeping children alive.
- (16:40) Thank-you and goodbye.
These show notes were contributed by Damien Guard. Thanks!
While at NDC Oslo, Jon talked to Robert Friberg about in-memory databases in general. They discussed OrigoDB, Robert’s open source in-memory database, as well as Redis and SQL Server Hekaton.
Download / Listen: Herding Code 209: Robert Friberg on In-memory Databases and OrigoDB
- (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.
- Business Model
- (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.
- Case Study
- (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.
While at NDC Oslo, K Scott and Jon talked to Chris Klug about pragmatically applying SOLID principles and on moving from Silverlight to HTML5.
Download / Listen: Herding Code 208: Chris Klug on SOLID principles and migrating from Silverlight to Angular and TypeScript
- Hello There
- (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.
Download / Listen: Herding Code 207: Damian Edwards on ASP.NET 5, DNX everywhere, and experimental servers on Windows
- (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.
While at NDC Oslo, K Scott and Jon talked to Rachel about accessibility (web and otherwise) and testing.
Download / Listen: Herding Code 206: Rachel Appel on Accessibility and Unit Testing
- (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.