Personal Software Development Practices

  • Don’t fear the code. It’s just code.
  • Never write (or copy) a line of code that you don’t fully understand.
  • Figure out how things really work and why they work they way they do.
  • If you don’t understand something, go deeper. Read the source code for the library you’re using.
  • Use tools to figure out how things work–debugger, unit tests, sample programs.
  • Create a punchlist to guide your work–investigations, things to do, things to test
  • Test the hell out of your code. Be as thorough as possible
  • When you get stuck, go for a 5 minute walk.
  • When you get stuck, describe your stuckness out loud to somebody else.
  • Write down what you’ve learned. Create a FAQ document and answer all the questions.
  • Try to teach someone else what you’ve learned. Create a blog.
  • Leave breadcrumbs for yourself and others–personal notes or comments in the code.

That Conference 2018 – An Extended Explanation of Caching

That Conference 2018, Kalahari Resort, Lake Delton, WI
An Extended Explanation of Caching – Tom Cudd

Day 3, 8 Aug 2018  2:30 PM

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2018 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Executive Summary

  • A number of places where you can do caching
  • Various tools for various places
  • Really all about 1) populating, 2) invalidating

Caching examples

  • Network tab in browser, pages from memory or disk cache
  • Content from CDN
  • Special applications – e..g. Varnish
  • WordPress plugin – specify cache settings for blog

Caching is Like Regex

  • If you’re not careful, you’re going to have new problems

Application Architecture

  • “Christmas tree” showing server, cache servers, CDN, load balancers, etc.


  • Caching solves one problem–performance
  • 3-sec rule: user leaves if something takes longer than 3 secs
    • 40% of users leave

Another reason

  • Buy some time
    • e.g. before application crashes
  • Cost-benefit analysis–caching costs vs downtime

Measure First

  • User metrics
  • Load times
  • Site no crashing every 5 minutes
  • S.M.A.R.T. Goals – specific measurable achievable relevant time-bound

How to Not Suck at Caching

  • Caching is additive
    • Can’t just throw caching onto server that’s already overloaded
  • Don’t over-engineer
    • Use the simplest solution that satisfies the requirements
  • Measure, change, test, measure

Caching Doesn’t Help

  • Oversaturation
    • Network hardware
    • Thread death–“virus”, creating multiple threads for each request
  • Thundering herd
    • If you get large number of initial requests, a large number of them go all the way back to server, since it takes a little time to cache the data
  • Lack of information
  • Bad decisions

End Users

Browser Caching

  • Setting request headers–page tells browser to cache a page
  • Requires a hit to operating system
  • Unique naming
    • Rename an assets to force download of long cached object

Set with Web Server

  • E.g. est cache-control for certain pages

External/Edge Services

  • CDN – Content Delivery Network
    • Point your URI to 3rd party server
    • They then pull files, as needed, from your server
  • Most big sites on the web run on CDN
  • Improve page load time
    • Serve request from server that has shortest travel time to client
  • High availability
    • Cached data could still be present even when your origin server hiccups
  • Can maybe buy CDN servies at lower cost than scaling out actual servers

CDN Features

  • Setting TTLs, other configs based on extension
  • Region, language routing
  • Mobile detection
  • WAF/Security
    • Applications can do double duty–firewall + CDN
    • DDOS protection

CDN Providers

  • Cloudflare
  • Incapsula
  • Cloud providers
  • Akamai
  • Fastly


  • Match file extensions
  • Honoe cache control of origin
  • Can have configs for some stuff on your server

Measure and Test

Your Systems

  • Don’t over-engineer–get strange results
  • Spin up different instance if you need different purpose


  • Separate servers
  • Both memory and disk paging

Web/App Layer

  • Baked vs fried
    • Building on demand vs preloading cache
    • Cache gen’d on demand when request hits (fries)
    • Preload cache ahead of time (baked)
  • Disk vs memory


  • Adobe Experience Manager
  • Sitecore
    • Prefetch, data, item, html caches
  • Drupal
    • Performance caching (SQL queries stored)

Output Caching

  • IIS- – generate on request

App/Data Layer

  • Reducing database calls
  • Reducing API calls


  • Java based applications
  • Memory or disk


  • In memory, key/value store
  • Reduce database load
  • Not synchronized
  • Scalable separately

Let’s Not Fight

  • Not worth arguing about which is better
  • Memcached, Redis, Mongo
  • All are good


  • Redis
  • Firebase
  • Stored procedures – reduce network bandwith by calling short sproc rather than sending long query


  • Invalidating stale data

Caching Procedures

  • Only two things you’ll really need to do with caching
    • Populating
    • Invalidating

Debugging, need to remind people to clear their cache

  • [Sean] But should users have to worry about this? If you need to have them clear cache, then something’s not working properly

Populating Caches

  • Pull based – cache tool pulls from your server
  • Push based – your code has to push out data to the cache

Cache clearing

  • Staggered approaches
  • Clearing individual items
  • Using APIs and automation


That Conference 2018 – Securing Your ASP.NET Core Applications

That Conference 2018, Kalahari Resort, Lake Delton, WI
Securing Your ASP.NET Core Applications – Cecil Phillip

Day 3, 8 Aug 2018  1:00 PM

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2018 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Executive Summary

  • Quick review of authentication pipeline
  • Various options for authentication

ASP.NET Core 2

  • Cross platform web framework
  • Targets .NET Standard 2.0
  • Introduces Razor Pages
  • SignalR Core available
  • ASP.NET Core 2.1 out now

Middleware Pipeline

  • diagram

Application Startup

  • Startup.cs
  • Configure takes IApplicationBuilder, IHostingEnvironment
  • app.UserXyz, app.UsePdq
  • The order of middleware matters


  • In VStudio, two servers
    • IIS Express
      • Enable SSL in properties
    • Kestrel – cross-platform
      • Have to use .NET CLI tool
      • dotnet dev-certs https –trust
      • Generates self-signed cert that’s automatically trusted
      • This cert doesn’t appear in cert manager
      • MMC – add snap-in, Certificates snap-in, My user account
      • Now looking at certs for the current user only
      • Now you see the dev cert that we just created
  • When you run, you fire up 2 endpoints–HTTP, HTTPS–that it’s listening too
  • Remove cert
    • dotnet dev-certs https –clean
  • Do not use this dev cert in production
    • Only for local development


  • Many options, i.e. middleware
    • Cookies
    • Twitter
    • Google
    • JWT Tokens
    • Facebook
    • OpenID Connect
    • Microsoft Accounts
    • Custom
    • Windows

Cookie Authentication Demo

  • In ConfigureServices, services.AddAuthentication
  • .AddCookie
  • In Configure, do app.UseAuthentication
    • Need to do this before UseMvcWithDefaultRoute
  • Mvc is a “terminating middleware”–stuff after it won’t run
  • Controller code
    • Login action, with LoginViewModel
    • Create ClaimsIdentity with a Claim
    • Pass in to HttpContext.SignInAsync
  • Back in ConfigureServices
    • .AddCookie takes opts with authentication events
    • We can handle various events as part of pipeline
      • Kick out existing logged in user

Twitter Authentication Demo

  • .AddAuthentication, AddCookie, AddTwitter (pass in client ID and secret)
  • Still just do app.UseAuthentication in Configure


  • Manage user secrets
  • Lives in app profile
  • JSON data with different secrets, e.g. Twitter-ClientSecret
  • (or) dotnet user-secrets
  • Roaming, so it will synch across profiles
  • BuildWebHost doesn’t do anything special to get secrets info
  • Configuration passed in to Startup (DI)
    • You can just ask it for secret, with [“xxx”]
  • In production
    • In Azure, have Azure key Vault
    • Can also create certificates
    • In application, you can specify Azure Key Value as a source of configuration
    • builder.AddAzureKeyValue (off .ConfigureAppConfiguration, in BuildWebHost
    • Register your app with Azure Key Vault–and perms, what can you do
    • Also supports versioning of secrets
  • What to put in Azure Key Vault
    • URL of SQL Server, web server URI
    • Connection strings
    • Secrets
  • You need secret to talk to key vault??
    • Yes, ID/Secret, hard-coded
    • OR create cert, associate with app in Azure App Services
  • You “compose” configuration
    • Settings come from various places

ASP.NET Identity

  • User management framework
  • Get bunch of stuff out of the box
  • Register
    • E-mail, password, Register button
  • Identity using EF, which uses migrations to ensure database is what you expect
  • You get Manage User feature
  • Authenticator app support
    • Little app on your phone to do 2-factor
  • Associate Google Authenticator app on phone to your application
  • Scan QR code with your phone, get #, enter that number
  • Also gives you recovery codes, for account recovery
    • You use one at a time and that code becomes invalid

Azure AD B2C

  • Create tenant, then go to that tenant
  • Register applications for that tenant
  • Identify providers
  • Can see users
  • Add to application (AD B2C)
    • New Project, Change Authentication
    • Individual user accounts – ASP.NET Identify
    • Individual user accounts, Connet to existing user store in the cloud
    • Add info for AD B2C, get domain name
    • Enter application ID
    • Reply URL–can default to localhost
    • Sign-up or Sign-in Policy–create one in Azure, give it name
      • Can have one or more policies for your application
      • E.g. E-mail sign-up
      • Application claims (in policy)
  • Run application that uses AD B2C
  • Login / signup, you go out to AD B2C page on Azure
    • E-mail verification code
    • Additional metadata fields, e.g. Job Title
  • User profiles in Azure, after they sign up

In code

  • User.Identities.First().Claims — a bunch of key/val pairs


That Conference 2018 – Tips & Tricks for a Successful Android Application

That Conference 2018, Kalahari Resort, Lake Delton, WI
Tips & Tricks for a Successful Android Application – Jorge Coca

Day 3, 8 Aug 2018  10:30 AM

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2018 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Executive Summary

  • History of Android
  • Some cross-platform options (code sharing)
  • Some specific notes on Kotlin



  • App being used


Android was originally an OS for cameras

  • Not for smartphones
  • Google acquired Android to do a smartphone



  • Cupcake, Donut – Apr 2009
    • Linux kernel
    • Java, Eclipse ADT
    • Main widgets & SDK components
    • Gesture framework
  • Eclair, Oct 2009
    • Multi account
    • Bluetooth
    • Multitouch
  • Froyo, May 2010
    • Chrome (engine for web views)
    • Push notifications
    • Flash, GIFs
    • Improved market
  • Gingerbread, Dec 2010
    • NFC
    • Improved UI
    • Support for front camera
    • Nexus One
  • Honeycomb, Feb 2011
    • Big milestone
    • Optimized for tablet support
    • Holo interface
    • Welcome Fragments  (nobody likes them)
  • Ice Cream Sandwich, Oct 2011
    • Holo for phones
    • Major update of the OS
    • Editor’s choice
  • Jelly Bean, Jun 2012
    • Performance
    • Support library
    • Dev focus on quality (tools)
  • KitKat, Oct 2013
    • Refreshed interface
    • Android Wear
    • Nexus 5
    • Android Studio
    • Gradle – build tool
  • Lollipop, Nov 2014
    • Material Design – layers of paper
    • Dalvik
    • WebView distributed over PlayStore
    • Dev focus on performance
    • Android One
  • Marshmallow, Oct 2015
    • Android for Work
    • Doze
    • Fingerprint
    • Runtime permissions
    • Batter optimizations
  • Nougat, Aug 2016
    • Android beta
    • Daydream – VR
    • Multiwindow support
    • Picture in picture
  • Oreo, Aug 2017
    • Kotlin
    • Architecture components
    • Focus on modular architectures
    • Adaptive icons
    • Android Go (evolution of Android One)


Market Share

  • 2015, Android nearly 80% of smartphone market


Challenges (in order to be successful)

  • Clear goals and expectation
  • Invest your time and energy where it matters
  • Build for everyone – i.e. international
  • Crowded market. Be original
  • Be the first.. or be the best


Goals and expectations

  • Research your market
  • Measurable goals
  • Realistic exxpectations
  • Indie vs. small shop vs. corporation
  • Functionality vs design.. (or both)


Invest your time and energy where it matters

  • There’s cloud
  • And devices–iOS, Android
  • Don’t do the same work multiple times, i.e. across multiple devices
  • Cloud is the common layer–use it
  • Dedicate efforts to the main use case of your app
  • What can you share between iOS and Android?


Cross platform

  • Easiest: WebView
    • Security hole
  • WebView with native bridge: custom, Ionic, ..
  • Xamarin
    • Business logic in shared library, shared across devices
    • Xamarin works
  • Kotlin Multiplatform
    • Similar to Xamarin–business logic written just once
  • ReactNative
    • Widgets
  • Flutter


Android native

  • Stop using Eclipse
    • Android Studio has better tools, better effort
  • Stop using Java



  • Better develop experience
  • Interop with existing Java
  • Null safety
  • Google working on “Kotlifying” APIs
  • Easer to do more complex things
  • Don’t force unwrap (ignore null check)
  • Default parameter values–no need for factory constructors
  • Sealed classes to express more complex enums


Kotlin Tips

  • Data classes are your friends
  • Easy singletons with object
  • Synthetic extensions to avoid boilerplate



  • The smaller your Activities are, the better
  • The smaller your Fragments are, the better
  • The smaller your Services, the better
  • Remove business logic from SDK components
  • Only use libraries that make you feel comfortable
  • Do not overuse libraries
  • The smaller your APK is, the better (code for everyone)


That Conference 2018 – What’s New in C#7

That Conference 2018, Kalahari Resort, Lake Delton, WI
What’s New in C#7 – Jason Bock

Day 2, 7 Aug 2018  4:00 PM

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2018 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Executive Summary

  • Brief review of history of C# versions
  • Lots of good new stuff in C# 7
  • Importance of C# and .NET now being open source

Language Evolution

  • C# – 2002, .NET 1.0
  • v1 – classes, evenst, properties
  • v2 – generics, partial types, anonymous methods, nullable types
  • v3 – LINQ, implicit types, extension methods, lambda expressions
  • v4 – dynamic binding, embedded interop types, named arguments
  • v5 – async/await, caller info attributes
  • v6 – Roslyn, exception filters, await in catch, auto prop initializer, default values for getters, expression-bodied members, string interpolation, null propagator, nameof
  • v7 – out variables, tuples, local functions, binary literals, ref returns/locals, throw expressions
  • v7.1
  • v7.2
  • v7.3

.NET Foundation

  • Foster open source development
  • Everything in .NET is now open source, on github
  • Contributors from both inside/outside MIcrosoft

.csproj file

  • Can target LangVersion, or latest

Binary digits, digit separators

  • Underscore in integer constant is separator–doesn’t do anything
  • Can do one or more underscores anywhere you like
  • 0b – binary literals

Local functions

  • Declare functions within functions
  • Compiled as private methods, so performance is the same as private methods

Out var

  • Replaces big try/catch block
  • Or TryParse
  • 3rd way in C# 7 – declare out var directly in method call

Ref Returns and Locals

  • Copy semantics for structs
  • Traditional list, indexer returns element, copied if element is value typed
  • Indexer can use ref keyword to pass element back by reference
    • For value typed objects, you get a reference to the value-typed object
  • Far faster (if elements are large)
  • Where you assign the element, you also use ref keyword

Pattern Matching

  • Using switch statement
  • Pass in parameter of parent type, then case on child type
  • Can also add when clause to trigger on stuff specific to that subtype
  • default case can be anywhere
  • case null


  • Not Item1, Item2 syntax from v5
  • Lets say that you want to pass two values back out of a function
  • public (int, int) ReturnTwoInts() { … }
  • Maps to ValueTuple, which has Item1, Item2, etc.
  • Can do named values
  • public (int x, int y) ReturnTwoInts
    • Can now ref result.x, result.y
  • Calling it
    • (var x, var y) = ReturnTwoInts()
  • Can use _ to indicate you don’t care
  • Deconstruct method – pull data out as tuple (?)
  • Can use tuples as concrete types in generics
  • Assign multiple properties in a single line of code with a tuple


  • Task is a reference type, but you might want a value-typed task for performance
  • ValueTask<T> is just a struct that does everything that a Task does
  • You’d use this only if you really need the added performance

Expression bodied members

  • Define wherever you like, not just read-only properties

[C# 7.1]

async main method

Default literals

  • Instead of default(int), you can infer the type of the default
  • So just use default keyword, type is inferred

[C# 7.2]

readonly struct


  • Look at chunk of memory
  • “Safe” way to read/write direct memory
  • e.g. “11,22” .AsSpan()
  • .Slice instead of Substring
  • No allocations
  • More performant

Constraint Generic

  • To enum type, to delegate type
  • where T : Enum

Compare Tuples

  • Equality semantics is correct

Backing field not serialized

  • On auto property, do [field: NonSerialized]

Future Directions

  • Ranges – foreach, in 5..10
  • Default Interface Methods – default implementation for a method on an interface
    • Looks odd
  • Nullable reference types
    • Have to opt-in, to avoid breaks
    • Once opt-in, MyClass mc would be non-nullable
    • Have to do MyClass? to get nullable
    • n!.Length – don’t worry about null-check
  • async streams – async enumerator
  • Generic attributes – e.g. [MyAttribute<int>]
  • Records and with expressions
  • Shapes and extensions
    • Mads T
    • Extensions everywhere – e.g. properties


Q: Isn’t this scary / dangerous? What is the main use case?

A: Multiple return values, e.g. int.Parse that is more elegant because it returns multiple things. Helps to avoid defining little objects designed just to pass data around between methods

That Conference 2018 – WebAssembly: The New EndGame?

That Conference 2018, Kalahari Resort, Lake Delton, WI
WebAssembly: The New Endgame? – David Pine

Day 2, 7 Aug 2018  2:30 PM

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2018 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Executive Summary

  • WebAssembly allows writing high-level source code and compiling to a binary format that runs in execution engine on the client
  • Allows doing C#, for example, in browser
  • Blazor works with Mono to allow .NET on client, including Razor syntax


  • Engines for WebAssembly


  • Binary instruction for a stack-based virtual machine
  • Binary
    • AST (Abstract Syntax Tree)
    • Stored as binary
  • Stack-based
    • Pushing and Popping onto stack


  • Binary execution format for web


  • Mobile and IoT


  • Portable target compilation of high-level languages
  • For C, C++, C#, Rust, Go


  • Compile C#, target WASM, you get binary file
  • File can run in your browser


  • Game
  • In browser debug, you see demo.wasm and not much else

Chrome has it

  • What about other platforms?
  • Big movement, WebAssembly now supported everywhere
  • W3C – World Wide Web Consortium

Text Format (.wat)

  • There’s a text-format human readable version of the final assembly
  • Hard to read, since it’s really the compiled output

What it is not

  • Not assembly-level CPU-specific machine code
    • Doesn’t run on the CPU but runs in browser’s execution engine
    • But you get near-native performance, since it’s close to the metal
  • Not a 3rd-party plugin
    • WebAssembly runs in same sandbox as JavaScript
  • Not versioned
    • Backwards-compatible
  • Not JavaScript replacement
    • WA plays nicely with JS
  • Not a programming language
    • If you hand-coded .WAT files, it would be
    • But it’s really just a format or compilation target
  • Not the ideal tool for every web project
    • Different tools, e.g. JavaScript, C, to do HTTP request


  • Tool for compiling to WASM

Demo: Emscripten

  • emcc
  • Takes C source file as input (e.g. hello.c)
  • Target WASM
  • Run output in browser–we get console output in the browser

WASM Explorer / Fiddle

  • Call WASM assembly from JavaScript

Use Cases

  • Games, rich client, etc.

Hanselman interview of Steve Sanderson

  • Web development has been constrained because everything has had to be in JavaScript
  • Web development will be able to grow up and mature a bit

My interview with Sanderson

  • Give developers a wider choices of languages and platforms
  • Industry healthier if multiple paradigms catered to


  • Mono Runtime
    • Cross-platform .NET runtime
    • Using it now for Blazor


  • Browser + Razor
  • Experimental project at the moment
  • Not yet a committed product

How Blazor works

  • Dev time
    • C# / Razor source files
  • Runtime in browser
    • mono.wasm – WebAssembly binary executed natively
    • Browser APIs – visible DOM, HTTP requests, etc
    • YourApp.wasm – WebAssembly version of your library

Demo – Blazor

  • Project template in VStudio
  • ASP.NET Core Hosted
  • You get Client stuff and Server stuff, as well as Shared stuff
  • Shared library has web objects shared across server and client
  • Template gives you a simple multi-page web site with a few things
  • Fetch some data, click a button, etc.
  • Server has controller that returns some basic data
  • Razor syntax that turns into HTML
  • Inject HttpClient into component on client

Look at code for Blazor

  • Debug C# code in browser
    • Hit breakpoint after interacting with something in the browser
  • Program.cs with main entrypoint
  • CreateHostBuilder
  • Wire up various services
  • Add component (app)
  • Standard markup with Razor binding to C# object (model)

Other debugging

  • Currently not pre-compilation, but running in interpreted mode
  • Full-on .NET DLLs on client, e.g. mscorlib
  • For small app, we’re at 3.5 MB
  • But this will get optimized

Mono.wasm – is the .NET runtime running in a WebAssembly


With Unity, can target WASM

  • Unity in browser

That Conference 2018 – Design Patterns: Not Just for Architects

That Conference 2018, Kalahari Resort, Lake Delton, WI
Design Patterns: Not Just for Architects – Jeremy Clark

Day 2, 7 Aug 2018  1:00 PM

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2018 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Executive Summary

  • There exist lots of design patterns that have been defined
  • We already use many of these without realizing it
  • Worth learning them–helps in communication
  • Examples of several patterns in C#


Goal: We’re already using design patterns, so worth putting a name on them


What are Design Patterns?

  • (Christopher Alexander quote)
  • Describes solution in a way that you can use it over and over again


Gang of Four book (GoF)

  • Gamma, Helm, Johnson, Vlissides
  • “Serious developer” needs to have this
  • Still relevant?  Yes
  • Examples in C++ and Smalltalk


Anatomy of a Design Pattern

  • Pattern Name
    • Unique way of referring to pattern
  • Problem
    • Problem that occurs over and over again
  • Solution
    • “Core” of the solution
    • Example implementations are not solutions
  • Consequences
    • Pros and cons
    • Things to watch out for


GoF Patterns

  • 23 different patterns
  • Categories
    • Creational
    • Structural
    • Behavioral
  • Book is a bit academic
    • Go through it at some point in your career
    • “You’re not ready for it yet”


Good starting point

  • Head First Design Patterns – Freeman, Freeman
  • Covers 12 of the GoF patterns
    • Same descriptions
    • Just explains it in a more approachable way
  • Examples in Java
    • But pretty general, so ok
    • Online, translations into various programming languages


Why Should We Care?

  • These are well-described solutions
  • Shared vocabulary
    • Easier to talk with other devs
  • Concise language
    • Quicker/shorter to just mention the pattern, rather than describing it in detail
  • Think in design rather than implementation
  • Encourage other developers to learn patterns


Observer pattern

  • When object changes state, dependent objects notified automatically
  • Publish-subscribe relationship


Real World Observer

  • Twitter – someone tweets, subscribers are notified


Implementation of Observer (C#)

  • Event handlers on button
  • This is ubiquitous in C# and in frameworks
  • Problem => Pattern => implementation of the pattern
    • E.g. pubsub => Observer pattern => event handlers
  • Prism, event aggregator
    • Publisher, subscribers don’t know about each other
  • .NET 4.0 – IObserver<T>
  • Consequences
    • I don’t know how many times I’ll be notified
    • Don’t know how frequently I’ll be notified
    • Don’t know if we’ll ever be notified


Iterator Pattern

  • Access elements of object sequentially without knowing about implementation of the thing
  • Get next item, stops at end
  • Real-world: Channel up button on TV Remote
  • In C#, foreach loop uses the iterator


Implementation of Iterator (C#)

  • Get List<T>, case to IEnumerable<T>
  • IEnumerable<T> says that object supports get next element (foreach)
  • All collections in .NET implement IEnumerable<T>
  • Nice that this is built into .NET (C#)


Facade Pattern

  • Unified interface for a set of interfaces in a sub-system
  • Higher-level interface makes things easier to use
  • Wrap complex stuff in simpler API


Real World Facade

  • Universal remote control wrapping access to multiple devices


Facade Implementation

  • foreach loop is also an example of facade
  • GetEnumerator
  • while (enumerator.MoveNext()) … do something with enumerator.Current()
  • foreach is a nice wrapper around this
  • Consequences
    • We might lose functionality that lower level stuff has
    • E.g. foreach doesn’t give access to Reset() method


Chain of Responsibility

  • Avoid coupling sender to receiver
  • Giving more than one object a chance to handle the request
  • Pass request along thru children until somebody handles it


Real-world example

  • Tech Support – first line, person asks questions
    • If not, passes to next person, more detailed look at your question


Chain of Responsibility Implementation

  • Throw exception
  • Catch certain types of exceptions at certain levels in call stack
  • If not caught at one level, it propagates up to the next level
  • Consequences
    • What is nobody handles the message?


Proxy Pattern

  • Provide surrogate for another object to control access to it
  • Example: Power of Attorney
    • One person makes another their proxy
  • Surrogate vs. placeholder
    • Placeholder–thumbnail or icon that only loads something when you click it
    • Good idea in mobile apps–delay download of some stuff, in case you have slow connection


Proxy Pattern Implementation

  • Web API service, controller with Get method
  • Get collection, return via service
  • Can create proxy service class that can call the service
    • HTTP clients
  • Use the proxy in the same way that you’d treat the original class
  • Consequences
    • Hides what’s really going on with the underlying object


A Million Implementations

  • Use over and over


That Conference 2018 – Launching with Now, Next, and React

That Conference 2018, Kalahari Resort, Lake Delton, WI
Launching with Now, Next, and React

Day 2, 7 Aug 2018  10:30 AM

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2018 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Executive Summary

  • Summary of tech stack used at Northwest Mutual and on Nicholas’ personal project
  • Recommend combination of micro services and micro apps
  • Koa vs. Express
  • Use Next?


Micro-Service vs. Micro-App



  • Encapsulate business logic
  • Encapsulate persistent data
  • Reusable, stand-alone solution
  • Not always a 1:1 relationship between micro-apps and micro-services
  • Independent
  • Tidy, clean



  • Client facing code
  • May call mlutiple micro-services for data or computations
  • Handle interactions and specific complex problems
  • Aggregates inof from multiple services


The Tech Stack

  • Node
    • Released support for async/await
  • Koa – “fix” Node; minimal lib as extraction of HTTP module of Node
    • Solves same problem as Express
    • Promises, async/await
    • Now at Koa 2–far less confusing than Koa 1
    • Choice for micro-service
    • Avoids “callback hell”
    • Choice: Express vs Koa
  • Express – augmentation for node that allows setting up simple server
    • Can end up “callback hell”–messy callback architecture
  • PostgreSQL
  • React
  • Next – like React, but SSR a bit differently than React does SSR
    • Also bundled with some “auto magical” elements
    • Good for supporting SEO
  • Redux – state management tool
    • Source of truth that feeds application



  • React 16 solved a lot of problems
  • React portal
    • Render a component and drop it somewhere else in your application
    • Specify what to render, where to render it
  • Fragment
    • Can return multiple components (e.g. HTML elements)
    • <React.Fragment>
    • Could return several table columns, not wrapped in <div>
  • Context API
    • Have state that’s inherited down with component hierarchy
    • Avoid passing things down the tree



  • Recent update that took advantage of all of React 16
  • Does things “auto-magically”, secretively, just works out-of-the-box
  • You call next command; it fires up server, automatically does various things
  • No longer have to explicitly import React into any of your components


Decisions – Handling Server Requests

  • For API used Kora – conceived for and caters to async/await funcs
  • For apps, used Express
  • Subtle differences between the two
    • Express is lower barrier to entry
    • Tons of tutorials out there
  • Most differences deal with middleware
  • For middleware-heavy apps, Koa better


Decisions – Rendering

  • Client-side vs. server-side
  • If SEO is concern, server-side might be simpler to roll out
  • Server-side rendering opens the door to some PWA setups (Progressive Web App)
  • Client-side rendering makes SEO harder
  • For server-side: React vs Next?
  • Anxiously awaiting React’s async rendering
  • Went with Next


Decisions – State Management

  • There are many options, and tons of patterns
  • Redux vs MobX vs others
    • MobX worth a look if you’re starting from scratch
  • Meiosis Pattern
  • Context API  (in React)


ThinkMinded Architecture

  • Micro Service (just 1)
    • Node, Express
  • Micro App
    • React, Next, Node, Express
  • Has mindset of allowing others to consume our data
    • So micro service is a standalone API


Micro App Architecture (ThinkMinded)

  • Redux
  • Redux store has sequence
    • Action => Dispatcher
    • Reducer
    • State
    • => Back to GUI


Engineering – React

Engineering – React / Redux

Engineering – Next / Redux

  • Similar to above, but don’t import React
  • Biggest difference, package.json changes, use next commands to do everything
  • Next uses Webpack
  • Next automatically creates API, based on file system
  • Hot module re-loading
  • Automatically indexes


Deploying with Now

  • Now is a platform for global deployment
  • Generates a URL upon deployment (staging)
  • (vs Gitlab)
    • Gitlab for bigger teams
    • Now has nice CLI
  • Staging can then be aliased to production
  • Works to deploy Node.js apps and docker powered apps
  • Preferred for short/small personal projects


That Conference 2018 – Correcting Common Mistakes When Using async/await in .NET

That Conference 2018, Kalahari Resort, Lake Delton, WI
Correcting Common Mistakes When Using async/await in .NET – Brandon Minnick

Day 1, 6 Aug 2018  4:00 PM

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2018 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Brandon Minnick

Developer Advocate, Microsoft


Executive Summary

  • Helps to know underlying IL that’s generated
  • Helps to know core task-based objects that async/await use
  • ConfigureAwait(false) if you don’t need to come back to UI thread
  • .GetAwaiter().GetResult() instead of await to get synchronous execution

Multi Threading

  • e.g. ReadDataFromUrl
    • Our method is async
    • does await on DownloadDataTaskAsync
    • 1st chunk of code is run by the thread that calls this method
    • 2nd thread–calls the Download method
    • After await, execution picks up with 1st thread
  • Typically, first thread, i.e. main thread, is the UI thread
  • UI thread
    • Draws UI on screen
    • Rule-of-thumb for executing on UI thread. Because refresh rate is 60Hz, don’t take more then 1/60 sec (17 ms)

Intermediate Language

  • Compiler generates class for your original method
  • Implements IAsyncStateMachine
  • Every local variable from method becomes private field in class
  • MoveNext method
    • Giant switch statement
    • $PC keeping track of state
    • Also a big try/catch block surrounding everything

Quick Review

  • async keyword adds 100 bytes
  • Every async method becomes a class

Await Every Async Method

  • Non-awaited async methods hide exceptions
  • Ditto for Task.Run — GetAwaiter().GetResult() will ensure we catch exception

Let’s Fix Some Code

  • Can’t await in a constructor
    • ICommand–made for fire and foreget
    • In Execute method, do async lambda with await
    • So from constructor, we can call MyCommand.Execute(null)
  • Never use async void ?
    • Not entirely true
    • Don’t use async void when not on UI thread
    • But on UI thread, if you throw exception from within async void–you’ll catch the exception
  • So from constructor, call Initialize(), which is an async void and can do the await
  • NEVER use .Wait
    • Blocks calling thread entirely
    • Doesn’t unwrap an exception
  • NEVER use .Result
  • Way better method
    • GetAwaiter().GetResult()
    • Does unwrap any exceptions
    • Can get the result from the async method
  • Note: .GetAwaiter().GetResult() is to be used in non-async method
    • In async method, just use await keyword
  • ConfigureAwait(false)
    • By default, you context switch back to UI thread
    • But this is expensive–background thread has to wait for UI thread
    • Context switch takes time
    • When background thread is done, execution stays on that background thread. Does not come back to UI thread
    • But note that you do need to come basck to UI thread if that method does some stuff with the UI, e.g. modify a control
  • ConfigureAwait(true)
    • This is the default, equivalent to not having ConfigureAwait() there at all
  • Don’t call .Result
    • Replace with await that method call to get the result directly
  • Special case, returning await something that returns Task<>
    • You can return the task directly, rather than awaiting it, then doing async on the method
    • Look for “return await”
  • Exception to this rule
    • You should await if you want to catch exception in method that you’re calling
    • So you could argue not to every do that trick

Async/Await Best Practices

  • Never use .Wait or .Result
    • Use await keyword
    • Or .GetAwaiter().GetResult()
  • Fire and forget tasks
    • Use ICommand
    • (or) async void (if you know you’re going to be on main thread)
  • Avoid return await
    • Remove async keyword
    • Except in try/catch blocks or using blocks
  • Utilize ConfigureAwait(false) as much as possible
    • In methods that don’t touch the UI

Xamarin University

  • Various course, e.g. CSC350: Using async await

That Conference 2018 – API Design Isn’t Just Nouns and Verbs

That Conference 2018, Kalahari Resort, Lake Delton, WI
API Design Isn’t Just Nouns and Verbs – Keith Casey

Day 1, 6 Aug 2018  2:30 PM

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2018 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Keith Casey

  • Okta – SSI identity management on the web
  • OAuth as a service, for Fortune 10 companies
  • “A Practical Approach to API Design” – Casey


  • Nothing/nobody is perfect
    • Will be attacks against API, some intentional, some not

What Is an API

  • contract about how two pieces of software interact
    • Can have lots of ceremony (e.g. SOAP) or less (e.g. REST)
    • REST is not a protocol, but a pattern for interacting with things
  • How one piece of software talks to another

Application Programming Interface

  • It’s an interface
  • We have users of our API
  • “Don’t Make Me Think” – Krug
    • Can apply same principles to API, just like GUI
  • Stop and think about how API appears to its users

What are we doing now?

  • Frameworks for creating RESTful services–there are tons
  • We generally default to some framework for building an API
  • Typically it just maps tables in database to verbs–CRUD over HTTP
    • But we normally don’t want to expose row-based pattern as the API

What is Bootstrap?

  • Clean, simple UI
  • Standard, consistent, reusable components
  • The bane of every UX designer

Why ?

  • Bootstrap treats every application the same
    • Ignores the application, what they use it for, how they use it


  • Expose additional data from database via API
  • “GraphQL is the CSV of API Design”
    • Ignores requirements, just give them every field and user can choose
  • Same thing, treats every application the same

What Should We Do Better?

  • E.g. Anonymous visitor to web site, want to create user account
    • that I can see my account balance
  • Must ask why on user story in order to understand the requirement
    • Can then build the right thing, better, faster
  • The things that we build need to be valuable to users
  • Developers want to
    • Build something useful
    • Go home

Think About the Story

  • What are the choices available to a user at any given time

Steps in Designing API

  • Identify who uses API
  • Identify high-level activities
  • Break down into steps
  • Create API Definitions
    • Prior to this step, it was a business process
  • Validate API

Identify Participants

  • List consumers of the API (directly or indirectly)
    • e.g. internal or external
  • Capture a bit about them–location, description

Identify High-Level Activities

  • Activity–work that produces a desired income, accomplished by one or more participants
    • Must understand user’s goals at this point
  • Activity might have multiple steps
  • Make note of description, participants

Break Down into Steps

  • Each step is accomplished by single participant
  • Step may have stages executed by different participants, but each step maps to single participant
    • Watch out for “and” steps–could be multiple steps

Create API Definition

  • Identify resources (the nouns)
  • May start to find dependent/nested resources
    • And business rules around the relationships
  • If API user needs to understand database schema in order to use API
    • You’re doing it wrong

Resource Relationship

  • e.g. Movie, Actor, Character relationship

Validate Your API

  • Ensure that your API will meet the requirements of the users
  • Walk through each use case
    • Individual steps in use case on notecards
  • You document how many activities need each API action
    • Helpful to know how widely used each endpoint is
    • Correction–each activity has steps, each step on a notecard; document which activities each step needs to be a part of

Validation Options

  • Compare API capabilities against UI wireframes
  • Build simple mock interfaces in a micro-framework
  • Write example code showing how to use it
    • Mock API, Happy JS?
  • Write end user documentation

What Should We Avoid?

  • Don’t assume we know all the use cases
    • e.g. multi-tool that has everything

Don’t collect or share extra data

  • Combridge Analytica
  • Why should people share this information?
  • How might a bad actor use this information?

Don’t Leak Your Own Data

  • E.g. giving user an incremented customer ID
  • What can someone tell by using your API?

Don’t Roll Your Own Encryption

  • Use an existing library
  • No, no, no don’t do your own encryption

That Conference 2018 – Know What Your Code Is Doing to SQL Server

hat Conference 2018, Kalahari Resort, Lake Delton, WI
Know What Your Code Is Doing to SQL Server – Kevin Boles

Day 1, 6 Aug 2018

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2018 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Kevin Boles

Executive Summary

  • Handful of specific examples of ways that you can end up with poorly performing SQL Server queries
  • Improper use of Entity Framework sometimes to blame
  • Always pay attention to exact T-SQL that is being used



  • Recommend 192GB on server, go beyond max memory (128GB)
  • In memory OLTP now down in standard edition
  • SQL Server 2016–It Just Runs Faster
    • Good blog posts on performance improvements
  • Get on 2016 or 2017


Entity Framework is tool that simplifies, but lower performance

  • Can be very productive
  • Several traps, easy to fall into
  • Other ORMs have similar problem


Being too greedy with rows

  • EF exposes objects without knowing values
  • E.g. pull data out to list, when do Where clause on the list
    • Pulls entire table before filtering
  • Do filtering on SQL Server
    • Provided that you ave the proper filter
  • Or could bring back to IQueryable


N+1 Select Problem–minimize trips to DB

  • ANTS performance profiler
  • E.g. One query to parent entities, 2nd query for each child to get related entities
  • Round-trip for each child query
  • Lazy Loading
  • “N+1 select problem”
  • If you know you want child data ahead of time, do the original query to include it
  • Use Eager Loading
    • .Where, .Include
  • Make sure that you really need them
  • Don’t do aggregation in client–do it in SQL Server
  • E.g. if we’re just counting child objects, do it with aggregate function in SQL Server
  • Don’t iterate and don’t get data that you don’t need


Being too Greedy with Columns

  • E.g. pull all Pupils from school, then iterate to dump out certain stuff
  • Selecting all columns when you just need subset of columns
  • EF doesn’t know what columns you want
  • Causes two problems
    • More data than we need
    • Impossible to index, since we pull everything back
    • If acceptable, can be faster because you don’t wait for confurrent transactions
  • If you’re pulling all columns, you’re locking entire table for the length of that query
  • Select new to just get you want


Mismatched Data Types

  • If data types don’t match, even simple queries can perform poorly
  • E.g. search for entities with particular zip code
  • Dev system should match prodution system in terms of scale
  • Find query runs fast, EF runs very slowly
  • Query plan warning
    • Function on a column in a WHERE clause
  • Column in database is VARCHART, but .NET has string, which is UTF16 Unicode
  • SQL Server does
    • INDEX SCAN of every zip code
    • Big I/O cost
    • Then converts the data–CPU hit
    • Optimizer can’t do prediction because  data is different than what’s in the index
  • Solution
    • Edit model to tell EF to use VARCHAR, using column annotation
    • In code, attribute
  • Do not let EF create models, code-first



  • He recommends not using one



  • 3 things to remember about stuff on internet about SQL Server
    • Who wrote it
    • When was it written
    • Does it apply to my system
  • ADO.NET Parameterized Queries
  • AddWithValue–get rid of this


Overly Generic Queries

  • Allowing searching on multiple fields
  • So we construct one query, where clauses for each search field
  • == null or matches
  • IS NULL OR stuff gets into query
  • Bad because it builds query plan just once for all the possible search combinations
  • Always runs same query plan, no matter what you search on
  • Can’t do a seek on index
  • Options
    • Stored procedure — Gail – “catch all queries”
    • Conditionals in EF side, exclude clauses
    • Make SQL Server recompile plans each time–from within EF. Sometimes good
    • Could write interceptor, option(recomiple)


Bloating the plan cache

  • Reuse of execution plans often a good thing, avoid regenerating plan
  • In order for a plan to be reused, the statement text must be textually identical, wihch as we just saw, is case for parameterized queries
    • Ad-hoc workloads


Skip / Take

  • Next time we run query, we get different query plan
  • Enable SQL Server setting ‘optimize for ad-hoc workloads ‘
    • Less aggressive at caching plans, generally a good thing
  • EF6, pass in lambdas
    • In SQL, values are paremetrized, so we don’t recreate cache plan


Inserting data

  • EF will run separate INSERT statements for every row being added
  • Not good if you have to insert a lot of data
  • Can use EF.BulkInsert or use EF 7 (has this out-of-the-box)


Code First, Performance Last

  • Never allow your code to create your storage constructs
  • (He means–code-first used to refresh database object)


Other Potential Issues

  • Improper use of IN clauses
    • >16 clauses in IN clause if bad
  • Correlated subqueries instead of JOINs
  • Parameterized queries with parameters defined to be length of data they contain
  • Chatty apps
  • Security conerns
  • Increased IO and app bloat due to asking for too mcuh data


That Conference 2018 – Finding Your Way to a Microservices Architecture

That Conference 2018, Kalahari Resort, Lake Delton, WI
Finding Your Way to a Microservices Architecture – Dana Hart

Day 1, 6 Aug 2018

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2018 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Dana Hart
Northwestern Mutual

Executive Summary

  • Lots of good reasons for re-factoring monolithic application as microservices
  • Architecture has multiple micro SPAs talking to multiple microservices


Monolithic application

  • Browser
    • UI / Business Loic / User Logic
    • Databases
  • One application on single platform
  • Drawbacks
    • Maintenance
    • Hard to test
    • Longer deploys
    • Longer downtimes
    • Doesn’t scale
  • How we got there
    • Probably started out small
    • Features have been added


Scaling the mono

  • Development–multiple teams in one repo
  • Continuous Deployment – updates = outages, higher risk
  • Increased Transactions – ru nmore copies of application?  Scale out metal?
  • Is this good enough? Working?


Frustration is an important part of success


Software microarchitecture

  • Set of patterns used together to realize parts of a system
  • Building block for piecing together cohesive portions of an overall architecture



  • Structure application as collection of loosely coupled services
  • Enables continuos delivery and deployment of large, complex applications



  • UI talks to various microservices
  • Each microservice talking to one database


Reasons to convert

  • Decomposes complexity
  • Developed independently
  • Deployed independently
  • Scaled independently
  • Smaller deploys
  • More frequent deploys
  • Lower deployment risk


How to start

  • Find piece that can exist independently
  • Don’t just convert, but re-factor


REST review–constraints

  • Uniform interface
  • Client-server
  • Stateless
  • Cacheable
  • Layered system
  • Code on Demand


Define your subdomain


REST review

  • Sensible resource names
  • XML and JSON
    • Recommend JSON over XML
    • Easier to consume by browser
  • Fine-grained resources
    • Simple resources that you can apply CRUD to
  • Idempotence
    • Get same response every time if inputs are the same
  • Safety


Micro SPAs

  • Take original monolithic UI
  • Split into separate pages, each being a SPA
    • /store
    • product
    • /order


Deployment Patterns

  • Multi service instances per host
  • Service instance per Host / VM / Container
  • Serverless deployment
  • Service deployment platform
    • Automated infrastructure


Move everything to cloud


Reverse proxy

  • URL goes thru reverse proxy (external request)
  • Look up services, find target address
  • E.g. use NGINX


API Gateway

  • SPA Containers send requests
  • To API Gateway
    • Could implement security
    • Load balancing
  • Farms out to API Containers


Micro Application platform–diagram

  • Request
  • Reverse Proxy
  • SPAs
    • Can talk to one or more services
  • API Gateway
  • Services
  • Databases


At end

  • Multiple SPAs
  • Multiple services
  • No deployment downtime
    • Pre-production environment
    • Kubernetes handles this




Q: When do you decide to create an API that might combine logic from two sub-domains?

A: We wouldn’t combine the services, but let the UI do the model translation between the two services. But sure, you could add a service that aggregates data from multiple services.


Q: How do you handle versioning?

A: Many opinions around versioning. We have pattern of “v1”, “v2” in front of API. “No breaking changes” unless it’s a major version chance.


Q: How do you decide what goes in what database?

A: We still have one large database. If the entities have relationships, we’d be hesitant to split them out.


Q: How do you manage to get common look/feel across the SPAs

A: It’s not easy. We had designers to create common UI Sketch components. Then devs create UI framework around these common elements. Partnership between Engineering and Design.


Q: How did you avoid applying legacy change management techniques (monolithic) to new architecture. Had to educate various teams to demonstrate that we’re now running with lower risk. Dev team “owns” the result of a deployment, responsible for it. We use New Relic for monitoring.


Q: We have 3rd party integration with a service that is not stateless.

A: Sometimes you do get stuck with a vendor’s implementation. Could give examples to vendor of what work better for you.


Q: Where do you pull stuff from multiple services together?

A: We do it in UI layer, model translation, pulling stuff together.

That Conference 2017 – From Dull to Dazzling: How Visualization Enhances Data Comprehension

That Conference 2017, Kalahari Resort, Lake Delton, WI
From Dull to Dazzling: How Visualization Enhances Data Comprehension – Walt Ritscher

Day 3, 9 Aug 2017

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2017 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Walt Ritscher

  • LinkedIn Learning – online video training (formerly
  • Content available on both sites
  • 7100 courses
  • @WaltRitscher

Executive Summary

  • Showing data visually can make patterns and trends suddenly very obvious
  • Varying graphical data items’ size, color, position, contrast or shape can make a big difference in how a user views the data
  • Review of various data visualization tools and some examples of graphs

Your Data

  • We all have various data sources and lots of data
  • Big Data – lots of data
    • Gathering at unprecedented rate
    • Many sources–sensors, online transactions, medical, tweet streams
  • If you don’t use/analyze data, you’re a hoarder
    • Stored data is inert
    • Need to make it Actionable
  • Raw data can be hard to understand
    • E.g. Big spreadsheet
    • “Wall of text”


  • Bring human optical system into picture
  • Visual recognition is 60,000x faster than text recognition

Example – Anscombe’s Data

  • 4 sets of XY data, with averages and std deviation
  • Visually view same data
  • We see patterns
  • And pattern anomalies

Demo – Differences – Test

  • Changes to hue, saturation, size of object
  • Change shape–quickly recognize
  • Can’t find difference if original shapes very different


  • Size
  • Color
  • Position
  • Contrast
  • Shape

Highlight Differences with 5D

  • Use one of the differentiators to highlight a difference
  • If original set is uniform in shape, but different colors, you’d differentiate by shape to make it stand out
  • Counting # instances of “8” shape
  • Could colorize rectangles around digits
    • Heat map
    • Easy to spot area with higher numbers
  • Or could change size of shape by value
    • Bubble chart
    • Easy to see high growth
    • But harder to see actual numeric data

A Word about Colors

  • Chart–happy customers green, angry red
  • Don’t use green/red
  • Problem–green/red color-blindness about 10% can’t differentiate
  • Could do Blue / Red–easier to differentiate (99.5% population)
  • Example–colorizing heatmap
    • Which colors seem to be “higher” value color
    • Brain doesn’t do this
  • Rule: don’t differentiate by Hue
    • Differentiate by Saturation or Lightness

Motion and Animation

  • Demo – slightly changing something, moving something slightly on screen
  • Your brain sees the motion
    • Can see something moving even 1-2 pixels
  • Can animate data, showing stuff in sequence
  • If you have time-stamped data, consider animating that

Warning–eyes can be deceived

  • With a lot of lines, you can’t see more than a couple black dots
  • Pie chart – 30% slice looks smaller if it’s in the back
    • Never use 3D pie chart
  • Displaying change in one variable using area or volume
    • Showing relative sizes using area–doesn’t work

Terminology – The Buzzwords

  • Categories of visualization
    • Data Visualization – show data via graphical
    • Infographic – design friendly approach to visualization
    • Motion Graphics or Animated – use motion to accentuate

Data Viz Categories

  • Business tools – Excel
    • Excel continues analysis engine
    • Can launch in background and generate results or chart
    • Could take screenshot in the background
  • Drawing tools – Illustrator
  • Code tools – Visual Studio

Data Viz Tools

  • Processing – programming language
  • ProcessingJS
  • Tableau
  • D3.js
  • R – language to manipulate data (no viz)

Data Viz Browser Tools

  • SVG
  • 2D Canvas
  • WebGL


  • Sideways bar chart
  • Excellent
  • Web site allowing you to pull data out ( ?


  • Glasswire – exploring data
    • Timeline with sliders
    • Nice alternative to having two calendar dropdowns


  • Designer-friendly approach to data visualization
  • View uploads by category
    • Wedges in triangle
    • “Umbrella graph” ?
    • Callout coming out of wedge

Motion Graphics

  • NASA Perpetual Ocean
    • Latitude, Longitude
    • Flow direction & speed
    • Timestamp


  • Visualization Data
  • Tufte


  • Time-tested concept but still useful
  • Have done bar and line charts forever
  • But lots of new charts out there
  • New charts
    • Waffle chart–boxes
    • Hierarchical Edge Bundling–connecting nodes, bezier curves, trends pop out
    • Adjaceny matrix–e.g. Les Miserables Co-occurrence; awesome animation
  • D3.js
  • Bret Victor

That Conference 2017 – 12 Reasons Your API Sucks

That Conference 2017, Kalahari Resort, Lake Delton, WI
12 Reasons Your API Sucks – D. Keith Casey Jr

Day 3, 9 Aug 2017

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2017 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

D. Keith Casey Jr


  • Twilio, Okta, Clarify
  • A Practical Approach to API Design –

Executive Summary

  • There are a number of things that you can do to deliver high quality API cod


  • APIs are important part of your job
  • Use them on a regular basis
  • Potentially build them too
  • Sometimes public, sometimes private
    • Same principles should apply
    • For internal API, if it’s awful, internal users can’t use another one
    • I.e. Adoption = in spite of your best efforts
  • Nothing is perfect
    • You make mistakes
    • Your providers make mistakes
    • That other team are knuckleheads
      • “Why do they work here”?

Developer Experience

  • “Developers are users too”
  • Don’t Make Me Think – Krug
    • When you make something figure something out, you’re taking time away from their main objectives
    • When you interrupt someone, you “reset” their work
  • Developers
    • Want to build something useful
    • Want to go home at end of day
  • Set aside an hour – you really tried
    • Phone calls, e-mails, IM, Slack, etc.
    • “Do you have a minute”?
    • TPS reports
  • At Twilio
    • 5-min onboarding experience

1 – Documentation

  • If delivering documentation via PDF–stop
  • HTML–
    • Slate great, widespread use
    • You write in markdown
  • When people are ready to use the API, documentation needs to be ready
  • Let’s get interactive
    • Swagger – now Open API
      • Load up in browser and interact with endpoints via browser
      • Level of skill required to try out goes way down
    • (competitors) JSON Schema, API Blueprint

2 – Incomplete Docs

  • If you’re only documenting SDK, that’s not complete API documentation
  • Must have actual API reference docs
    • Exact syntax for each endpoint
    • High level of detail
  • JavaScript drinking game–random noun + .js
  • When you take dependency on 3rd party library
    • If it’s not popular, you’ll end up bringing it in house
  • Need reference docs + How To docs
    • Basic API is straightforward to figure out
    • But need to tell developers how to do something useful

3 – Getting Started Code

  • Sample code that solves a problem
    • How to do a “thing”
    • But nobody cares about that thing
  • 1st thing you need
    • Authentication
  • Need to give them sample code that solves an important problem
    • But we don’t know what’s important
    • Customer wants you to solve their specific problem
    • User judges docs based on whether it solves their problem
  • Work quickly to make someone successful

4 – “Innovative” Interfaces

  • Nobody really wants innovative
  • Everyone tries to create their own
    • HTTP verbs – important that they’re standard
    • Response codes – don’t do this
    • Your own protocols – also huge ecosystem out there
      • Probably not qualified to build your own
    • “Don’t Be Dumb”

5 – Authentication

  • Don’t roll your own “encryption” scheme
  • Don’t roll your own “new” methods
    • You’re not qualified to create something new
    • Good encryption scheme have been out there a long time and have been hammered on
    • You’re new scheme won’t have been deeply reviewed and tested
  • Use existing scheme like Oauth
    • Less training required – for users
    • Reuse common libraries for clients & server
    • Faster on boarding – for internal developers

6 – Inconsistencies

  • Consistency of URIs
    • See some URIs, you want to extrapolate to figure out other URIs
  • POST -d {data}
    • Use 201 Created and Location header
    • Don’t do 201 for most, then 200 for one
  • If you are inconsistent/wrong on day 1, you’ll have to support that mistake for years

7 – Poor Modeling

  • Example–coffee cup w/handle
    • Accomplishes primary goal (don’t get burned)
  • When building API, what is user’s primary goal
    • Single sentence, primary use case
  • Affordances
    • What problems/tasks does it make simple?
    • What is the API producer’s goal?
    • What do you want to do?
    • (or) Why are people giving us money?

8 – Stack Overflow Problem

  • Many different way to do something
    • Other places are replicating your documentation, advising how to do something
    • And these documents end up on Google
  • E.g. Multiple ways to pass auth token into API
    • E.g. Auth Header, URL, or body
  • Just give them one way to do something

9 – Your Sh.. Stuff Is Broken

  • Is Support run by developers?
  • What does your uptime look like?
    • Never 100%
    • Cost increases exponentially as you add digits to %
    • Two digits easy
  • Do you have a Trust page?
    • Usually yourapi/trust — status of issues, history, what happened
    • Need to be open with the devs who are using your API
  • Need to make sure your stuff works
    • SLA in place once people are using it
  • Core hours during which API must be up
    • And some users out there who need it during off hours

10 – Error Messages

  • Bad error message–unhelpful
  • “Don’t do this to people”
  • E.g. 404 – “Item Not Found” — not great, just repetitive
  • Error code
    • 404, Item not found, E000007
  • Add error_code and more_info with URI that explains error code
    • Simple
    • And you better have information on the error at the page
  • E.g. HAL – additional links with every payload
    • Typically return this stuff with an actual resource
  • Could avoid response body entirely
    • Just set 404
    • And add some stuff to header (spec allows this)

11 – Logging and Debugging

  • API going to break, unavoidable
  • RunScope – good tool, proxying, catching web hooks
    • Web-based
    • Not appropriate in regulated field
    • Don’t use if you can’t leak private data
  • Fiddler
  • Postman
  • Building Your API Utility Belt
    • Another talk
    • Use the right tool for the job


  • “Principle of Least Surprise”
  • Designed workflows
  • The One True Way
  • Authentication


  • Error messages & handling
  • Logging & debugging

12 – Do you Have a Business Model

  • You’re building trust with users
  • Fastest way to destroy trust is to disappear as a business
  • If your business disappears, you’ve just screwed somebody
  • API must support bottom line of API builder
  • As customers become more successful, scaling up with your API, you make more money
  • If just an experiment, tell people that

That Conference 2017 – The Static Web Revolution

That Conference 2017, Kalahari Resort, Lake Delton, WI
The Static Web Revolution – Steven Hicks

Day 2, 8 Aug 2017

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2017 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Executive Summary

  • Lots of good reasons to publish static web site, rather than dynamic
  • Need to select a Static Site Generator
  • Lots of tools to choose from, but there are tradeoffs

History of the Web

  • “Before” time
    • 1997 – static HTML
    • Scrolling / blinking
    • Hard to maintain static files
  • Dynamic back-ends
    • PHP, ASP
    • ASP.NET, Rails, Node
  • CMS on top of frameworks
    • WordPress, Drupal
    • Marketing guys could now manage the actual content
  • Bootstrap
    • Everything based on Bootstrap
    • Tons of stuff is based on WordPress

How did we get here?

  • Bootstrap & CMS for all content
  • “Simple enough for anyone to use”
  • “Any other way would be a maintenance nightmare”

A Hero Rises

  • “Are we using the right tool”?
  • “Is your content truly dynamic”?
  • “How often does your content change”?
  • “Is a dynamic site worth the cost of support?”

Surprising Numbers

  • 28% of sites on Internet run on WordPress
  • 70% of WordPress installs are vulnerable
  • 20% of top WordPress plug-ins are vulnerable


  • Compelling alternative to traditional dynamic website

Dynamic Website

  • Content in database
  • HTML generated when user requests it
  • Content managed with CMS
  • Admin tool to administer stuff, add new content, etc.
    • Can be in CMS
  • Magic happens between database and CMS
    • Convert data to HTML
    • Happens for every user

Static Website

  • Static files
  • Generated when content changes
  • User request–return static HTML
  • Static site generator–generates the HTML
  • The magic happens less frequently, when content changes

Why Go Static

  • Speed – static HTML is faster
    • CDN ready
  • Security
    • Fewer moving parts that can be attacked
  • Simplicity
    • Fewer points of failure
    • Don’t worry about database, caching, etc.
  • Scalability
    • Static is easier to scale out
  • Source Control
    • Just store content in CM
    • Rather than database data, which doesn’t automatically track history

How Do I Get Started?

  • Static Site Generator
    • Command-line tool
    • Flat files as input
    • Output is complete website of static HTML

How Do I Customize?

  • Themes (if you’re lucky)
    • Not a ton of support for it, though

How Do I Write Content?

  • Header & Nav don’t change (Template)
  • Content

Templates – EJS

  • Inject stuff like title, conten

Templates – Other

  • Handlebars
  • Pug (Jade)

Writing Content

  • Text editor, markdown
  • Add metadata
    • Depends
    • FrontMatter – e.g. keyword/values in +++ section
    • Separate files

Choosing a Generator

  • 200+ different generators
  • Potential criteria
    • Engine language
    • Templating language
    • Simplicity vs. Customization
    • Extensibility
    • Frontmatter Support


  • Jekyll
    • Pro: Support, themes, features
    • Cons: Difficult setup, bad support for Windows
  • Hugo
    • Pros: Fast, Support, Themes
    • Cons: No extensibility
  • Harp
    • Pros: Simple
    • Cons: No extensibility, no frontmatter
  • Gatsby/Phenomic
    • Pros: React, PWA, Momentum
    • Cons: React, Young (you might not like React)

How Do I Host?

  • Existing infrastructure – drop the files on the server
  • Amazon S3
  • Dropbox – public folder
  • Github Pages –
  • Dedicated Static Hosts (surge, Aerobatic)


  • Features
    • Run builds
    • Free custom domains
    • Free SSL
    • Baked-in CDN
    • Free Pro upgrade for open source projects

When Should You Go Static?

  • Blogs
  • Online magazine (large site)
  • Portfolios
  • Brochures
  • Docs
  • Style Guides
  • Events

JAM Stack

  • JavaScript
  • APIs
  • Markup

JAM Stack Examples

  • Forms – Google Forms, TypeOne
  • Commerce – SnipCart
  • Site Search – Lunar.js
  • User Data – Firebase – offload user data to somebody else
  • Serverless – functions as a service – Azure Functions, Lambda Services,
  • See

Supporting Content Authors

  • Need visual authoring tool for content generators (non-technical)
  • Text Editor
  • Headless CMS – CMS as a service
    • Without headless CMS – .git repo feeds generator
    • With headless CMS – feed static generator from headless CMS in cloud
  • Contentful – still have to write markdown
  • Netlify CMS
    • Integrates with .git
    • Drop something in your repository
    • Uses GitHub authentication to log into CMS (admin page)
    • Content saved to your repository
    • Integrates nicely with Netlify

The Static Web Revolution

  • New way – more modular, smaller tools that each does a different thing

That Conference 2017 – Continuous Database Deployment

That Conference 2017, Kalahari Resort, Lake Delton, WI
Continuous Database Deployment – Mike Acord

Day 2, 8 Aug 2017

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2017 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Executive Summary

  • Important to have database assets under source control
  • Several different strategies, each with pros/cons
  • Most likely approaches–schema-based or script-based

Continuous Deployments

  • We continuously deploy our code
    • Automated deployments
    • Integration tests
    • Build pipeline
  • But we’re not doing this with databases
    • More difficult
    • Harder to avoid losing data
    • More risky

Databases – Instead

  • Manual change scripts
  • Schema comparisons (SQL Compare)
  • Create change script, run against database
  • Problems
    • Error prone
    • Risky
    • Slow

What Is Continuous Database Deployment

  • Automated deployments
  • Integration tests
  • Build pipeline
  • Diagram
    • Database should be in source control
    • Trigger from changes in CM leads to Continuous Integration
    • Leads to Release Management
    • Staged releases–QA, Test


  • Less error prone, more repeatable
  • Anybody can do this
  • Testable–deploying to different environments
    • At each phase, you’re re-testing the deployment script
  • Faster to release
  • Easier to merge branches
    • Work item has unique code and unique database changes
  • Easier to refresh environments
    • And easier to refresh to different environments
    • Stuff already in DEV, ready to go


  • Schema-based
    • Current schema is always in source control
    • Script in CM for every object in your database
  • Script-based
    • Change scripts checked in and applied
    • You just create a delta script
    • Never have full history
  • Code-based
    • Apply database changes from code
    • E.g. Migrations in .NET

Schema Based

  • Provides history of schema
  • Can generate change scripts to reverse changes
  • Less likely to screw up change scripts
  • Compare and sync schema to deploy changes
  • Can make to database and sync back to model
    • Can generate blank database at an point
  • Challenges
    • Merging can be challenging
    • Black voodoo magic leads to nasty change scripts
    • Deployment process is more complex
    • Forget to check in changes and lose them

SQL Source Control

  • Shows changes
  • Create migration scripts
  • Deals with situation of adding non-nullable columns

Visual Studio Database Project

  • SQLCompare utility to apply schema changes


  • Octopus Deploy used to deploy changes
  • Creates Powershell scripts (or uses scripts)
    • Applying .dacpac files using SQL Package cmd line tools
  • NB: RedGate has plugins to SQL Source Control for various CI tools

Script Based

  • Create change scripts to apply
    • Script for every change
  • Simple to understand
  • Easy to implement
  • No black magic
  • Easy to test scripts
  • Challenges
    • May need to review change scripts
    • No ‘current’ database that you can deploy
      • Backup/restore to get copy of current

Example – DBUP + Octopus Deploy

  • Storing migration scripts in DB project
  • DBUP uses LOG in database to see what needs to be run; applies migration in order
  • Also then applies environment-specific scripts

Code Based

  • Quick setup for new developers
  • Allows for seed data
  • Simple to use
  • Can generate change scripts
  • Challenges
    • Testing changes can be awkward
      • Hard to test because migration only happens in the context of running your app
    • May feel unnatural
    • Rolling deployments more challenging
      • One app does the update, but other apps aren’t yet up to date

Example – Entity Framework Migrations

Database Refresh – Keep Data Current

  • Quickly refresh environments from production
  • Can be scheduled to happen daily
  • Allows better diagnosis of data issues
  • Daily testing of deployment scripts
    • By virtue of pushing between DEV / STAGE / PRODUCTIOn
  • Challenges
    • Clustered servers
    • Large databases
      • Can be painful, >1TB

Example – Database Refresh

  • Using Octopus Deploy

Best Practices

  • Create backups or snapshots before doing anything else
  • Avoid data loss
  • Automated integration tests
  • Deploy breaking changes in steps
  • Example (field rename)
    • Add new field with synchronization trigger
    • Modify application to use new column
    • Remove old column and synchronization trigger
  • Do this in stages when you can’t take time window to do everything at once
  • Lots of patterns for applying changes in non-breaking patterns like this
    • Book – Refactoring Databases


  • Problem with database project – comparing two schemas, scripts that it generates just don’t work
    • Turn on setting to catch errors on project build

That Conference 2017 – Concurrent Programming in .NET

That Conference 2017, Kalahari Resort, Lake Delton, WI
Concurrent Programming in .NET – Jason Bock (@JasonBock)

Day 2, 8 Aug 2017

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2017 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Executive Summary

  • Doing concurrency correctly is very hard when doing it at a lower level
  • Don’t use Thread, ThreadPool anymore
  • Learn and use async/await


  • Concurrency is tough, not as easy as doing things sequentially
  • Games are turn-based
    • But interesting exercise to do chess concurrently
    • Much more complicated, just as a game
  • We’ll just look at typical things that people struggle with


  • Concurrency – Work briefly and separately on each task, one at a time
  • Parallelism – People all working at the same time, doing separate tasks
  • Asynchronous – One you start a task, you can go off and do something else in the meantime


  • Stop using Thread, ThreadPool directly
  • Understand async/await/Task
  • Use locks wisely
  • Use concurrent and immutable data structures
  • Let someone else worry about concurrency (actors)

Stop Using Thread, ThreadPool

  • This was the way to do concurrency back in .NET 1.0
  • Diagram – Concurrent entities on Windows platform
    • Process – at least one thread
    • Thread – separate thread of execution
    • Job – group of processes
    • Fiber – user-level concurrent tasks
  • But mostly we focus on process and thread
  • Example–multiple threads
    • Use Join to observe at end
  • Problems
    • Stack size
    • # physical cores
  • # Cores
    • May not really be doing things in parallel
    • More threads than cores–context switch and run one at a time on a core
    • Context switches potentially slow things down
    • Don’t just blindly launch a bunch of threads
  • Memory
    • Each thread -> 1 MB memory
  • ThreadPool is an improvement
    • You don’t know when threads are complete
    • Have to use EventWaitHandle, WaitAll
    • Lots of manual works
    • At least threads get reused
  • Existing code that uses Threads works just fine


  • Models
    • Asynchronous Programming Model (APM)
    • Event-based Asynchronous Patter (EAP)
    • Task-Based Asynchrony (TAP)
  • Demo – console app
    • AsyncContext.Run – can’t call async method from non-async method
    • AsyncContext – from Stephen Cleary – excellent book
    • This goes away in C# 7.1 – compiler will allow calling async method
    • Reading file
  • Misconception – that you create threads when you call async method
    • No, not true
    • Just because method is asynchronous, it won’t necessarily be on another thread
  • Use async when doing I/O bound stuff
    • Calling ReadLineAsync, you hit IO Completion Point; when done, let caller know
    • When I/O is done, calling thread can continue
    • Asynchronous calls may also not necessarily hit IOCP
  • If you do I/O in non-blocking way on a thread, you can then use thread to do CPU work while the I/O is happening
    • Performance really does matter–e.g. use fewer servers
  • When you call async method, compiler creates asynchronous state machine
    • Eric Lippert’s continuation blog post series
  • Task object has IsCompleted
    • Generated code need to first check state to see if task completed right away
  • Good news is–that you don’t need to write the asynch state machine plumbing code
  • Can use Tasks to run things in parallel
    • Task.Run(() => ..)
    • await Task.WhenAll(t1, t2);
  • Tasks are higher level abstraction than threads
  • Don’t ever do async void
    • Only use it for event handlers
  • Keep in mind that async tasks may actually run synchronously, under the covers

Demo – Evolving Expressions

  • Code uses all cores available


  • Don’t use them (or try not to use them)
  • If you get them wrong, you can get deadlocks
  • Don’t lock on
    • Strings – You could block other uses of string constant
    • Integer – you don’t lock on the same thing each time, since you lock on boxed integer
  • Just use object to lock on
  • Interlocked.Add/Decrement
    • For incrementing/decrementing integers
    • Faster
  • Tool recommendation:
  • SpinLock
    • Enter / Exit
    • Spins in a while loop
    • Can be slower than lock statement
    • Don’t use SpinLock unless you know it will be faster than other methods

Data Structures

  • List<T> is not thread-safe
  • ConcurrentStack<T>
    • Use TryPop
  • ImmutableStack<T>
    • When you modify, you must capture the new stack, result of the operation
    • Objects within the collection can change


  • Service Fabric Reliable Actors
  • Benefits
    • Resource isolation
    • Asynchronous communication, but single-threaded
      • The actor itself is single-threaded
      • So in writing the actor, you don’t need to worry about thread safety

Demo – Actors – Using Orleans

  • “Grains” for actors

That Conference 2017 – Refactoring Monolith Database Stored Procedures

That Conference 2017, Kalahari Resort, Lake Delton, WI
Refactoring Monolith Database Stored Procedures – Riley Major (@RileyMajor)

Day 2, 8 Aug 2017

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2017 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Executive Summary

  • Re-factoring large stored procedures helps with testability, comprehensibility, performance
  • Main strategies–reorganize, factor out pure business logic into UDFs, do updates at the end
  • Testing strategy–use transactions to undo test calls to before/after versions of stored proc, store data to compare in table variables


  • Evolves over time
  • Long
  • Does multiple things
  • Disorganized
  • Fragile
  • Untestable
  • Scary

Layers, Like an Onion

  • Programming layers
    • Presentation
    • Business Logic
    • Data Storage
  • Tiers
    • Client app (HTML)
    • Server (ASP.NET)
    • Database (SQL Server, NoSQL)
  • Best Practice
    • Presentation in client application
    • Business Logic in server

Oh Noes!

  • Monolith
    • Presentation in database
    • Business Logic in database
  • Bad
    • Database scaling is hard
    • Causes vendor lock-in
    • Database languages are primitive
  • But
    • Close to data, less overhead
    • Who really changes databases?
    • SQL more powerful than you think
      • Could be faster to make changes to multiple tables down in the database

Turtles All the Way Down

  • Separate layers even on the same tier
    • Browser: MVVM
    • Server: MVC
    • Database: TBD
  • Database layer
    • Presentation / Business Logic
      • IF / CASE / SET / SUM / DATEADD
      • If this logic is going to be here anyway, we should try to architect it
    • Data access
  • Testability, Isolation, Portability
    • Reasons to structure bus logic in database

Make a plan

  • What are goals?
    • Better performance?
    • Maintenance?
    • Understandability?
    • Testability?
  • How will you know you’ve achieved the goals?
    • Speed benchmarks
    • Less repetition
    • Smaller sections of code
    • Actually having a testing suite

Survey the damage

  • Can’t avoid a thorough code review
  • Look for data modification
    • Note columns affected
  • Look for external effects
    • CLR
    • E-mail generation
    • SPS: Triggers
  • Look for transaction handling
    • Harder to re-factor if existing code uses transactions
    • Can have nested transactions
    • Rollback goes all the way up the stack

Don’t Break Anything

  • Build a development environment
    • Need to be able to play around
    • Need realistic data (volume and content)
    • Maybe not real data
  • Work in isolation
    • Were changes the result of you or somebody else?
    • You really need to isolate your changes
    • Slow because resources being used elsewhere?
  • How can you tell if you broke something?
    • Need to capture before and after state
      • Look across entire database potentially
    • Aim for deterministic process
    • Easy to know if you broke it if you know what it’s supposed to do


  • Function returns the same result, given the same inputs
  • Easy to test – send same values in before/after your changes
  • Things that break determinism
    • Random numbers
    • Time
    • Pulling data from database (underlying table’s contents can change)

Play It Again, Sam

  • Why we want determinism–so you can compare data before/after your changes

Good Luck with That

  • (Monolith stored proc) Likely not deterministic
  • Monoliths change state
  • Need to go back in time
  • Can use transactions to do this
    • Revert to previous state

Become a wrapper

  • To test impact of code changes, wrap your calls
    • Begin transaction
    • Run original code
    • Capture changed data
    • Rollback
    • Run new code
    • Capture changed data
  • Compare the 2 captured data sets


  • But need to save changes somewhere
  • Captured data is also rolled back
  • Need to preserve the changes that you captured, even during rollback
    • Could save to local storage
    • Could save to another database
    • Print results to database console

Build a Ghost House

  • How capture doomed data?
    • Outside SQL Server–hard
    • Another thread with NOLOCK–hard
  • What’s immune from transactions?
  • Variables
  • You can’t have a variable for every row
  • One big XML? Ouch
  • Table variables survive transactions
    • Written to disk, but not stored to database
  • They’re ghost houses

Spooky Playground – Create House

  • DECLARE @Orders TABLE (Field1 int, Field 2 int);
  • Could use tricks here–store checksums or hashes instead of actual data
  • Typically create one table variable for each DB table that will get changed
    • And set only the columns that you expect to change

Spooky Playground – Fill House

  • BEGIN TRAN; EXEC monolisth;
  • UPDATE @Orders SET x = x FROM Orders
  • BEGIN TRAN; EXEC monolith_New

Spooky Playground – Compare

  • SELECT * FROM @Orders WHERE colA_Before <> colA_After

Mock Your Black Boxes

  • Transactions only work on the database
  • External effects aren’t rolled back
  • Replace external calls with “mocks”
  • They look and act like external calls
  • But you control the guts
  • Return hard-coded sample data
  • Have the mock log its inputs
    • You’ll need to see what was sent, to make sure it would have done the same thing

Make your time!

  • Date/Time functions kill determinism
  • You have to control “now”
  • Otherwise no two runs could be the same
  • So make your own time
  • And send it in as a parameter
    • Feed the monolith the current date/time

Your Petard Should Hoist

  • Move variable DECLAREs to the top
  • Reveals duplication
  • Reveals common data sources
  • Displays breadth of data required
  • Caution: DECLARE assignment
    • Leave SET down below when you pull the DECLARE up

One SELECT to Rule them All

  • Gather scattered SELECT statements to top
  • Reveals duplication
  • Prepares for separation
  • Prepares for shorter transactions
  • Use single SELECT with fancy SQL, if practical

Measure Twice, Cut Once

  • Replace with variables SETs
    • Store what these statements were supposed to do
  • Move data modification to end of proc
    • Shrinks amount of time when transactions are open
  • Results in 3 main sections
    • Data gathering
    • Computation
    • Data modification

Cases of CASES

  • What’s left in middle? Logic
  • Lots of Ifs, SETs, and calculations
  • Pull it all together in one giant statement
  • Usually performs better
  • Can be clearer
  • Can reduce code
  • Prepares for separation
  • CASE, Derived Tables, and CTEs are your friends

Building Blocks

  • Still one procedure = still a monolith
  • Separate
    • Data Gathering – inline UDFs
    • Calculation – inline UDF
  • Allows data gathering re-use
  • Allows testing suite for business rules
  • Allows read-only monolith actions
    • Most important benefit
    • Can tell people what the business logic will do
    • Data in, data out
    • May want to use this function elsewhere

It’s All Better Now

  • Reformed monolith
    • Recently written
    • Short
    • Orchestrates multiple things
    • Repeated code eliminated
    • Organized into functions
    • Vials of reagents to mix – based on pieces
    • Problems isolated
    • Testable
    • Bening–not scary

Note on functions

  • Scalar user-defined functions in SQL Server perform much worse than inline table-valued user-defined functions
  • Treated like the engine just like a view
  • Especially bad performance when you use result of a scalar function in a WHERE clause
  • Other problems with multi-statement table-valued function

Demo – Walk through this process

  • Mock out stored proc that sends e-mail
    • Just store input data
  • To test encapsulation, run monolith twice, in transaction
    • You’ll see differences for non-deterministic stuff, e.g. dates
  • Need to look through the differences and resolve them
    • e.g. by feeding in date as procedure
    • Make copy of Monolith, but change only the date parameter business
    • If you now see now results, it’s now deterministic
  • Now start re-factoring, but create different versions of the monolith
    • e.g. Monolith_HoistVariables
    • Move variable DECLAREs up to top
  • Beware of false positives
    • You might see no differences, but that could be due to having no data in database that exposes a bug that we just created
    • SPS: Or that test data doesn’t cause execution of a path where a bug is fixed
  • CROSS APPLY as performance improvement
    • Create new record sets on the fly
    • This is performance efficient
  • Do one UPDATE at bottom to make all of our changes
  • Move multiple IF statements into single bit SELECT statement
    • Keep re-running the compare harness, continue seeing no changes after compare
  • Move hard-coded strings into function that returns table having named columns with constant values
    • No performance hit to do this
  • Pull many statements together into one big SELECT
    • Can then move into its own UDF
  • Make giant list of test data
    • Then use CROSS APPLY to pass this data into new UDF
    • Can then do regression testing
    • After future changes, you can say explicitly what’s going to break (change)

That Conference 2017 – The Rise of JavaScript-Driven Native App Development

That Conference 2017, Kalahari Resort, Lake Delton, WI
The Rise of JavaScript-Driven Native App Development – Rob Lauer

Day 1, 7 Aug 2017

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2017 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Executive Summary

  • Web apps not performant enough, native apps too hard to implement
  • Hybrid apps too much of a compromise
  • Xamarin just “1st-gen”
  • Move toward React Native / NativeScript
  • NativeScript comes with a bit more “out of the box”

Rob Lauer – @RobLauer

  • Senior Manager, Developer Relations
  • Progress (Telerik)

Two things

  • JavaScript-Drive Native
  • NativeScript

Covering today

  • Rise of “JavaScript-driven Native”
  • Intro to NativeScript
  • NativeScript core concepts

Environment for apps

  • Native apps are in silos, for the various platforms

Cross platform options

  • Mobile Web – PWA (Progressive Web Apps)
    • Mobile-first web site, or mobile variant
  • Hybrid – leveraging web view on device (e.g. Chromeless browser)
  • 1st gen X-Plat Native
    • e.g. Xamarin
  • Native

Not available to web app

  • Offline support
  • Device APIs
  • Home screen availability

Hybrid Promise

  • In between native and full web
  • Reuse web skills
  • Rich UI
  • Supposed to be best of both worlds
  • It’s basically a set of compromises

Hybrid Problems

  • Lots of press talking hybrid apps down

Hybrid Reality

  • 50% dev time doing first 80%
  • Another 50% doing final 20%
  • Need to tweak things because of bad performance

Binary choice

  • Hybrid vs. Native
  • Hybrid
    • Fast to market
    • Compromise on UX
  • Native
    • Best experience
    • One platform at a time

Pie chart

  • How important is mobile app performance
  • 80% somewhat/very important

If user perceives poor performance

  • Switch to another app, etc.

Third choice

  • Native JavaScript
  • Native UI driven by JavaScript
  • App runs in JavaScript engine, bridge to native

Biggest JavaScript Native

  • React Native
  • NativeScript (Progress)
  • Other smaller ones
    • Weex
    • FuseTools
    • Flutter

React Native vs. NativeScript

  • Both work in similar way
  • Native UI, Native APIs running on JavaScript engine
  • NativeScript – write once
    • Plugins created with JS/TypeScript
    • On Day 0, NativeScript ready to go
    • Single-threaded (UI thread)
  • React Native – write API wrapper for each platform
    • React support
    • API access via native modules (you write)
    • UI Thread vs. JavaScript Thread
  • Performance between the two is very similar

{N} vs RN

  • React vs. Angular/Vue/Vanilla
  • Progress vs. Facebook
  • BSD (RN) vs. Apache
  • Community – RN community is bigger

JavaScript-Driven Native

  • Faster to market
    • Reuse existing skills
    • Reuse existing libraries
  • Best experience
  • True native UI


  • Progress/Telerik still supporting the idea of Xamarin and cross-compiled web apps
  • e.g.

Intro to NativeScript

  • Timeline – 2013 to 2017 (mass adoption)
  • npm downloads going up
  • Ionic still dominant
  • RN and {N} battling it out

What is NativeScript?

  • Open source framework
  • Native mobile for iOS, Android (eventually Windows 10)
  • Use web skills
  • Write once, run everywhere
    • Share 100% code between iOS/Android
    • Share 80% code with web – can easily port Angular, but just rewrite view


  • No compromise UI
  • Measurable native UI performance
  • Maximum code and skill reusability
  • Reuse existing native libraries

How Does NativeScript Work?

NativeScript Module Layer (NML)

  • Abstractions on top of native APIs
    • Dozens available out of the box
    • All native APIs still available at JavaScript layer


  • Application Code  (can occasionally hit NativeScript Runtime)
  • NativeScript Modules
  • NativeScript Runtime
  • iOS / Android at bottom

Putting It All Together

  • Define UI with Markup
  • Back-end logic is JavaScript
  • CSS

Architecture choice

  • JavaScript
  • TypeScript
  • Angular

First App

  • npm install
  • tns run iOS
  • tns run android

NativeScript LiveSync

  • Refresh app with latest changes to JS, CSS, XML
  • No re-build
  • Works with emulators and devices

Demo – Simple  NativeScript App

  • tns create myapp
  • main-page.xml
    • A few HTML elements, though custom Telerik


  • XML markup structure
  • Elements (<Page>, <Label>) are NativeScript modules
    • Cross-platform abstractions
    • E.g. <switch>
  • Lots of UI Widgets out of the box

Layouts (Traditional)

  • Layout containers
    • Absolute
    • Dock
    • Grid
    • Stack
    • Wrap
  • Power comes from when you start nesting layout containers inside of each other
  • Also provide Flexbox

Custom XML Components

  • Custom controls
  • Encapsulate reusable UI in components
  • Can be JS only or XML + CSS + JS

Platform-Specific Capabilities

  • File naming:, xxx.ios
  • Markup: chunks – <android>,
  • Attributes: android:blah, ios:blah
  • Write once by default
    • But can customize per target

Styling with CSS

  • Conventions
    • App.css
    • Myview.css
    • Myview.ios.css

Supported Selectors

  • Element Type, class, id

Sass and LESS Available

UI Components

  • Nativescript-ui

JavaScript Code Behind

  • Vanilla JavaScript
  • Built-in MVVM pattern
  • Angular support
  • TypeScript support

Handling Events

  • Create event handlers in JavaScript

Navigating Views


  • Navigating with topmost

View Transitions

  • Standard, e.g. curl

Data Binding

  • Available out of the box
  • Two-way


  • Animate – various properties
  • Configured – props
  • Chain animations
  • Animate multiple properties and elements

Custom Fonts

  • TTF or OTF
  • Drop-in

Debugging Strategies

  • Console.log
  • Developer Tools – e.g. Chrome DevTools
  • IDE – e.g. Visual Studio and Visual Studio Code
  • Free extension for Visual Studio Code

Anything Else?

Two Ways to use

  • Command Line Interface (CLI)
  • NativeScript Sidekick
    • Builds on top of CLI
    • Services like cloud-based builds
    • Cross-platform
    • Starter kits, app templates
    • Plug-ins management
    • Visual Studio integration coming

What about Angular?

  • Unified app concepts across web and native mobile



Bottom Line

  • No web views (platform native UI)
  • Use JavaScript (or TypeScript)
  • 100% access to all native APIs
  • Made for web devs (JS, CSS, XML)
  • Use Angular for web and ntive mobile
  • Reuse thousands of libraries from Node/iOS/Android/Web


That Conference 2017 – React Native: The Good Parts

That Conference 2017, Kalahari Resort, Lake Delton, WI
React Native: The Good Parts – Stan Bershadskiy

Day 1, 7 Aug 2017

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2017 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Executive Summary

  • Native app is a very different experience than web app
  • You get way better performance with native app
  • You get better development experience when working in React
  • React Native gives you best of both worlds–good development experience and best performance

Stan Bershadskiy

  • Architect at Modus Create
  • Author of React Native Cookbook
  • Working with React Native >1.5 yrs

React Native Cookbook

  • From UI to deployment
  • Not just “how”, but “why”


  • Product Studio
    • Consulting company
    • Specializing in mobile and web apps
    • Globally distributed agile teams
  • Community leaders
    • Published authors and conference speakers
    • Partners with GitHub et al

Mobile Apps Today

  • Split into three groups
    • Native
      • Excellent performance, slow development
    • Web/Hybrid – PhoneGap, Cordoba, Ionic
      • Easy development, terrible performance
      • HTML5/JS is not the solution for fast native apps
    • Cross Compiled – Xamarin, Titanium
      • Meh, dinosaur
      • Most people moving away from this world

We want, of course, good performance, quick development

React Native

  • A framework for building native mobile apps using JavaScript
  • JavaScript runs in interpreter on the platform
  • Different from cross-compiled, which compiles down to native

React’s Core Dependency

  • React.js


  • Parts
    • JSX – Describe the UI
    • Virtual DOM – Efficiently batch and schedule rendering
    • Lifecycle – Control how components render

How Does React Work?

  • View Declaration (JSX) -> Virtual DOM -> Target Platform
  • Initial phase – componentWillMount, render, componentDidMount
  • Update phase – shouldComponentUpdate, render, componentDidUpdate

React’s New Core Algorithm

  • Fiber – will also be in React Native (next version)

React Native

  • Parts
    • React – declarative goodness
    • Bridge – communication between JavaScript and native threads
    • Native UI SDK – Render Native UI elements on the main thread

How Does React Native Work?

  • JavaScript thread
    • Has event loop (60 fps)
    • JS Call – delegates to main thread, which does Native Call
  • Main thread
    • Renders to the UI
    • Main thread is never blocked, so UI responsive

The Good Parts

Layout System

  • Yoga
  • Flexbox and Absolute positioned layout system written in C++ to achieve maximum performance
  • Some parts written in assembly
  • Similar to web standards

Animated API

  • 60 fps goodness
  • Create Animated Values of a type that wrap components
  • Values can be composed in parallel, sequence or other variations
  • Animations can be executed on the native thread for increased performance
  • Native thread can kick off sub-thread on which to do the animation calculations. So UI isn’t blocked

Animated API Examples

  • React-Native-Foldview
  • Twitter Exploding Hearts
  • Can now export Adobe (something) Effects into React Native

Native Module Bridge

  • Native Made Easy
  • Easily expose native functionality and native UI components to be used by React Native

It’s Just JavaScript

  • Answer to anything is probably on Stack Overflow
  • All your business logic likely going to be implemented in JavaScript

Commonly Used JS Modules

  • Redux – state container
  • Lodash – looping
  • Moment – simple date manipulation


  • This is the most important thing
  • Facebook and the Community as a whole work hand in hand to further the development of React native.
  • >50% of commits come from the community

Community Contributions

  • Expo(nent) – app development platform
  • React Navigation – navigation made simple (finally)
  • RNPM – Simple linking of native modules

The Not-So-Good Parts


  • “Hope you like reading diffs”
  • But it’s not critical that you upgrade immediately
  • If you’re actively developing, you could keep up with latest versions
  • But if further into lifecycle, don’t need to upgrade constantly


  • Dealing with Native Android code is no fun
  • Device and version fragmentation cripples the development experience
  • Tons of devices, tons of Android versions
  • “Tread lightly”
  • Suggested starting with Android first, since once it works there, you know it will work on iOS

Development Mode

  • Apps work much slower in development mode, especially Android
  • But much faster in production mode

Where does React Native Belong?

  • Target platforms
    • iOS
    • Android
    • Apple TV
  • More
    • Universal Windows Platform – Surface tablets, Xbox One
    • Mac OS
    • Linux
  • Few more
    • Virtual Reality – Oculus (React VR)
    • Web – but Stan doesn’t recommend it
    • Other–just needs to run JavaScript interpreter in C++

React Native in the Wild

  • Skype
  • AirBnb
  • Instagram – recently switched over to React Native – claimed better velocity

Building Your Next App


  • Stan’s book
  • React Native Docs
  • GitHub issues page

Create React Native App

  • Simple platform-independent way to get up and running
  • Can push updates to your app while in production (if JavaScript)
    • e.g. Microsoft CodePush

Standard Way

  • Start with native IDE
    • Xcode
    • Android Studio
    • javaScript IDE
  • Still need to know how to go through deployment cycle on each platform

Best Practices

  • Render() – keep as lean as possible
  • Bridge – be mindful of data you send across bridge
    • Bridge has to serialize the types, so be careful of large blobs of data going across
    • To do complicated data manipulation, e.g. transfer megabytes, do this on the native side

First Use of React Native in Production

  • Facebook Groups
  • Ads Manager 2nd