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


Benefits

  • 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


Methods

  • 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


Example

  • 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
    • Agiledata.org/essays/renameColumn.html
    • Book – Refactoring Databases


Questions

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

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


Background

  • 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


Terms

  • 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


Recommendations

  • 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


Async/Await/Tasks

  • 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


Locks

  • 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: benchmark.net
  • 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


Actors

  • 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


Monowhat?

  • 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
      • SELECT / UPDATE / INSERT / DELETE
  • 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
    • INSERT, UPDATE, DELETE
    • Note columns affected
  • Look for external effects
    • CLR
    • E-mail generation
    • SPS: Triggers
  • Look for transaction handling
    • BEGIN TRAN, COMMIT, ROLLBACK
    • 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


Deterministic

  • 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


Oops

  • 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
  • ROLLBACK
  • 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

  • Find INSERT / UPDATE / DELETE
  • 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

Xamarin

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

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

Differentiators

  • 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

Architecture

  • 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

Pages/Views

  • 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.android, 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

Basics

  • Navigating with topmost

View Transitions

  • Standard, e.g. curl

Data Binding

  • Available out of the box
  • Two-way

Animations

  • 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

Community

  • Plugins.nativescript.org
  • Forum.nativescript.org

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”


Modus

  • 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


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


Community

  • 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


Upgrading

  • “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


Android

  • 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


Resources

  • 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

That Conference 2017 – Intro to Docker

That Conference 2017, Kalahari Resort, Lake Delton, WI
Intro to Docker – John Ptacek

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

  • Docker containers make deploying a running application easier and more repeatable
  • Tooling exists to deploy to Azure or AWS
  • Microsoft is definitely pushing Docker as a unit of deployment

Docker

  • Not a programming language
  • Not a framework

 

What Docker Is

  • Virtualization technology
    • Server -> VM -> PaaS -> Containers
  • Tool for software
    • Installation, removal, upgrading
    • Distribution
    • Trusting
    • Managing

 

Docker

  • Automates setup/configuration development environments
    • E.g. Far quicker to get up and running with a typical server environment
  • Happy pplace for developers and infrastructure
    • Avoids typical friction between devops and devs
  • Analogy for shipping containers
    • Contains everything you need; container moved from place to place
    • Encapsulation
  • Native for Linux
    • Linux’ containerization strategy became starting point for Docker
  • Installs for OS X and Windows
    • But a bit finicky sometimes
  • It’s Plug In Software (rather than installed software)
    • If it works on your dev machine, it will work anywhere

 

Why Docker?

  • Resource efficiency
    • 26-1 perf improvement over VM
  • Speed
    • Smaller units, quicker build/deploy
    • Leads to talking about microservices
  • Agile
    • Still virtualization, Ship Code containers (ship containers)
  • Lightweight
    • Just Enough OS – only the bits you need in the OS are turned on
  • Consistency
    • Portability and reproducibility. DockerFile, not Click
    • Not relying on how somebody does a particular install or configuration
    • Works on my machine, then it works
  • Microsoft says so
    • Microsoft is moving a lot of stuff towards Docker
    • SPS: How does this strategy fit in with Azure architectures
  • SharePoint story
    • Get things set up at home, but then have trouble rolling out SharePoint on customer’s server
    • Because they don’t necessarily have the same stuff enabled on their server
  • Environmental Drift
    • Avoids having to set up big dev environment to go back and support something from several years ago
    • Docker allows entire environment to be easily reproduced, using Docker File
  • Cattle, not pets
    • Care and feeding that happens when you set up server – pets
    • With cattle, you don’t care that much if one of the servers drops out

 

Things

  • Containers are not virtualization, as we know it
  • Containers can be thought of as shipping containers
    • Everything embedded that you need
  • Containers contain images
  • Images are bundled snapshot
  • Images are deployable
    • Can spin up in Azure, AWS, Google, or in-house
    • Can also move these between platforms
    • Containers don’t tie you to platform
  • Compatibility between Oses
    • Build on OS X, run on Windows
  • What app store did for mobile
    • Docker like multi-platform app store for developers
  • Finicky for OS X and Windows
  • Security by isolation from OS
    • Can’t get from container back to host operating system
    • Helps manage risk
  • Images – immutable file system with execution parameters
  • Containers – instantiations of images (running or inactive)

 

Demo – Simple node.js application

  • Sends a message to console

 

Running it

  • Can run on dev box directly, i.e. running Node

 

Running with Docker

  • Dockerfile – contains instructions for how to run within container
    • Pull down Node
    • Make a directory for app, one for user
    • Do npm install for dependent packages
    • Copy source code down
    • ENTRYPOINT – Says the command to run to start up container
  • .dockerignore – what not to bring down
    • e.g. node_modules
  • Build the container
    • docker build – it runs through docker file and sets everything up
    • At the end, it gives you a number
  • The container exists on the dev machine at this point
  • Now run this image
    • Can map docker’s port to port on host machine
    • docker run
    • Can hit the site at the new port
  • Log on to container
    • docker exec – runs bash shell
  • docker ps
    • List images that are running

 

Demo 2 – Calculating Pi

  • Running locally – spits out a bunch of debug info to console
  • docker run – can run in container
  • Winston logger
    • Log out to directory
    • Can log to external location
  • Typically, you wouldn’t persist data to the Docker container
    • Because the data is lost when you power down the container
    • You’d typically persist data elsewhere

 

Deploy container to production server

  • DockerHub – place for you to deploy your applications to
    • It’s not production yet
  • First, test on your local machine
  • Publish to DockerHub – docker login
    • Tag the image that you created/tested
    • docker push – push to docker hub
  • Push to production, e.g. Azure
    • Docker Container settings in Azure
  • Should work the same on Azure
    • Typically takes 10-15 mins to deploy out to Azure
  • Can do the same for AWS–deploy the same container to AWS
    • “A bit more painful”
    • Use AWS command line tools (you have to install them)
    • Quirky to get push to work
  • Could even envision running the same app on both AWS and Azure
    • More flexibility to react to down time

 

Things

  • Docker pull – pull image from docker hub
  • Docker run – run an image
  • Docker images – list images
  • Docker ps – list all running containers
  • Docker rm – delete docker container
  • Docker rmi – delete docker image

 

Questions

  • More than just Azure and AWS?
    • Yes, e.g. Google, or could build infrastructure in-house
    • But simpler to deploy to Azure or AWS
  • (Sean): Would you typically run SQL Server inside a Docker container?
    • Yes, you can definitely run SQL Server in a Docker container
  • Difference between container and image?
    • Container is sort of the definition of what needs to run, immutable
    • Images are the pieces that start up
    • The image is the running instance
  • If I have various configurations for different environments, how does Docker file manage this?
    • Yes, could use environment variables that get read in the dockerfile
  • Why do you do node:latest, won’t this lead to trouble in the future?
    • In production, you’d want to hard-code a version that you know works for you

That Conference 2017 – SASS and CSS for Developers

That Conference 2017, Kalahari Resort, Lake Delton, WI
SASS and CSS for Developers – Robert Boedigheimer

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

  • Use CSS for styling your web site
  • SASS makes writing CSS much easier
  • Lots of great constructs for modern UI in both CSS and SASS
  • Some good 3rd party libraries out there (e.g. Bourbon)

About Me

CSS

  • Cascading Style Sheet
  • Describes presentation of a document

Why CSS?

  • Site-wide changes by modifying the styles
  • Support multiple views
  • Leaner pages
  • http://Csszengarden.com
    • Shows how difference style sheets leads to radically different views

Style Rule

  • Selector
    {
    property: value;
    }

Using CSS

  • Inline
    • Style attribute directly on elements
  • Embedded
    • Styles at top of page in <head>
  • External style sheet
    • Style rules collected in .css file
    • Include via <link>
    • (Almost) always do it this way

Cascading

  • Inline first, then top of page, then external

Basic Selectors

  • Element, e.g. h1, div
  • Id
    • #idName
  • Class
    • One or more elements can have this class value
    • .classname

Pseudo Elements and Classes

  • Styles not based on document structure
  • Begins with colon
  • E.g. Style around focused element
    • a:focus { …

Inheritance

  • Elements from document parsed into tree based on structure
    • E.g. Apply style to body, inherited by <div>, <h1> in body

Colors

  • Named colors
    • 17 in CSS 2.1, 140 more in CSS 3
  • RGB

Box Model

  • Margin on outside
  • Border
  • Padding on inside

Common Techniques

  • Cursor
  • display:none – visibility, can turn on/off
  • text-transform – universally apply transform to text, e.g. all caps
  • z-index – overlapping, higher is on top
  • Non-scrolling areas

Reset or Normalize Stylesheet

  • Goal is to reduce browser inconsistencies
  • Reset – set default styles, apply everything yourself
  • Normalize.css – the same across all browsers

RB: Going to Bootstrap for all of our web properties now

CSS 3 Background

  • Series of “Modules”
    • Easier to manage than one big specification
    • Make for easier updates
    • Devices w/constraints can implement just modules that are appropriate to that device
    • Some considered part of “CSS Core”
    • www.w3.org/Style/CSS/

CSS 3 Browser Support

  • http://Caniuse.com
    • Can see which devices/browsers a particular element or feature works on

Browser/Vendor Prefixes

  • Browser vendors can create their own specific settings
  • For stuff not yet standardized
  • Once completed, these specific settings may be removed
  • e.g. grid-ms

Rounded Corners

  • Border-radius
    • e.g. on img
    • Can be different values on different corners
  • Can also use oval corner
  • (More the craze a while back)?

Opacity

  • Specify how opaque an element is
  • Ranges from 0 (fully transparent) to 1 (opaque)
  • F12 in browser, can emulate older versions of IE

CSS 3 Selectors

  • Attribute selectors
    • E{A=V]
    • E[A$=V] attributes ends V
    • Etc
  • input: invalid
    • If input element is invalid, apply this style

Web Fonts

  • Introduced in IE 5, was proposed for CSS 2
  • Watch licensing!
  • Watch FOUT (Flash Of Unstyled Text) and FOIT (Flash of Invisible Text)
  • @font-face

Google Fonts

  • Open Source fonts (600+)
  • <link> to fonts
  • Style-able with CSS
  • Free
  • Developers.google.com/fonts/
  • Fonts.google.com

How

  • <link> to Google site with fonts
  • font-family: ‘Lobster Two’
  • Can host fonts on your own CDN
    • Download the fonts
    • Convert to WOFF or WOFF2
  • Be aware, Google doesn’t display anything while font loading

Animations

  • Property changes in CSS values using keyframes
    • @keyframes AnimName
    • Specify percentages
      • “from” – 0%
      • “to” – 100%

2D Transforms

  • Animations using CSS transforms
  • Matrix translations
  • Transforms are render transforms, independent of layout

Media Queries

  • Media type and 1 or more expressions that check “media features”
  • For responsive design
  • Use
    • Width
    • Height
    • Color
    • Resolution
    • Orientation
  • E.g. Bootstrap
  • Question: Can I get <div> size?
    • No
    • But might be 3rd party package

Other CSS 3 Techniques

  • Box Shadows
  • Gradients
  • Text Shadows
  • Multiple Backgrounds Images
  • Word Wrap

RB: Note that we’re finally getting stuff like gradients and rounded corners at a time when de

Modernizr and Fallbacks

  • Modernizr – detects features in browser
    • Can do alternate method for some feature, e.g. use jQuery for opacity

General CSS Tips

  • Expirations
  • Rt-click, Inspect, Styles tab shows everything applied to an element
    • Can play around with different styles right in the browser

Sass

  • Syntactically Awesome Stylesheets, 2006
  •  CSS preprocessor
  • Sass in designer, compile step, converted to CSS
  • Two syntaxes
    • SCSS (Sassy CSS)  [this is the one you want]

Why Sass?

  • Provides programming concepts for CSS
  • Better organization
  • Reduced maintenance
  • Less vs. Sass
    • Very similar

Tools

  • Ruby – Sass gem
  • VS 2015
    • Web Compiler extension
    • Grunt
    • Gulp
  • Sassmeister.com
    • Experiment

Conventions

  • Myfile-gen.css (output file)

Major Features in Sass

  • Variables
  • _partials, @import
  • Mixins
  • Inheritance
  • Nested Rules and Properties
  • Functions

Variables

  • Avoid “Magic Values” (DRY)
  • $variableName: value;
    • e.g. $primaryColor: Red

_partials

  • Create files to organize SASS and styles in separate files
  • e.g. _variables.scss
  • Then @import “_variables.cscc”;
  • Then everything built into single big .css file
  • So HTML looks the same

Mixins

  • Set of declaratoins that can be reused
  • @mixin to define, @include to reuse
  • Parameters
    • Default values
    • Variable number
  • @content – pass declaration blocks

NB: Should still always look at your CSS to verify what’s getting generates

  • e.g. pay attention to size

Style Inheritance

  • Create classes that inherit from other classes
  • @extend .myBaseClass
  • Compiler will set up style for common stuff and apply to correct elements

Nested Rules and Properties

  • Just syntactic difference, embedding style in another style
  • Nested property
    • border-width generated by border: {width

Control Directives and Expressions

  • @if, @else
    • E.g. check $debugBuild
    • And set $imagePath to correct server
    • NB: for absolute URIs, start with just “//”
  • @for loop
  • @each statement to iterate through a list of items
    • CSS explodes into individual styles

Miscellaneous

  • Debug statements
  • Comments – can disappear or stay in CSS
  • Always modify .scss files, not .css files
  • Check CSS output CSS periodically
  • Minify

Frameworks/Mixin Libraries

  • Bourbon
    • Whole bunch of pre-written scss stuff
    • Only outputs to CSS what you use
  • Compass
  • Bootstrap
    • Switching to Sass/Scss