Use this link and code JAVAJAB to get 20% off your registration for FluentConf 2013! Panel David Herman (twitter blog Effective JavaScript) Ariya Hidayat (twitter github blog) Tim Caswell (twitter github howtonode.org) Jamison Dance (twitter github blog) Joe Eames (twitter github blog) Merrick Christensen (twitter github) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 00:48 - David Herman and Ariya Hidayat Introduction 044 JSJ Book Club: Effective JavaScript with David Herman 023 JSJ Phantom.js with Ariya Hidayat 01:54 - Parsing JavaScript and ASTs and Language Grammars 04:44 - Semantics 06:08 - Abstract Syntax Tree (AST) Esprima: Parser SpiderMonkey 10:37 - Lexer 12:16 - Writing your own language creationix / jack The C Programming Language 17:41 - Parser Generators JavaScriptCore 21:04 - Evolving a Syntax Automatic Semicolon Insertion Post correspondence problem Halting problem 28:05 - Language Design The Rust Programming Language 30:35 - Grammar Regular Expressions (Regex) Backus–Naur Form (BNF) Recursion How to Design Programs (HTDP) 38:00 - Recursive Descent Parsers 42:48 - Benefits of knowing language internals and syntax Apache Lucene - Apache Lucene Core LPeg - Parsing Expression Grammars For Lua 48:48 - Abstract Syntax Tree (AST) Picks Mass Effect 3 (Joe) A Beginner's Guide to Irrational Behavior | Coursera (Joe) Go write a programming language to learn one (Tim) Thumbs and Ammo (Jamison) ISM by Savant (Jamison) Vimcasts (Jamison) The iPhreaks Show (Chuck) Mozy (Chuck) Tech & Go Bright Pink Micro USB Cable (David) asm.js (David) Beyond Office Politics: The Hidden Story of Power, Affiliation & Achievement in the Workplace by Linda Sommer (Ariya) gotwarlost / istanbul (Ariya) Next Week Web Developer Skills Transcript JAMISON:  I am Linus Torvalds and I pronounce Linux, Linix. [Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.] CHUCK:  Hey everybody and welcome to Episode 54 of the JavaScript Jabber Show. This week on our panel, we have Tim Caswell. TIM:  Hello. CHUCK:  Jamison Dance. JAMISON:  Hi guys. CHUCK:  Joe Eames. JOE:  Hey there. CHUCK:  Merrick Christensen. MERRICK:  Hey guys, what’s up? CHUCK:  I’m Charles Max Wood from DevChat.tv. And we have two special guests this week. We have Dave Herman. DAVID:  Hey there. CHUCK:  Ariya Hidayat. ARIYA:  Hello everyone. CHUCK:  And these guys are so smart that we brought them back. So, if you’re interested, we’ll put links to the episodes that they were on. David was on when we talked about his book ‘Essential JavaScript’ and Ariya was on when we talked about PhantomJS. JAMISON:  Effective JavaScript. CHUCK:  Effective? What did I say? MERRICK:  Essential. CHUCK:  Essential? Well, it’s an essential book on Effective JavaScript. How’s that? [Laughter] MERRICK:  Good save. DAVID:  At least, you didn’t say Defective JavaScript. [Laughter] CHUCK:  No, that’s what I write. I’m really good at writing defective JavaScript. ARIYA:  Actually, there’s a book about Essential on Defective JavaScript. CHUCK:  I also want to announce really quickly that Fluent Conf has given us a discount code. So, if you want to get 20% off on your registration for Fluent Conf, just enter JAVAJAB and you’ll get 20% off when you register for Fluent Conf. Alright. Well, let’s get started. This is going to be a really, really interesting topic and it’s something that I’ve wanted to know more about for a long time. And I just haven’t delved as deeply into it as I would like to. And that is,

Panel Joe Eames (twitter github blog) Merrick Christensen (twitter github) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:10 - Making the transition from one primary language to JavaScript 01:30 - Merrick’s Experience ActionScript 03:32 - Joe’s Experience .NET Microsoft 07:46 - Moving from C# to JavaScript Misconceptions 09:25 - JavaScript Misconceptions 10:59 - Chuck’s Experience Ruby on Rails 14:25 - Rails and JavaScript Avoidance 15:25 - Microsoft and JavaScript Avoidance 16:58 - JavaScript Development in General Browsers and Problems 23:38 - Libraries and Tools 044 JSJ Book Club: Effective JavaScript with David Herman Effective JavaScript by David Herman 24:45 - Code Structure 27:03 - node.js 28:00 - Learning core concepts behind JavaScript 29:11 - Understanding Clojures, Scoping & Context 29:53 - Testing 31:35 - Deviating off the common path 33:10 - Idiomatic JavaScript Picks Dart (Merrick) ES6 Plans (Merrick) Defiance (Joe) America's Got Talent (Joe) StarCraft II World Championship Series (WCS) (Joe) Continuum (Chuck) Fringe (Chuck) CleanMyMac (Chuck) Book Club JavaScript Allongé with Reginald Braithwaite!  He will join us for an episode to discuss the book on August 1st. The episode will air on August 9th. Next Week Testem with Toby Ho Transcript CHUCK:  Yeah, I can pretend I’m getting better at JavaScript. [Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]  [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]  [This podcast is sponsored by JetBrains, makers of WebStorm. Whether you’re working with Node.js or building the frontend of your web application, WebStorm is the tool for you. It has great code quality and code exploration tools and works with HTML5, Node, TypeScript, CoffeeScript, Harmony, LESS, Sass, Jade, JSLint, JSHint, and the Google Closure Compiler. Check it out at JetBrains.com/WebStorm.] CHUCK:  Hey everybody, and welcome to Episode 66 of the JavaScript Jabber Show. This week on our panel, we have Joe Eames. JOE:  Hi there. CHUCK:  And Merrick Christensen. MERRICK:  Hey guys. CHUCK:  I’m Charles Max Wood from DevChat.TV. And this week, we’re going to be talking about, I think it’s kind of a blend of making the transition from one primary language to JavaScript, it usually happens through web development, and some of the mistakes that people make when their primary language is not JavaScript. Let’s go ahead and get started. Merrick, you’re kind of the expert guy that I always look at and go, “Man, he’s awesome at JavaScript.” So, I’m wondering, did you start out at JavaScript or did you come in from somewhere else? MERRICK:  Oh, that’s really nice of you, man. I actually started out with ActionScript. I really loved Flash developments, but it’s the same thing, really. They’re both based off of ECMAScript. So, I guess you could say I’ve always done JavaScript. JOE:  So, ActionScript is nearly identical to JavaScript? MERRICK:  Well, not anymore. ActionScript 3 developed classes and they typed it and they did some interesting things to make it more of a full-featured language. It’s got more [inaudible] than JavaScript now, I think. But I ended up getting into JavaScript when I was like 17 or so. I came across the MooTools framework and ever since then, it’s been all JavaScript all the time. CHUCK:  You’re pretty young. Wasn’t that last year? [Laughter] MERRICK:  Close. No, about six years, five years of JavaScript. JOE:  You’re also, though, like a real student of languages. You love studying other languages. MERRICK:  I love programming languages, yeah. JOE:  I think you’re a pretty funny, not necessarily unique,

Panel Reginald Braithwaite (twitter github blog) Jamison Dance (twitter github blog) Joe Eames (twitter github blog) AJ O’Neal (twitter github blog) Merrick Christensen (twitter github) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 02:08 - Reg Braithwaite Introduction Github 03:46 - JavaScript Allongé by Reginald Braithwaite 06:43 - The Y Combinator Kestrels, Quirky Birds, and Hopeless Egocentricity by Reginald Braithwaite 14:26 - Book Summary/Perspective Functions QED, The Strange Theory of Light and Matter by Richard P. Feynman 21:37 - Footnotes Flashman: A Novel by George MacDonald Fraser 26:42 - allong.es Michael Fogus 29:15 - Sharing Knowledge & Information 33:01 - The Coffee Theme CoffeeScript Ristretto by Reginald Braithwaite 37:42 - Favorite Parts of the Book How Prototypes Work Combinators 42:18 - Writing the Beginning 44:41 - Reg’s Programming Background One Two Three . . . Infinity: Facts and Speculations of Science by George Gamow Picks ng-conf (Joe & Merrick) LUMOback (Merrick) Twilio (AJ) Bountysource (AJ) Brian Stevens / Data Porters (Chuck) InformIT (Chuck) Safari Books Online (Chuck) QED, The Strange Theory of Light and Matter by Richard P. Feynman (Reginald) One Two Three . . . Infinity: Facts and Speculations of Science by George Gamow (Reginald) Understanding Computation: From Simple Machines to Impossible Programs by Tom Stuart (Reginald) Realm of Racket: Learn to Program, One Game at a Time! by Matthias Felleisen (Reginald) Special Offer! JSJABBERROCKS will give $5 off JavaScript Allongé by Reginald Braithwaite on Friday, August 9th through Sunday, August 11th 2013 ONLY! Next Week JavaScript Strategies at Microsoft with Scott Hanselman Transcript MERRICK:  Turns out my habit is Joe coming over to my desk and saying, [singing] “Da-na-na-na, jabber time!” [Laughter] AJ:  Nice. REG:  That behavior is always acceptable if you are dressed for the part. [Laughter] CHUCK:  Since this is pure audio, you don’t even have to be dressed. JOE:   I have a pair of parachute pants. MERRICK:  I actually record most of this show while I'm in the bathtub. [Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]  [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]  [This podcast is sponsored by JetBrains, makers of WebStorm. Whether you’re working with Node.js or building the front end of your web application, WebStorm is the tool for you. It has great code quality and code exploration tools and works with HTML5, Node, TypeScript, CoffeeScript, Harmony, LESS, Sass, Jade, JSLint, JSHint, and the Google Closure compiler. Check it out at JetBrains.com/WebStorm.] CHUCK:  Hey everybody and welcome to Episode 70 the JavaScript Jabber show. This week on our panel we have Jamison Dance. JAMISON:  Hello friends. CHUCK:  Joe Eames. JOE:  Hey there. CHUCK:  AJ O’Neal. AJ:  Still coming at you almost live from San Francisco. CHUCK:  Merrick Christensen. MERRICK:  What’s up guys? CHUCK:  There we go. I’m Charles Max Wood from DevChat.TV. And we have a special guest, and that is Reg Braithwaite. REG:  Pleased to be here with you. MERRICK:  That was a real voice if I’ve ever heard one. JOE:  Yeah. Awesome. CHUCK:  No kidding. We should have you do some voice overs for us. MERRICK:  We should. CHUCK:  You’re listening to JavaScript Jabber. [Chuckles] AJ:  Say, “In a world…” [Chuckles] REG:  In a world… CHUCK:  Anyway… [Laughter] AJ:  Derailed, derailed. CHUCK:  Yeah, totally. Reg, since you’re new to the show, do you want to introduce your self briefly? REG:  Certainly. I’m a 51-year-old programmer. I got started the old-fashioned way,

Panel Scott Hanselman (twitter github blog) Joe Eames (twitter github blog) Aaron Frost (twitter github blog) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:14 - Scott Hanselman Introduction Community Program Manager for Web Tools at Microsoft Azure and Web Tools ASP.NET Runtime 03:17 - Microsoft and JavaScript Microsoft Build Developer Conference Scott Hanselman: Angle Brackets, Curly Braces, One ASP.NET and the Cloud Json.NET 13:40 - The Cost of Web Development Tooling Sublime Text Visual Studio 18:17 - Libraries and Frameworks Knockout 24:14 - Innovation in Software Befunge 29:48 - Apps Supporting JavaScript Create your first Windows Store app using JavaScript (Windows) Visual Studio Express 34:14 - Windows and Internet Explorer Chakra 40:42 - Microsoft’s Attitude Towards JavaScript Scott Hanselman: Azure for the non-Microsoft Person - How and Why? 45:58 - Open Source 49:12 - asm.js 52:05 - Angle Brackets Conference Picks The Wolverine (Joe) ng-conf (Joe) Cancún (Aaron) @ngconf (Aaron) Wistia (Chuck) Mumford And Sons 'Hopeless Wanderer' Music Video (Scott) Beyoncé Joins the Short Hair Club (Scott) Next Week Screencasting: Sharing What You Know Through Video Transcript [Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]  [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]  [This podcast is sponsored by JetBrains, makers of WebStorm. Whether you’re working with Node.js or building the front end of your web application, WebStorm is the tool for you. It has great code quality and code exploration tools and works with HTML5, Node, TypeScript, CoffeeScript, Harmony, LESS, Sass, Jade, JSLint, JSHint, and the Google Closure Compiler. Check it out at JetBrains.com/WebStorm.] CHUCK:  Hey everybody and welcome to Episode 71 the JavaScript Jabber show. This week on our panel, we have Joe Eames. JOE:  Hey. CHUCK:  Aaron Frost. AARON:  Hello. CHUCK:  I’m Charles Max Wood from DevChat.TV. And we have a special guest that is Scott Hanselman. SCOTT:  Hello. CHUCK:  Since you’re new to the show, do you want to introduce yourself really quickly? SCOTT:  My name is Scott Hanselman. You can learn more about me on the internet by googling for Scott. I’m in an epic battle right now with the Scott toilet paper people. You’ll find me just below Scott toilet tissue. I’ve been blogging for ten years. More than ten years, 13 years. I work at Microsoft right now. Before that I worked in finance at a company called Corillian that is now Fiserv. I’ve been building big systems on the web for as long as the web’s been around. CHUCK:  Wow. What do you do at Microsoft? SCOTT:  I work in Azure and Web Tools. I’m a program manager. I’m in charge of the experience from file new project until deployment. I call myself the PM of miscellaneous. I spend time going through that experience making sure that it doesn’t suck. My focus is on web tools but also ASP.NET Runtime and what the experience is when you deploy something into Azure. That might be everything from what’s it like editing JavaScript in Visual Studio and I’ll find some issue and go and work with the guys that own that, or it might be someone’s trying to do something in Node on Azure and that experience is not good. I’m like an ombudsman or a customer liaison. But the simplest way would be to say I’m the community PM, community program manager, for web tools at Microsoft. CHUCK:  Okay. AARON:  Cool. CHUCK:  So, is JavaScript your primary focus? SCOTT:  I would say that my primary focus is just anything that makes the web better and moves the web forward. While I work for ASP.NET and most of my work is in C#,

Panel Nicholas C. Zakas (twitter github blog) Joe Eames (twitter github blog) AJ O’Neal (twitter github blog) Jamison Dance (twitter github blog) Merrick Christensen (twitter github) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:24 - Nicholas Zakas Introduction Box Maintainable JavaScript by Nicholas C. Zakas High Performance JavaScript (Build Faster Web Application Interfaces) by Nicholas C. Zakas Yahoo 02:19 - What Makes Maintainable JavaScript? Code Layout Clever Solutions (“Chicken Blood Solutions”) 04:39 - Formatting Thinking, Fast and Slow by Daniel Kahneman Broken Window Theory 07:33 - Architecture aura Nicholas Zakas: The Scalable JavaScript Application Architecture Feature Encapsulation 14:11 - 'High Performance Javascript' and the balance between short-term and long-term knowledge 19:17 - Important conventions for a team to follow Styles Mini Design Patterns Readability 26:14 - Tools & Techniques Style Guide 28:31 - Breaking the continuous integration build 31:14 - Linting JSLint 32:35 - Developing skills for architecting things Experience Personal Trait of Curiosity Component-based and Systems-based software engineers 37:52 - Architecture and Maintainability Testability Backbone.js 43:28 - Creating common conventions that will apply across projects Picks Domo (Joe) Pluralsight (Joe) Game Dev Tycoon (Joe) The Star Wars (Joe) Foundation Actionscript 3.0 Animation: Making Things Move! by Keith Peters (Merrick) ng-conf (Merrick) Kveikur by Sigur Rós (Merrick) makemeasandwich (AJ) Sleep (AJ) Jekyll Themes (Jamison) Growing Object-Oriented Software, Guided by Tests by Steve Freeman (Jamison) A Canticle For Leibowitz by Walter M. Miller Jr. (Jamison) DevChat.tv (Chuck) Thinking, Fast and Slow by Daniel Kahneman (Nicholas) StePhest Colbchella '013 - Time to Dance (Nicholas) Evolution of Music - Pentatonix (Nicholas) Next Week Meteor.js with Marcus Phillips and Fred Zirdung Transcript [Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]  [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]  [This podcast is sponsored by JetBrains, makers of WebStorm. Whether you’re working with Node.js or building the frontend of your web application, WebStorm is the tool for you. It has great code quality and code exploration tools and works with HTML5, Node, TypeScript, CoffeeScript, Harmony, LESS, Sass, Jade, JSLint, JSHint, and the Google Closure Compiler. Check it out at JetBrains.com/WebStorm.] CHUCK:  Hey everybody and welcome to episode 75 of the JavaScript Jabber show. This week on our panel, we have Joe Eames. JOE:  Hey, everyone. CHUCK:  AJ O’Neal. AJ:  I can hit unmute. I'm here. CHUCK:  Jamison Dance. JAMISON:  Hello, friends. CHUCK:  Merrick Christensen. MERRICK:  Hey, guys. CHUCK:  I’m Charles Max Wood from DevChat.TV. This week, we have a special guest, that’s Nicholas Zakas. NICHOLAS:  Yup, you got it. CHUCK:  So, since you haven’t been on the show before, do you want to introduce yourself? NICHOLAS:  Sure. I'm a software engineer that is working for Box currently. I think a lot of people probably know me from the books that I've written, mostly on the topic of JavaScript and the talks that I've given also on that topic. And a lot of that relates back to my work when I was at Yahoo. I was there for about five years and was the lead on the Yahoo homepage redesign. And a lot of what I do is really just try to solve problems in real life and then share what I did with everybody else in whatever way I think is most appropriate - writing or speaking or coming on podcasts. CHUCK:  Yes, you're being modest. You have a book,

Pete Hodgson crosses over from the iPhreaks podcasts to talk with the Jabber gang about testing asynchronous Javascript with promises.

The panelists discuss The New York Times and JavaScript with Eitan Konigsburg, Alastair Coote and Reed Emmons.

The panelists talk to Bart Wood about large single page JavaScript applications.

The panelists talk to David Nolen about ClojureScript and Om.

The panelists discuss dependency injection with Vojta Jína & Misko Hevery.

The panelists talk about refactoring JavaScript Apps Into a Framework with Brandon Hays.

The panelists talk to Brendan Eich, the creator of JavaScript.

02:54 - Everyone Gets It But Me

• Martin Fowler

04:06 - Tools You “Need” to Know

06:29 - Clojures

07:39 - JavaScript as “Object-Oriented” vs “Event-Oriented”

• Object-Oriented Programming

09:30 - Code That Can’t Be Serialized or Deserialized

10:49 - Clojures (Cont’d)

14:32 - The DOM (Document Object Model)

• [YouTube] Angular + React = Speed by Dave Smith @ ng-conf 2015

19:52 - Math Is Hard

• IEEE754 (Floating-Point Arithmetic)

22:39 - Prototypes

• Sebastian Porto: A Plain English Guide to JavaScript Prototypes

25:43 - Asynchronous Programming

• Debugging
• Gregor Hohpe: Your Coffee Shop Doesn’t Use Two-Phase Commit
• How Do You Learn It?

32:23 - Browser Environments

34:48 - Keeping Up with JavaScript

35:46 - Node

• Nesting
• Context Switching

42:48 - UTF-8 Conversion

44:56 - Jamison’s Stack

• React
• Koa    
• RethinkDB
• io.js
• Webpack

Check out and sign up to get new on React Rally: A community React conference on August 24th and 25th in Salt Lake City, Utah!

Picks

Jason Orendorff: ES6 In Depth (Aimee)
Cat Strollers (Aimee)
Stephano Legacy of the Void (Joe)
A Gentleman's Guide to Love and Murder (Joe)
Gregor Hohpe: Your Coffee Shop Doesn’t Use Two-Phase Commit  (AJ)
Firefox OS (AJ)
Flame (AJ)
OpenWest 2015 (AJ)
801 Labs Hackerspace (AJ)
Stack Overflow Careers (AJ)
Dota 2 (Jamison)
Beats, Rye & Types Podcast (Jamison)
JS Remote Conf Talks (Chuck)
Workflowy (Chuck)

02:27 - Alex Eagle Introduction

• Twitter
• GitHub
• Google

02:54 - Jonathan Turner Introduction

• Twitter
• GitHub
• Microsoft
• [Talk] Jonathan Turner: TypeScript and Angular 2 @ ng-conf 2015
• [Talk] Jonathan Turner: TypeScript and Angular 2 @ Angular U 2015

03:30 - What is TypeScript?

04:40 - Google + Microsoft = <3 (Angular Adopting TypeScript)

• Rob Eisenberg
• AtScript
  • Jonathan Turner: Angular 2: Built on TypeScript

07:18 - TypeScript Accommodating Angular

• TC39
• Yehuda Katz
• Aurelia

09:28 - Surge of Interest in Adopting a Typechecker, Type System

14:21 - Angular: Creating a New Language

• Killing Off Wasabi - Part 1 (FogBugz Article)
• traceur

16:46 - The Angular 2 Component System and How it Uses New Annotations for Classes

18:01 - Annotations and Decorators

22:06 - TypeScript and Babel?; Adding New Features

25:25 - Non-Angular Users Adopting TypeScript

• Visual Studio Code

34:55 - Tooling and Setting Modes for Linting and Static Analysis

36:58 - Using Libraries Outside the TypeScript Ecosystem

38:11 - Type Definition Files

40:15 - Content of the Type System

43:19 - Duck Typing

45:12 - Getting People to Care about TypeScript

49:16 - The Angular and TypeScript Relationship

Picks

f.lux (Aimee)
Jafar Husain: Functional Programming in Javascript (learnrx) (Aimee)
Startup Timelines (Jamison)
Friday Night Lights (Jamison)
React Rally (Jamison)
Evan Farrer: Unit testing isn't enough. You need static typing too. (Dave)
AngularConnect (Joe)
ng-click.com (Joe)
mdn.io (Joe)
Sonic Pi (Chuck)
Error Prone (Alex)
AudioScope-ng2 (Jonathan)
The Nintendo World Championships (Jonathan)

03:04 - Jafar Husain Introduction

• Twitter
• GitHub
• Netflix
• TC39

03:29 - The Great Name Debate (ES6, ES7 = ES2015, ES2016!!)

05:35 - The Release Cycle

• What This Means for Browsers

08:37 - Babel and ECMAScript

09:50 - WebAssembly

13:01 - Google’s NACL

13:23 - Performance > Features?

• ES6 Feature Performance (JavaScript Weekly Article)
• Features Implemented as Polyfills (Why Bother?)

20:12 - TC39

24:22 - New Features

• Decorators
  • Performance Benefit?

28:53 -Transpilers

34:48 - Object.observe()

37:51 - Immutable Types

45:32 - Structural Types

47:11 - Symbols

48:58 - Observables

52:31 - Async Functions

• asyncawait

57:31 - Rapid Fire Round - When New Feature Will Be Released in ES2015 or ES2016

• let - 15
• for...of - 15
• modules - 15
• destructuring - 15
• promises - 15
• default function argument expressions - 15
• asyncawait - 16

Picks

ES6 and ES7 on The Web Platform Podcast (AJ)
Binding to the Cloud with Falcor Jafar Husain (AJ)
Asynchronous JavaScript at Netflix by Jafar Husain @ MountainWest Ruby 2014 (AJ)
Let's Encrypt on Raspberry Pi (AJ)
adventures in haproxy: tcp, tls, https, ssh, openvpn (AJ)
Let's Encrypt through HAProxy (AJ)
Mandy's Fiancé's Video Game Fund (AJ)
The Murray Gell-Mann Amnesia Effect (Dave)
The Majority Illusion (Dave)
[Egghead.io] Asynchronous Programming: The End of The Loop (Aimee)
Study: You Really Can 'Work Smarter, Not Harder' (Aimee)
Elm (Jamison)
The Katering Show (Jamison)
Sharding Tweet (Jamison)
The U.S. Women's National Soccer Team (Joe)
mdn.io (Joe)
Aftershokz AS500 Bluez 2 Open Ear Wireless Stereo Headphones (Chuck)
Autonomy, Mastery, Purpose: The Science of What Motivates Us, Animated (Jafar)
Netflix (Jafar)
quiescent (Jafar)
Clojurescript (Jafar)

Check out JS Remote Conf! Buy a ticket! Submit a CFP!

03:07 - Burke Holland Introduction

• Twitter
• GitHub
• Blog

04:01 - TJ Van Toll Introduction

• Twitter
• GitHub
• Blog

04:33 - Telerik

• Telerik Platform

04:57 - NativeScript

• JavaScriptCore
• JavaScript Jabber #128: JavaScriptCore with Cesare Rocchi
• React Native

07:41 - The Views

10:07 - Customizability, Styling, and Standardization

16:19 - React Native vs NativeScript

18:37 - APIs

• CocoaPods

21:17 - How NativeScript Works

23:04 - Edgecases?

• Message Passing
• Marshalling (Mapping)

26:12 - Memory Management

27:06 - UITableView

29:59 - NativeScript and Angular

• AngularConnect Talks on YouTube
• Sebastian Witalec: Building native mobile apps with Angular 2 0 and NativeScript​

33:22 - Adding NativeScript to Existing Projects

33:51 - Building for Wearables and AppleTV

• Burke Holland: Apple Watch and the Cross-Platform Crisis

35:59 - Building Universal Applications

37:14 - Creating NativeScript

• Kendo UI

39:42 - Use Cases

• nativescript.org/app-samples-with-code

41:01 - Are there specific things NativeScript isn’t good for?

• npmjs.com search: nativescript

42:54 - Testing and Debugging

48:35 - Data Storage

Picks

Caddy (AJ)
OC ReMix #505: Top Gear 'Track 1 (Final Nitro Mix)' by Rayza (AJ)
Jamie Talbot: What are Bloom filters? A tale of code, dinner, and a favour with unexpected consequences (Aimee)
Mike Gehard (@mikegehard) (Aimee)
Joe Eames: Becoming Betazoid: How to Listen and Empathize with Others in the Workplace @ AngularConnect 2015 (Dave)
Exercise (Chuck)
Sleep (Chuck)
electron (Aaron)
The Synchronicity War Series by Dietmar Wehr (Aaron)
PAUSE (Burke)
Outlander (TJ)

Check out JS Remote Conf!

02:22 - Elijah Manor Introduction

• Twitter
• GitHub
• Blog
• LeanKit
• Eliminate JavaScript Code Smells (Elijah's Talk Abstract)
• A video containing the 30 min version of the talk: Eliminate JavaScript Code Smells
• The full slides (60 mins worth of material)

04:49 - What is a “Code Smell”?

• Martin Fowler: CodeSmell
• ESLint
• JSHint

10:21 - Copy/Paste Code Error

• jsinspect and jscpd
• ES6, ES7, Babel Support

13:11 - Using ES6 to Eliminate Code Smells

15:48 - Refactoring Case Statements

• The Strategy Pattern

21:29 - Juniors and Code Smells

• Code Reviews

27:29 - Isomorphic Code

31:12 - Framework Code Smells

33:47 - Identifying New Code Smells

36:33 - When Code Smells are OK

39:10 - Why use parameters?

Picks

Terms And Conditions May Apply (AJ)
Nodevember (Aimee)
Developer Tea (Aimee)
Jake Shimabukuro (Joe)
Screeps (Joe)
react-styleguide-generator (Elijah)
react-styleguidist (Elijah)
The Phantom Menace - What it Should Have Been (AJ)
Attack of the Clones - What it Should Have Been (AJ)

02:54 - John A. De Goes Introduction

• Twitter
• GitHub
• Blog
• SlamData

06:34 - Phil Freeman Introduction

• Twitter
• GitHub
• Blog

07:38 - What is PureScript?

09:11 - Features

• Extensible Effects

12:24 - Overcoming the Vocabulary Problem in Functional Programming

• Gang of Four Book (Design Patterns)
• purescript-halogen

20:07 - Prerequisites to PureScript

26:14 - PureScript vs Elm

• JavaScript Jabber Episode #175: Elm with Evan Czaplicki and Richard Feldman
• No Runtime
• General Purpose vs UI-Focused
• Generic Containers

40:37 - Similar Languages to PureScript

44:07 - PureScript Background

• Roy

47:48 - The WebAssembly Effect

51:01 - Readability

53:42 - PureScript Learning Resources

• PureScript by Example by Phil Freeman
• PureScript Conf 2015/6

55:43 - Working with Abstractions

• purescript-aff
• Audrey Popp: Fighting Node Callback Hell with PureScript

Picks

Philip Robects: What the heck is the event loop anyways? @ JS Conf EU 2014 (Aimee)
loupe (Aimee)
The Man in the High Castle (Jamison)
Nickolas Means: How to Crash an Airplane @ RubyConf 2015 (Jamison)  
Lambda Lounge Utah (Jamison)
Michael Trotter: Intro to PureScript @ Utah Haskell Meetup (Jamison)
Utah Elm Users (Jamison)
Screeps (Joe)
Most Likely to Succeed: Preparing Our Kids for the Innovation Era by Tony Wagner (Joe)
Dark Matter (Joe)
LambdaConf (John)
@lambda_conf (John)
ramda (John)
Proper beef, ale & mushroom pie (John)
Tidal (Phil)
purescript-flare (Phil)
The Forward JS Conference (Phil)

JS Remote Conf starts tomorrow! Get your ticket TODAY!

03:59 - JavaScript Tools Fatigue

• Catalyst: Eric Clemmons: Javascript Fatigue
• Some Twitter Opinions and Perspectives:
  • Ryan Florence
  • Michael Jackson
  • Jamison
  • Vjeux
  • Sebastian McKenzie

09:25 - Are popular technologies ahead of public consumability?

• Ryan Florence Tweet

12:53 - Adopting New Things / Churn Burnout

18:02 - Non-JavaScript Developers and Team Adoption

30:49 - Is this the result of a crowdsourced design effort?

35:44 - Human Interactions

45:00 - Tools

47:03 - How many/which of these tools do I need to learn?

Picks

Julie Evans: How to Get Better at Debugging (Jamison)
Totally Tooling Tips: Debugging Promises with DevTools (Jamison)
Making a Murderer (Jamison)
Scott Alexander: I Can Tolerate Anything Except the Outgroup (Jamison)
@SciencePorn (Dave)
postcss (Aimee)
Cory House: The Illogical Allure of Extremes (Aimee)
Kerrygold Natural Irish Butter (Aimee)
Star Wars (Joe)
@iammerrick (Joe)
Greg Wilson: What We Actually Know About Software Development, and Why We Believe It's True (Joe)
The U.S. Military (Joe)
Operation Code (Aimee)
Ruby Rogues Episode #184: What We Actually Know About Software Development and Why We Believe It's True with Greg Wilson and Andreas Stefik (Chuck)
Serial Podcast (Chuck)

This episode was recorded live from The Microsoft Build Conference 2016. In this episode we chatted with Anders Hejlsberg of Microsoft about Typescript. You can follow him on Twitter, or check out what he’s done over on GitHub

Resources

• TypeScript

Picks

Writing Code (Anders)

Check out Newbie Remote Conf!

02:44 - What it Takes to Learn JavaScript in 2016

04:03 - Resources: Then vs Now

09:42 - Are there prerequisites? Should you have experience?

20:34 - Choosing What to Learn

• The iPhreaks Show Episode #153: Using Mobile Devices to Manage Diabetes with Scott Hanselman

28:19 - Deciding What to Learn Next

31:19 - Keeping Up: Obligations As a Developer

34:22 - Deciding What to Learn Next (Cont’d)

42:01 - Recommendations

• You-Dont-Know-JS
• gulp.js
• webpack
• The Little Schemer
• Designing Data-Intensive Applications by Martin Kleppmann

Picks

• accidentally nonblocking (Jamison)
• choo (Jamison)
• Web Rebels (Jamison)
• React Rally (Jamison)
• Grab The Gold (Aimee)
• node-for-beginners (Aimee)
• Procrastinate On Purpose by Rory Vaden (Chuck)
• Newbie Remote Conf (Chuck)
• Get A Coder Job (Chuck)

02:25 - Kyle Simpson Introduction

• Twitter
• GitHub
• Blog
• “Getify”
• You-Dont-Know-JS
• [Pluralsight] Advanced JavaScript by Kyle Simpson

04:43 - Development => Teaching

• Front End Masters

16:20 - Inheritance and Delegation

29:40 - Evolving a Language

36:23 - Cohersion

• Weak Typing, Dynamic Typing
• The Politics of JavaScript by Angus Croll

50:37 - Performance

• The Width Keyword

54:33 - Developer Education Programs and The Skill of Teaching

Picks

• Adam Tornhill: Code, Crime, Complexity: Analyzing software with forensic psychology @ TEDxTrondheim (Aimee)
• Your Code as a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs by Adam Tornhill (Aimee)
• Planet Money Episode 704: Open Office (Jamison)
• Zooko's Triangle (Jamison)
• The Barkley Marathons (Jamison)
• React Rally (Jamison)
• X-Men: Apocalypse (Joe)
• America's Got Talent (Joe)
• Overwatch (Joe)
• Stack (Kyle)
• Jeremy Keith: A web for everyone (Kyle)
• Jeremy Keith: Regressive Web Apps (Kyle)

00:50 Intro to guests Donovan Brown and Jordan Matthiesen

1:14 Javascript and Devops

3:49 Node JS and integrating with extensions

11:16 Learning Javascript coming from another language

15:21 Visual Studio Team Services at Microsoft, integration and unit testing

• Visualstudio.com
• Donovanbrown.com

25:10 Visual Studio Code and mobile development

• Apache Cordova open source project

31:45 TypeScript and tooling

33:03 Unit test tools and methods

38:39 ARM devices and integration

QUOTES:

“It’s not impossible, it’s just a different set of challenges.” - Donovan Brown

“Devops is the union of people, process and products to enable continuous delivery of value to your end users” - Donovan Brown

“Apps start to feel more native. They can actually get form.” - Jordan Matthiesen

PICKS:

Veridian Dynamics (AJ)

Jabberwocky Video (AJ)

Hard Rock Cafe - Atlanta (Charles)

CES (Charles)

3D printers (Donovan)

High-Yield Vegetable Gardening (Jordan)

taco.visualstudio.com

Jordan on Twitter @jmatthiesen

Visualstudio.com

Donovanbrown.com

Donovan on Twitter @donovanbrown

SPONSORS:

Front End Masters

Hired.com

On today's JavaScript Jabber Show, Charles, Aimee, Joe, and Cory discuss Wordpress and Wordpress API for JavaScript Developers with Roy Sivan. Roy is a WordPress (WP) developer at Disney Interactive. He has long been a fan of JavaScript and WP. During a WordCamp, the WP Founder announced the need for WP developers to learn JavaScript. But, what's in WP that developers should be interested about? Tune in to learn!

On today's JavaScript Jabber Show, Charles, Joe, Aimee, Cory, and AJ discuss Clean Code JavaScript with Ryan McDermott. Ryan is a UX Engineer at Google and has been a professional developer for 5 years. He's focused on frontend Angular and backend node.js. Stay tuned to learn more about his current project with JavaScript!

On today's episode, Charles, Joe, and Cory discuss Practical JavaScript with Gordon Zhu. Gordon is the founder of Watch and Code, and teaches the Practical JavaScript online course. His mission is to help beginners become developers through tutorials. Tune in!

JSJ 268 Building Microsoft Office Extensions with Javascript with Tristan Davis and Sean Laberee

This episode is live at the Microsoft Build 2017 with Charles Max Wood and AJ O’Neal. We have Tristan Davis and Sean Laberee from the Office Team at Microsoft. Tune in and learn more about what’s new with Microsoft Office Extensions!

[00:01:25] – Introduction to Tristan Davis and Sean Laberee

Tristan Davis and Sean Laberee are Program Managers on the Microsoft Office team, focused on Extensibility.

Questions for Tristan and Sean

[00:01:45] – Extending Office functionality with Javascript

Office isn’t just an application on Windows that runs on your PC. It is running on iPhone, iPad, Android tablet, and apps on the browser with Office Online. The team needs a new platform, add-ins, which allow you to build apps that run across all places. It’s HTML and Javascript. HTML for all the UI and a series of Javascript module calls for the document properties. Sometimes we call it OfficeJS.

[00:03:20] – This works on any version of Office?

It works on Office on Windows, Mac, Online and iPad.

[00:03:55] – HTML and CSS suck on mobile?

There are things that you’re going to want to do when you know you’re running on a mobile device. If you look at an add-in running on Outlook for iPhone, the developer does a lot of things to make that feel like part of the iPhone UI. Tristan believes that you could build a great add-in for Office using HTML and JavaScript.

[00:05:20] – Are these apps written with JavaScript or you have a Native with WebView?

Office itself is Native. All of it is Native code but the platform is very much web. The main piece of it is pointing at the URL. Just go load that URL. And then, you can also call functions in your JavaScript.

[00:06:35] – Why would you do this? How does it work?

The add-in platform is a way to help developers turn Word, Excel and PowerPoint into the apps that actually solve user’s business problems. The team will give you the tools with HTML and JavaScript to go and pop into the Word UI and the API’s that let you go manipulate the paragraph and texts inside of Word. Or in Excel, you might want to create custom formulas or visualizations. The team also let people use D3 to generate their own Excel charts.

And developers want to extend Office because it’s where a lot of business workers spend their days 0 in Outlook, Teams, Word, Excel.

[00:10:00] – How did this get delivered to them?

There are 2 ways to get this delivered. One, there’s an Office Store. Second, if you go into Word, Excel, and PowerPoint, there’s a store button and you can see tons of integrations with partners.

For enterprises, IT can deploy add-ins to the users’ desktops without having stress about deploying MSI’s and other software deployments that the web completely rids off. The add-ins make a whole lot of pain the past completely go away.

[00:11:00] – Everybody in the company can use a particular plug-in by distributing it with Office?

That’s right. You can go to Office 365 add-in experience. Here’s the add-in and you can to specific people or everyone who’s part of a group.

For the developer’s perspective, if you have the add-in deployed to your client, you could actually push updates to the web service and your users get the updates instantly. It’s a lot faster turn-around model.

[00:14:20] – What about conversations or bot integrations?

There’s the idea of connectors at Teams. You can subscribe to this web book and it’ll publish JSON. When the JSON is received, a new conversation inside of Teams or Outlook will be created. For example, every time someone posts on Stack Overflow with one of the tags that team cares about, it posts on Outlook.

It’s a great way to bring all the stuff. Rather than have 20 different apps that are shooting 20 different sets of notifications, it’s just all conversations in email, making do all the standard email things.

And in the connector case, it’s a push model. The user could choose what notifications they want.

You’d also learn things like bots. You can have bots in Teams and Skype. The users can interact with them with their natural language.

[00:18:40] – How about authentication?

As long as you’re signed into Office, you can call JavaScript API to give you an identity token for the sign in user and it will hand you a JWT back. That’s coming from Azure Active Directory or from whatever customer directory service. That’s standard.

If you want to do more, you can take that identity token and you can exchange that for a token that can call Microsoft graph. This app wants to get access to phone, are you okay with that? Assuming the user says yes, the user gets a token that can go and grab whatever data he wants from the back-end.

[00:20:00] – Where does it store the token?

That’s up to the developer to decide how they want to handle that but there are facilities that make sure you can pop up a dialog box and you can go to the LO-flow. You could theoretically cache it in the browser or a cookie. Or whatever people think is more appropriate for the scenario.

[00:20:55] – What does the API actually look like from JavaScript?

If you’re familiar with Excel UI, you can look at Excel API. It’s workbook.worksheets.getItem() and you can pass the name of the worksheet. It can also pass the index of the worksheet.

[00:22:30] – What’s the process of getting setup?

There’s a variety of options. You can download Office, write XML manifest, and take a sample, and then, side loads it into Office. You can also do that through web apps. There’s no install required because you can go work against Office Online. In the Insert menu, there’s a way to configure your add-ins. There’s upload a manifest there and you can just upload the XML. That’s going to work against whatever web server you have set up.

So it’s either on your local machine or up in the cloud. It’s as much as like regular web development. Just bring your own tools.

[00:24:15] – How do you protect me as a plug-in developer?

There’s an access add-in that will ask your permission to access, say, a document. Assume, they say yes, pipes are opened and they can just go talk to those things. But the team also tries to sandbox it by iframes. It’s not one page that has everybody’s plug-ins intermingle that people can pole at other people’s stuff.

[00:27:20] – How do you support backward compatibility?

There are cases where we change the behavior of the API. Every API is gated by requirement set. So if a developer needs access to a requirement set, he gets an aggregate instead of API’s that he can work with but it isn’t fixed forever.

But it’s not at that point yet where we end up to remove things completely. In Office JS, we’ve talked about API’s as one JavaScript library but really, it’s a bootstrap that brings in a bunch of other pieces that you need.

[00:30:00] – How does that work on mobile? Do they have to approve download for all components?

You can download components by using the browser that the operating system gives. It’s another one of the virtues of being based on the web. Every platform that has a web browser can have JavaScript execution run-time. It allows for the way that their app guidelines are written.

[00:33:15] – How about testing?

It’s a place where there’s still have work to do. There’s a bunch of open-source projects that partners have started to do that. What they’ve done is they’ve built a testing library. Whatever the mock is, it's just a thing on Github. It is open-source friendly. So the team could be able to contribute to it. “Here’s an interesting test case for this API. I want to make sure that it behaves like this.

[00:35:50] – Could you write it with any version for JavaScript e.g. TypeScript?

A Huge chunk of the team is big TypeScript fans. They’ve done a lot of work to make sure that TypeScript experience is excellence.

Type is basically a collection of typing files for TypeScript. There’s a runtime process that parses your TypeScript, gives you feedback on your code, and checks for errors. You can also run it in the background.

There’s an add-in called Script Lab. Script Lab is literally, you hit the code button and you get a web IDE right there. You can go start typing JavaScript code, play with API’s, and uses TypeScript by default. It’ll just actually load your code in the browser, executes, and you can start watching.

[00:39:25] – Are there any limitations on which JavaScript libraries you can pull in?

There a no limitations in place right now. There are partners that use Angular. There are partners that are big React fans. If you’re a web dev, you can bring whatever preferences around frameworks, around tools, around TypeScript versus JavaScript.

[00:45:20] – What’s the craziest thing you’ve seen done with this API?

Battleship was pretty cool. There’s also Star Wars entering credits theme for PowerPoint.

[00:46:40] – If a developer is building a plug-in and get paid for it, does Microsoft take credit for that?

There are 2 ways that folks can do it. You can do paid add-ins to the store. Either you do the standard perpetual 99 cents or you can do subscriptions, where it’s $2.99/month. Tristan encourages that model because integrations are just a piece of some larger piece of software.

But Microsoft is not in the business of trying to get you to pay me a little bit of 10 cents a dollar. It’s really in the business of making sure that you can integrate with Office as quickly as possibly can.

When the users go to the store, they can use the same Microsoft account that you use to buy Xbox games or movies in the Xbox, Windows apps in the Windows store.

[00:52:00] – The App Model

If folks are interested in the app model, they should go to dev.office.com to learn more about it because that’s where all the documentation is. Check out our Github. Right there in the open, there’s the spec. Literally, the engineers who are coding the product are reading the same marked-down files in the same repo that you, as a developer, can come and look at. And you can comment. You can add issues like you could have a dialogue with that PM. Under the OfficeDev, you’ll find a tunnel repository that contains samples. Our docs are there.

Picks

AJ O'Neal

• Lithium

Charles Max Wood

• Miracle Morning by Hal Erod
• Clean Code by Uncle Bob Martin
• Ketogenic diet

Tristan Davis

• Amazon Echo
• Microbiome

Sean Laberee

• Running
• Garmin watch

JSJ 269 Reusable React and JavaScript Components with Cory House

On today’s episode of JavaScript Jabber, we have panelists Joe Eames, Aimee Knight, Charles Max Wood, and playing the part of both host and guest, Cory House. Encourage your team to investigate reusable components, whether that’d be React, Angular, Vue, or Ember. Tune in!

[00:01:35] – Overview

We can finally write reusable components that it is really lightweight. It doesn’t take much framework-specific code to get things done.

Around 3 years ago, the idea of web component standard was all front-end developers could share our components with each other whether someone is in Angular or React. Web components continue to be an interesting standard but people continue to reach for JavaScript libraries instead – React, Angular, Vue. 

[00:04:50] – Browser support issue

The story in JavaScript libraries is easier. You have more power, more flexibility, more choices, and get superior performance, in certain cases, by choosing a JavaScript library over the standard right now. If you try to use the web components standard, you have to Polyfill-in some features so you can run things across browser. You also won’t get JavaScript features like intelligently splitting bundles and lazy load different components.

Whether you’re in Angular or React, you have this model of putting your data in your curly braces. That setup is non-existent in standardized web components. You have to play the game of putting and pulling data into and out the DOM using DOM selectors. You actually take a step backward in developer ergonomics when you choose to leverage the platform instead.

[00:07:50] – Polymer

The reason that Polymer is useful is it adds some goodness on top of web components. One of those things is that it makes it easier to bind in data and not having to do things like writing a DOM query to be able to get your hands on this div and put this text inside of it. With Polymer, you can do something that feels more like Angular, where you can put in your curly braces and just bind in some data into that place. Polymer ends up adding some nice syntactic sugar on top of the web components standard just to make it easier to create web components. Polymer is also used to bundle in Polyfill for the features across browser.   

[00:14:20] – Standards are dead

No. The standard itself has been embraced at different levels by different libraries. What you can see for the near future is popular libraries leveraging pieces of the web components platform to do things in a standard-spaced way. Effectively, Angular, Vue, Aurelia, are going to be abstractions over the web components standard. Arguably the most popular way to do components today is React. But React completely ignores the web components standard. When you look at React, you can’t see what piece of the web components standard would fundamentally make React a better component library.

Cory can’t seem to run to anybody that is actually using the standard in production to build real applications. People continue to reach for the popular JavaScript libraries that we so often hear about.

[00:17:05] – Libraries making reusable components

There is a risk that it would have been a waste for people writing components on Angular, for React, for Vue. But it’s not necessarily safer writing on the web component standard when you have so few people leveraging that standard. There’s always the risk that that standard may shift as well.

As an example, Cory’s team created approximately 100 reusable components in React. If they end up moving to a hot new library, the components are really just functions that take parameters and contain HTML. There is little there

[00:21:20] – Why opt for reusable components

Reusable components are inherently useful in a situation where you’re going to be doing something more than once. If you think about any work that you do as a software developer, we’d like to think that we’re coming in and creating new things but often it is groundhogs day. There are all sorts of opportunities for reuse.

As a company, we want to encapsulate our forms in reusable components so it’s literally impossible for our software developers to do something that goes against our standard. That’s the power of reusable components.  

[00:31:20] – Rigid component vs. flexible component

As component developers, if we try to create a reusable component in a vacuum, bad things happen. If you’re going to do a reusable component, start by solving a specific problem on a given application. If we think that a component’s going to be useful in multiple places, we put it in a folder called reusable right there in our application source folder.

We try to follow that rule of three as well. If we’ve taken that component and used it in 3 places, that’s a good sign that we should extract it out, put it in our NPM package, that way, everybody has this centralized component to utilize. At that point, it has been tested. It’s been through the fire. People have used it in the real world in a few places so we can be confident that the API is truly flexible enough.

Be as rigid as you can upfront. Once you add features, it’s really hard to take features away. But it’s quite easy to add features later. If you start with something rigid, it’s easier to understand. It’s easier to maintain and you can always add a few more switches later.

[00:36:00] – Reusable components

The reason that we can’t reuse code is every time a new project comes up, people are spending up their own ideas rather than leveraging standards that should have been put in place previously.

We’ve had the technical ability to do this for a long time. We just haven’t been around long enough for consolidation to happen, for standardization to happen. You look at how quickly things are changing in our industry. For instance, a couple of years ago, everybody had pretty much decided that two-way binding was the way to build web applications. And then, React came along and shook that up. So today, you have different ways of thinking about that issue.

[00:42:45] – Component development on teams

Aimee’s team has component development and they’re using Angular 1.6. All of our base components are sitting in a seed application. We just go in when we want to create a new property and we just extend all of those components with specific functionalities that we need.

[00:47:45] – Mobile to web crossover

Cory’s team is creating React components but it’s not leveraged on a mobile application. But people use React Native components on the web. And in fact, if you use create-react-app today, you can do that right now. It’s wired up to work in React Native components. In that way, you can literally have these same components running on your Native mobile apps as you do on your web application.

[00:50:00] – Challenge

Cory’s challenge for everybody listening is sit down with your team and have a quick conversation about whether you think components make sense. Look back at the last few months of development and say, "if we have a reusable component library, what would be in it? How often have we found ourselves copying and pasting code between different projects? How much benefit would we get out of this story?"

Once you’ve realized the benefits of the component model, both in the way that makes you think about your application, in a way that it helps you move faster and faster over time, I really think you won’t go back to the old model. I’d encourage people to investigate reusable components, whether that’d be React, Angular, Vue or Ember.

Picks

Cory House

• Creating Reusable React Components on Pluralsight
• Ted Talk: Why You Should Define your Fears Instead of Your Goals by Tim Ferriss

Joe Eames

• UI-Router
• Persistence

Aimee Knight

• Ask HN: People who completed a boot camp 3+ years ago, what are you doing now?
• NgAtlanta

Charles Max Wood

• Upwork.com

JSJ 269 Reusable React and JavaScript Components with Cory House

On today’s episode of JavaScript Jabber, we have panelists Joe Eames, Aimee Knight, Charles Max Wood, and playing the part of both host and guest, Cory House. Encourage your team to investigate reusable components, whether that’d be React, Angular, Vue, or Ember. Tune in!

[00:01:35] – Overview

We can finally write reusable components that it is really lightweight. It doesn’t take much framework-specific code to get things done.

Around 3 years ago, the idea of web component standard was all front-end developers could share our components with each other whether someone is in Angular or React. Web components continue to be an interesting standard but people continue to reach for JavaScript libraries instead – React, Angular, Vue. 

[00:04:50] – Browser support issue

The story in JavaScript libraries is easier. You have more power, more flexibility, more choices, and get superior performance, in certain cases, by choosing a JavaScript library over the standard right now. If you try to use the web components standard, you have to Polyfill-in some features so you can run things across browser. You also won’t get JavaScript features like intelligently splitting bundles and lazy load different components.

Whether you’re in Angular or React, you have this model of putting your data in your curly braces. That setup is non-existent in standardized web components. You have to play the game of putting and pulling data into and out the DOM using DOM selectors. You actually take a step backward in developer ergonomics when you choose to leverage the platform instead.

[00:07:50] – Polymer

The reason that Polymer is useful is it adds some goodness on top of web components. One of those things is that it makes it easier to bind in data and not having to do things like writing a DOM query to be able to get your hands on this div and put this text inside of it. With Polymer, you can do something that feels more like Angular, where you can put in your curly braces and just bind in some data into that place. Polymer ends up adding some nice syntactic sugar on top of the web components standard just to make it easier to create web components. Polymer is also used to bundle in Polyfill for the features across browser.   

[00:14:20] – Standards are dead

No. The standard itself has been embraced at different levels by different libraries. What you can see for the near future is popular libraries leveraging pieces of the web components platform to do things in a standard-spaced way. Effectively, Angular, Vue, Aurelia, are going to be abstractions over the web components standard. Arguably the most popular way to do components today is React. But React completely ignores the web components standard. When you look at React, you can’t see what piece of the web components standard would fundamentally make React a better component library.

Cory can’t seem to run to anybody that is actually using the standard in production to build real applications. People continue to reach for the popular JavaScript libraries that we so often hear about.

[00:17:05] – Libraries making reusable components

There is a risk that it would have been a waste for people writing components on Angular, for React, for Vue. But it’s not necessarily safer writing on the web component standard when you have so few people leveraging that standard. There’s always the risk that that standard may shift as well.

As an example, Cory’s team created approximately 100 reusable components in React. If they end up moving to a hot new library, the components are really just functions that take parameters and contain HTML. There is little there

[00:21:20] – Why opt for reusable components

Reusable components are inherently useful in a situation where you’re going to be doing something more than once. If you think about any work that you do as a software developer, we’d like to think that we’re coming in and creating new things but often it is groundhogs day. There are all sorts of opportunities for reuse.

As a company, we want to encapsulate our forms in reusable components so it’s literally impossible for our software developers to do something that goes against our standard. That’s the power of reusable components.  

[00:31:20] – Rigid component vs. flexible component

As component developers, if we try to create a reusable component in a vacuum, bad things happen. If you’re going to do a reusable component, start by solving a specific problem on a given application. If we think that a component’s going to be useful in multiple places, we put it in a folder called reusable right there in our application source folder.

We try to follow that rule of three as well. If we’ve taken that component and used it in 3 places, that’s a good sign that we should extract it out, put it in our NPM package, that way, everybody has this centralized component to utilize. At that point, it has been tested. It’s been through the fire. People have used it in the real world in a few places so we can be confident that the API is truly flexible enough.

Be as rigid as you can upfront. Once you add features, it’s really hard to take features away. But it’s quite easy to add features later. If you start with something rigid, it’s easier to understand. It’s easier to maintain and you can always add a few more switches later.

[00:36:00] – Reusable components

The reason that we can’t reuse code is every time a new project comes up, people are spending up their own ideas rather than leveraging standards that should have been put in place previously.

We’ve had the technical ability to do this for a long time. We just haven’t been around long enough for consolidation to happen, for standardization to happen. You look at how quickly things are changing in our industry. For instance, a couple of years ago, everybody had pretty much decided that two-way binding was the way to build web applications. And then, React came along and shook that up. So today, you have different ways of thinking about that issue.

[00:42:45] – Component development on teams

Aimee’s team has component development and they’re using Angular 1.6. All of our base components are sitting in a seed application. We just go in when we want to create a new property and we just extend all of those components with specific functionalities that we need.

[00:47:45] – Mobile to web crossover

Cory’s team is creating React components but it’s not leveraged on a mobile application. But people use React Native components on the web. And in fact, if you use create-react-app today, you can do that right now. It’s wired up to work in React Native components. In that way, you can literally have these same components running on your Native mobile apps as you do on your web application.

[00:50:00] – Challenge

Cory’s challenge for everybody listening is sit down with your team and have a quick conversation about whether you think components make sense. Look back at the last few months of development and say, "if we have a reusable component library, what would be in it? How often have we found ourselves copying and pasting code between different projects? How much benefit would we get out of this story?"

Once you’ve realized the benefits of the component model, both in the way that makes you think about your application, in a way that it helps you move faster and faster over time, I really think you won’t go back to the old model. I’d encourage people to investigate reusable components, whether that’d be React, Angular, Vue or Ember.

Picks

Cory House

• Creating Reusable React Components on Pluralsight
• Ted Talk: Why You Should Define your Fears Instead of Your Goals by Tim Ferriss

Joe Eames

• UI-Router
• Persistence

Aimee Knight

• Ask HN: People who completed a boot camp 3+ years ago, what are you doing now?
• NgAtlanta

Charles Max Wood

• Upwork.com

JSJ 271: SharePoint Extensions in JavaScript with Mike Ammerlaan and Vesa Juvonen

This episode is a live episode from Microsoft Build where AJ O'Neal and Charles Max Wood interview Mike Ammerlaan and Vesa Juvonent about building extensions for SharePoint with JavaScript.

[00:01:28] Mike Ammerlaan introduction
Mike has worked at Microsoft for a long time on multiple Microsoft products and projects. He's currently on the Office Ecosystem Marketing Team.

[00:01:52] Vesa Juvonen introduction
Ves a is Senior Program Manager for the SharePoint Splat team. He's been with Microsoft for about 11 years and manages the community and documentation for the SharePoint framework.

[00:02:18] What is the SharePoint Framework?
This is how you write SharePoint extensions with JavaScript. SharePoint has changed. It now works with common modern development tools and web development techniques. SharePoint consolodates the extension effort

[00:03:32] What is SharePoint?
File sharing, team sites, communication points for teams. Part of Office 365. You use Web Parts to add functionality to SharePoint. Web Parts provide functionality like widgets and are scoped to a team, group, or set of users. It's usually hosted on premises, but you can also use it with Office 365 as a hosted solution.

[00:05:56] What extensions can you build for SharePoint?
You can build widgets for your front page or intranet. You can also add user management or data management or document management.

Examples:

• Dashboards
• Mini Applications
• Scheduling and Time Tracking
• Document Storage
• Source code repositories

[00:07:39] What is WebDAV and how does it relate?
WebDAV is a protocol for accessing documents and SharePoint supports it among other protocols for managing documents.

[00:08:36] Do I have to build front-end and back-end components to get full functionality?
You can build the front-end UI with Angular and other frameworks. And then build a service in Azure on the backend. The backend systems can then access Line of Business systems or other data systems.

It really does take multiple skill sets to build extensions for SharePoint.

[00:11:10] SharePoint on Mobile
There is a mobile web app and the Web Parts work through the mobile application. You can also use any browser to connect to the application.

[00:12:08] Building extensions with standard Angular or React component libraries
There are standard Yeoman templates. You can also pull in the components through React or Angular just like what Microsoft does.

Newer Angular versions are designed for Single Page Apps and SharePoint isn't necessarily set up to work that way. The Web Parts are isolated from each other and Angular requires some workarounds.

[00:14:30] Getting around sandboxing
Google and Microsoft are talking to each other to see how to work around this when there are multiple sandboxed applications that can't talk to each other in very simple ways.

[00:15:39] Application library or naming collisions if my UI uses different versions or clobber page wide settings
There are guides for a lot of this. React does a bunch of the isolation work.

Addons are iframed in and an API token is given to grant access to the data and APIs.

Microsoft also reviews and approves plugins.

[00:18:30] How do you get started and make money at this?
Look at the SharePoint store. You can build things through websites and pages and offer the plugins through the store.

You can request a SharePoint tenant installation from the Microsoft Dev Tools for free. Then you can build into the tenant site. The rest of the tools are available on npm.

SharePoint Developer Tools

[00:22:13] Automated testing for SharePoint extensions
Unit testing is built in for JavaScript. Testing the UI's require you to sign into Office 365. There are people doing it, though.

[00:22:54] Building internal-only extensions
SharePoint is an enterprise tool, so a lot of enterprises may not want to install extensions from the store. You can definitely build and install private plugins for SharePoint setups. They also have their own backend systems that will require custom development.

[00:25:50] Office 365, SharePoint, and OneDrive
Office 365 is used by people across many different sized organizations and SharePoint is much more enterprise. Office 365 tools store files and information in SharePoint.

What about OneDrive versus Sharepoint? OneDrive is focused for one person. SharePoint is focused around a team. But they have the same APIs and use the same technology stack.

[00:29:05] The history and future of SharePoint
It started out on premises and has moved to the cloud. The SharePoint team is working to keep it available and useful in the modern cloud based era.

[00:30:25] What does the API footprint look like?
It spans modifying lists, data objects, attributes, items in a list, put Web Parts on a page, modify the experience, and manage and modify access, users, and documents. SharePoint is a way of building a way of conveying information.

SharePoint is layers of data and scopes.

[00:35:26] Tutorials and Open Source
dev.office.com
The Sharepoint framework is not open source yet, but they're working on that. They also need to open source the Yeoman templates.
Open source samples are available at github.com/sharepoint.

Picks

Charles Max Wood

• BlueTick
• Zapier
• ScheduleOnce
• Moo.com
• Advice: Take the time to go talk to people.
  Vesa adds that you should go to a session that's on something completely outside your experience.

AJ O'Neal

• The Circle
• Spontaneity/Happiness: AJ tells a story about a woman he saw running through sprinklers.
• Oh the places you'll go by Dr. Seuss: AJ talks about a journal entry he read at a yard sale.

Mike Ammerlaan

• Super hot VR on Oculus Rift

Vesa Juvonen

• Family

A big thanks to Microsoft, DotNetRocks, and Build!

JSJ 272: Functional Programming and ClojureScript with Eric Normand

This episode of JavaScript Jabber features panelists Aimee Knight and Charles Max Wood. Special guest Eric Normand is here to talk about functional programming and ClojureScript. Tune in to learn more!

[00:1:14] Introduction to Eric Normand

Eric works for purelyfunctional.tv. The main target market for his company is those people who want to transition into functional programming from their current job. He offers them support, shows them where to find jobs, and gives them the skills they need to do well.

[00:02:22] Address that quickly

Functional programming is used at big companies such as Wal-Mart, Amazon, EBay, Paypal, and banks. They all have Clojure but it is not used at the scale of Java or Ruby.

So yes, people are using it and it is influencing the mainstream programming industry.

[00:3:48] How do you build an application?

A common question Eric gets is, “How do I structure my application?” People are used to using frameworks. Most start from an existing app. People want a process to figure out how to take a set of features and turn it into code. Most that get into functional programming have development experience. The attitude in functional programming is that they do not want a framework. Clojure needs to be more beginner friendly. His talk is a four-step process on how to turn into code.

[00:05:56] Can you expand on that a little?

There are four steps to the process of structuring an application.

1. Develop a metaphor for what you are trying to do. Developing the first implementation. How would you build it if you didn’t have code?
2. Develop the operations. What are their properties? Example: will have to sort records chronological.
3. Develop relationships between the operations.
4. Run tests and refactor the program. Once you have that, you can write the prototype.

[00:13:13] Why can’t you always make the code better?

Rules can’t be refactored into new concepts. They have to be thrown away and started completely over. The most important step is to think before beginning to write code. It may be the hardest part of the process, but it will make the implementation easier.

[00:17:20] What are your thoughts on when people take it too far and it makes the code harder to read?

He personally has written many bad abstractions. Writing bad things is how you get better as a programmer. The ones that go too far are the ones that don’t have any basis or are making something new up. They are trying to be too big and use no math to back up their code.

[00:20:05] Is the hammock time when you decide if you want to make something abstract or should you wait until you see patterns develop?

He thinks people should think about it before, although always be making experiments that do not touch production.

[00:23:33] Is there a trade off between using ClojureScript and functional JavaScript?

In terms of functional programming in JavaScript don’t have some of the niceties that there are in Clojure script. Clojure Script has a large standard library. JavaScript is not as well polished for functional programming; it is a lot of work to do functional programming it and not as much support.

[00:27:00:] Dave Thomas believes that the future of software is functional programming. Do you agree?

Eric thinks that it seems optimistic. He doesn’t see functional programming take over the world but does think that it has a lot to teach. The main reason to learn functional programming is to have more tools in your toolbox.

[00:31:40] If this is a better way to solve these problems, why aren’t people using it?

There is a prejudice against functional programming. When Eric was first getting into it, people would ask why he was wasting his time. Believes that people are jaded. Functional programming feels foreign because people are used to a familiar way of programming; they usually start with a language and get comfortable.

[00:40:58] If people want to get started with it, is there an easy way in?

Lodash is great to start replacing for loops. It will clean up code. There are other languages that compile to JavaScript. For example, Elm is getting a lot of attention right now. It is a Haskell like syntax. If you want more of a heavyweight language, use TypeScript or PureScript. ClojureScript is into live programming. You are able to type, save, and see results of the code immediately on the screen in front of you.

Picks

Aimee:

• The Hidden Cost of Abstraction 
• What Functional Language Should I Learn 

Eric

• Steven King, On Writing 
• Youtube Channel: Tested  

Charles

• Ionic Framework

Links

• Purely Functional TV 
• Blog 
• Building Composable Abstractions 

Charles Max Wood

Special Guests: 

Amanda Silver

In this episode, Charles is at Microsoft Connect 2017 in NYC. Charles speaks with Amanda Silver. Amanda is deemed the  TypeScript and future of JavaScript guru, and this year's speakers at Microsoft Connect with Visual Studio Live Share. Amanda shares what is new with TypeScript and how that is a kind of subscript to JavaScript. Amanda explains the big picture of TypeScript’s inception and where she believes the language will be most efficient and effective for JavaScript and TypeScript developers.

In particular, we dive pretty deep on:

• What is new in TypeScript?
• Keep JavaScript and TypeScript aligned
• TypeScript is implemented to create larger scaled applications
• Integration with VS Code, etc.
• Building better tools for JavaScript Developers
• When would this be taken on by users
• Defaults in Visual Studio
• TypeScript replacing JavaScript type service
• TypeScript is written in TypeScript
• Chakra runtime
• Diaspora
• The different faces of JavaScript
• Optimized JavaScript runtime
• Languages should be created with tooling
• A satisfying tooling experience
• Foot Guns
• New Tokens
• Eco-systems and metadata
• Multi-phase
• Minimum common denominator constantly changing
• Collaborating on the same code
• Open Source and the impact
• How to move to open source
• Contributing
• The next thing for TypeScript
• The future of JavaScript
• And much more!

Links:

• @amandaksilver
•  

Picks:

Amanda

• Visual Studio Live Share
• Instinct of learning technology

Charles

• Visual Studio Live Share
• AI

Panel:

Charles Max Wood 

Aimee Knight

AJ O’Neal

Joe Eames 

Special Guests: Gareth McCumskey

In this episode, JavaScript Jabber speaks with Gareth McCumskey about Serverless For JavaScript. Gareth leads the dev team at Expat Explore in Cape Town, South Africa. Gareth and this team specialize in exploring the Serverless realm in JavaScript. The JavaScript Jabbers panel and Gareth discuss the many different types of serverless systems, and when to implement them, how serverless system work, and when to go in the direction of using Serverless. 

In particular, we dive pretty deep on:

• What does it mean to be Serverless? 
• Since platform as a service.
• Microservice on Docker 
• Firebase
• “no backend” 
• Backend systems 
• Cloud functions and failure in systems 
• How do you start to think about a serverless system? 
• How do decide what to do?
• AWS Lambda 
• Working in a different vendor
• Node 4 
• Programming JS to deploy 
• Using libraries for NPM
• How is works with AWS Lambda
• Where is the database?
• More point of failure? 
• Calls to Slack?
• Authentication
• Micro Services
• Elastic Bean Stalk
• Static Assets, S3, Managing
• Testing the services 
• Integration testing
• And much more! 

Links:

• @garethmcc
• @expatexplore
• gareth.mccumskey.com
• https://github.com/garethmcc
• serverless.com

Picks:

Aimee

• Serverless Architectures 
• NG-BE Conference 

AJ

• Documentary on Enron
• Hard Thing about Hard Things 

Charles

• Serverless Framework
• The Storm Light Achieves 
• Avengers: Infinity War

Gareth

• Building MicroServices 
• Skeptics Guide To The Universe Podcast
• Expate Explore 

Joe 

• Wonder -  Movie
• Gloom In Space - Board Game 

Panel: 

Charles Max Wood

Cory House

Joe Eames

Aimee Knight

Special Guests: John Papa

In this episode, JavaScript Jabber panelist speak with John Papa. John has been doing web programming for over twenty years on multiple platforms and has been contributing to the developer communities through conferences, authoring books, videos and courses on Pluralsight.

John is on the show to discuss an articles he wrote on A Look at Angular Along Side Vue, and another article on Vue.js  with TypeScript. John talks about the new features with the different versions of Angular technologies, anxiety in the different features, comparisons between the technologies and use case with Angular.

In particular, we dive pretty deep on:

• A look at Angular Along Side Vue - Article
• Angular 5, Amber,Vue,  React, Angular
• Angular 2 - different features
• CLI
• Spell Webpack
• Comparisons - Why the anxiety?
• Opinions of Angular and sprinkling in other technologies
• Vue is the easy to use with Angular
• Are there breakpoints with the uses case?
• Choosing technologies
• Talk about working with Vue and Angular
• DSL - Domain Specific Language
• Vue and 3rd party libraries
• Talk about Vue working with TypeScript
• Vue.js  with TypeScript
• Vue with TypeScript looks similar to Angular
• Vetur
• What does 2018 have in store for Angular?
• Native apps and web functionality
• And much more!

Links:

• https://johnpapa.net
• Vue.js  with TypeScript
• A Look at Angular Along Side Vue
• @john_papa
• https://github.com/johnpapa

Picks:

Corey

• cypress.io

Charles

• E Myth Revisited
• Profit First 
• Dunkirk

Aimee

• Crucial Conversations 
• Ripple or XRP

Joe

• The Greatest Showman
• Better Late Then Never
• Vue
• 7 Languages In 7 Weeks  - Book

John

• Jumanji 2017
• Emotional Intelligence

Panel: 

AJ O’Neal

Joe Eames

Aimee Knight

Special Guests: Chris Ferdinandi

In this episode, JavaScript Jabber panelist speak with Chris Ferdinandi. Chris teaches vanilla JavaScript to beginners and those coming from a design background. Chris mentions his background in Web design and Web Develop that led him JavaScript development. Chris and the JSJ panelist discuss the best ways to learn JavaScript, as well as resources for learning JavaScript. Also, some discussion of technologies that work in conjunction with vanilla JavaScript.

In particular, we dive pretty deep on:

• Teaching JavaScript - Beginners and Design patrons
• Web Design and Web Development
• CSS Tricks 
• Todd Motto
• How to do jQuery Things without jQuery
• Doing things like mentors (Todd)
• When JavaScript makes sense.
• CSS is easier to learn then JS?
• Being good at CSS and JS at the same time?
• How about Node developers?
• jRuby, DOM
• Documentation
• And much more!

Links:

• https://github.com/cferdinandi
• https://gomakethings.com
• @ChrisFerdinandi
• https://www.linkedin.com/in/cferdinandi
•  

Picks:

AJ

• Discover Card
• Mistborn 

Aimee

• Your Smart Phone is Making You Stupid…
• Crypto Currency

Joe

• Mystic Vale
• Kedi

Chris

• https://gomakethings.com
• Teva Mush

Panel:

• Charles Max Wood
• Cory House
• Aimee Knight

Special Guests: Ben Titzer

In this episode, the JavaScript Jabber panelists discuss WebAssembly and JavaScript with Ben Titzer. Ben is a JavaScript VM engineer and is on the V8 team at Google. He was one of the co-inventors of WebAssembly and he now works on VM engineering as well as other things for WebAssembly. They talk about how WebAssembly came to be and when it would be of most benefit to you in your own code.

In particular, we dive pretty deep on:

• Ben intro
• JavaScript
• Co-inventor of WebAssembly (Wasm)
• Joined V8 in 2014
• asm.js
• Built a JIT compiler to make asm.js faster
• TurboFan
• What is the role of JavaScript? What is the role of WebAssembly?
• SIMD.js
• JavaScript is not a statically typed language
• Adding SIMD to Wasm was easier
• Easy to add things to Wasm
• Will JavaScript benefit?
• Using JavaScript with Wasm pros and cons
• Pros to compiling with Wasm
• Statically typed languages
• The more statically typed you are, the more you will benefit from Wasm
• TypeScript
• Is WebAssembly headed towards being used in daily application?
• Rust is investing heavily in Wasm
• WebAssembly in gaming
• And much, much more!

Links:

• JavaScript
• V8
• WebAssembly
• asm.js
• TurboFan
• TypeScript
• Rust
• WebAssembly GitHub
• Ben’s GitHub

Picks:

Charles

• Ready Player One Movie
• DevChat.tv YouTube
• Alexa Flash Briefings: Add skill for “JavaScript Rants”

Cory

• npm Semantic Version Calculator
• Kent Beck Tweet

Aimee

• MDN 418 Status code
• Quantity Always Trumps Quality blog post

Ben

• American Politics

Panel:

• AJ ONeal
• Aimee Knight
• Joe Eames

Special Guests: Kyle Simpson

In this episode, the JavaScript Jabber panelists discuss light functional JavaScript with Kyle Simpson. Kyle is most well-known for writing the books You Don’t Know JS and is on the show today for his book Functional-Light JavaScript. They talk about what functional programming is, what side-effects are, and discuss the true heart behind functional programming. They also touch on the main focus of functional programming and much more!

In particular, we dive pretty deep on:

• You Don’t Know JS
• Functional-Light JavaScript
• From the same spirit as first books
• JavaScript
• Documents journey of learning
• What does Functional Programming mean?
• Functional programming is being re-awoken
• Many different definitions
• History of functional programming
• Programming with functions
• What is a function?
• “A collection of operations of doing some task” is what people think functions are
• What a function really is
• Map inputs to outputs
• What is a side-effect?
• Side-effects should be intentional and explicit
• The heart of functional programming
• Refactoring
• Can’t write a functional program from scratch
• What functional programming focuses on
• Making more readable and reliable code
• Pulling a time-stamp
• Defining a side-effect
• And much, much more!

Links:

• You Don’t Know JS
• Functional-Light JavaScript
• JavaScript
• Kyle’s GitHub
• @getify

Picks:

Aimee

• What Does Code Readability Mean?
• @FunctionalKnox
• HTTP 203 Podcast

AJ

• IKEA

Joe

• Barking Up the Wrong Tree by Eric Barker
• Workshops in general

Kyle

• GDPR
• The start-up’s guide to the GDPR
• Hatch
• Fluent Conf

Panel:

Charles Max Wood

Special Guests: Vesa Juvonen

In this episode, the JavaScript Jabber panel talks to Vesa Juvonen about building SharePoint extensions with JavaScript. Vesa is on the SharePoint development team and is responsible for the SharePoint Framework, which is the modern way of implementing SharePoint customizations with JavaScript. They talk about what SharePoint is, why they chose to use JavaScript with it, and how he maintains isolation. They also touch on the best way to get started with SharePoint, give some great resources to help you use it, and more!

In particular, we dive pretty deep on:

• Vesa intro
• What is SharePoint?
• Has existed since 2009
• People either know about it and use it or don’t know what it is
• Baggage from a customization perspective
• Why JavaScript developers?
• Modernizing development
• SharePoint Framework
• Microsoft Ignite Conference
• Is there a market for it?
• System integrators
• Angular Element and React
• React for SharePoint Framework back-end
• Supports Vue
• React Round Up Podcast
• How do you maintain isolation?
• What’s the best way to get started with SharePoint extensions?
• Office 365 Developer Program
• SharePoint documentation
• SharePoint YouTube
• What kinds of extensions are you seeing people build?
• And much, much more!

Links:

• SharePoint
• JavaScript
• SharePoint Framework
• Microsoft Ignite Conference
• Angular Element
• React
• Vue
• React Round Up Podcast
• Office 365 Developer Program
• SharePoint documentation
• SharePoint YouTube
• @OfficeDev
• @vesajuvonen
• Vesa’s blog
• Vesa’s GitHub
• @SharePoint

Sponsors

• Kendo UI
• Sentry
• Digital Ocean

Picks:

Charles

• Zig Ziglar
• Conversations with My Dog by Zig Ziglar
• Pimsleur Lessons on Audible

Vesa

• Armada by Ernest Cline

Panel:

• Charles Max Wood
• AJ ONeal

Special Guests: Kurt Mackey

In this episode, the JavaScript Jabber panel talks to Kurt Mackey about Fly.io. At Fly.io, they are "building a JavaScript platform that gives you the power to build your own CDN." They talk about how Fly.io came to fruition, how CDN caching works, and what happens when you deploy a Fly app. They also touch on resizing images with Fly, how you actually build JavaScript platforms using Fly, and more!

In particular, we dive pretty deep on:

• Fly.io
• Building a programmable CDN
• High level overview of Fly.io
• How did this project come together?
• CDNs didn’t work with dynamic applications
• Has been working on this since 2008
• Extend application logic to the “edge”
• Putting burden of JavaScript “nastiest” onto the web server
• Fly is the proxy layer
• Getting things closer to visitors and users
• CDN caching
• Cache APIs
• Writing logic to improve your lighthouse score
• Have you built in resizing images into Fly?
• Managing assets closer to the user
• Can you modify your own JavaScript files?
• What happens when you deploy a Fly app
• Having more application logic
• DOM within the proxy
• Ghost
• React and Gatsby
• Intelligently loading client JavaScript
• How do you build the JavaScript platform?
• And much, much more!

Links:

• Fly.io
• JavaScript
• Ghost
• Gatsby
• React
• @flydotio
• @mrkurt
• Kurt at ARS Technica
• Kurt’s GitHub

Sponsors

• Kendo UI
• Sentry
• Digital Ocean

Picks:

Charles

• GitLab

AJ

• Gitea
• Black Panther

Kurt

• Packet.net
• The Three-Body Problem by Cixin Liu

Panel:

• Aimee Knight
• Joe Eames
• AJ ONeal

Special Guests: Jeremy Fairbank

In this episode, the JavaScript Jabber panel talks to Jeremy Fairbank about his talk Practical Functional Programming. Jeremy is a remote software developer and consultant for Test Double. They talk about what Test Double is and what they do there and the 6 things he touched on in his talk, such as hard to follow code, function composition, and mutable vs immutable data. They also touch on the theory of unit testing, if functional programming is the solution, and more!

In particular, we dive pretty deep on:

• Jeremy intro
• Works for Test Double
• What he means by “remote”
• What is Test Double?
• They believe software is broken and they are there to fix it
• His talk - Practical Functional Programming
• The 6 things he talked about in his talk
• Practical aspects that any software engineer is going to deal with
• Purity and the side effects of programming in general
• Hard to follow code
• Imperative VS declarative code
• Code breaking unexpectedly
• Mutable data VS immutable data
• The idea of too much code
• Combining multiple functions together to make more complex functions
• Function composition
• Elm, Elixir, and F#
• Pipe operator
• Scary to refactor code
• Static types
• The idea of null
• The theory of unit testing
• Is functional programming the solution?
• His approach from the talk
• And much, much more!

Links:

• Test Double
• His talk - Practical Functional Programming
• Elm
• Elixir
• F#
• @elpapapollo
• jeremyfairbank.com
• Jeremy’s GitHub
• Jeremy’s YouTube

Sponsors

• Kendo UI
• Sentry
• Digital Ocean

Picks:

Aimee

• American Dollar
• Force with lease

AJ

• Superfight

Joe

• The 2018 Web Developer Roadmap by Brandon Morelli
• Svelte

Jeremy

• Programming Elm
• The Secrets of Consulting by Gerald M. Weinberg
• Connect.Tech

Panel:

• AJ O’Neal
• Aimee Knight
• Joe Eames
• Charles Max Wood

Special Guests: Vitali Zaidman

In this episode, the panel talks with programmer, Vitali Zaidman, who is working with Software Solutions Company. He researches technologies and starts new projects all the time, and looks at these new technologies within the market. The panel talks about testing JavaScript in 2018 and Jest.

Show Topics:

1:32 – Chuck: Let’s talk about testing JavaScript in 2018.

1:53 – Vitali talks about solving problems in JavaScript.

2:46 – Chuck asks Vitali a question.

3:03 – Vitali’s answer.

3:30 – Why Jest? Why not Mocha or these other programs?

3:49 – Jest is the best interruption of what testing should look like and the best practice nowadays. There are different options, they can be better, but Jest has this great support from their community. There are great new features.

4:31 – Chuck to Joe: What are you using for testing nowadays?

4:43 – Joe: I use Angular, primarily.

6:01 – Like life, it’s sometimes easier to use things that make things very valuable.

7:55 – Aimee: I have heard great things about Cypress, but at work we are using another program.

8:22 – Vitali: Check out my article.

8:51 – Aimee: There are too many problems with the program that we use at work.

9:39 – Panelist to Vitali: I read your article, and I am a fan. Why do you pick Test Café over Cypress, and how familiar are you with Cypress? What about Selenium and other programs?

10:12 – Vitali: “Test Café and Cypress are competing head-to-head.”

Listen to Vitali’s suggestions and comments per the panelists’ question at this timestamp.

11:25 – Chuck: I see that you use sign-on...

12:29 – Aimee: Can you talk about Puppeteer? It seems promising.

12:45 – Vitali: Yes, Puppeteer is promising. It’s developed by Google and by Chrome. You don’t want to use all of your tests in Puppeteer, because it will be really hard to do in other browsers.

13:26: Panelist: “...5, 6, 7, years ago it was important of any kind of JavaScript testing you had no idea if it worked in one browser and it not necessarily works in another browser. That was 10 years ago. Is multiple browsers testing as important then as it is now?

14:51: Vitali answers the above question.

15:30 – Aimee: If it is more JavaScript heavy then it could possibly cause more problems.

15:56 – Panelist: I agree with this.

16:02 – Vitali continues this conversation with additional comments.

16:17 – Aimee: “I see that Safari is the new Internet Explorer.”

16:23: Chuck: “Yes, you have to know your audience. Are they using older browsers? What is the compatibility?”

17:01 – Vitali: There are issues with the security. Firefox has a feature of tracking protection; something like that.

17:33 – Question to Vitali by Panelist.

17:55 – Vitali answers the question.

18:30 – Panelist makes additional comments.

18:43 – If you use Safari, you reap what you sow.

18:49 – Chuck: I use Chrome on my iPhone. (Aimee does, too.) Sometimes I wind up in Safari by accident.

19:38 – Panelist makes comments.

19:52 – Vitali tells a funny story that relates to this topic.

20:45 – There are too many standards out there.

21:05 – Aimee makes comments.

21:08 – Brutalist Web Design. Some guy has this site – Brutalist Web Design – where he says use basic stuff and stop being so custom. Stop using the web as some crazy platform, and if your site is a website that can be scrolled through, that’s great. It needs to be just enough for people to see your content.

22:16 – Aimee makes additional comments about this topic of Brutalist Web Design.

22:35 – Panelist: I like it when people go out and say things like that.

22:45 – Here is the point, though. There is a difference between a website and a web application. Really the purpose is to read an article.

23:37 – Vitali chimes in.

24:01 – Back to the topic of content on websites.

25:17 – Panelist: Medium is very minimal. Medium doesn’t feel like an application.

26:10 – Is the website easy enough for the user to scroll through and get the content like they want to?

26:19 – Advertisement.

27:22 – See how far off the topic we got?

27:31 – These are my favorite conversations to have.

27:39 – Vitali: Let’s talk about how my article got so popular. It’s an interesting thing, I started researching “testing” for my company. We wanted to implement one of the testing tools. Instead of creating a presentation, I would write first about it in Medium to get feedback from the community as well. It was a great decision, because I got a lot of comments back. I enjoyed the experience, too. Just write about your problem in Medium to see what people say.

28:48 – Panelist: You put a ton of time and energy in this article. There are tons of links. Did you really go through all of those articles?

29:10 – Yes, what are the most permanent tools? I was just reading through a lot of comments and feedback from people. I tested the tools myself, too!

29:37 – Panelist: You broke down the article, and it’s a 22-minute read.

30:09 – Vitali: I wrote the article for my company, and they ad to read it.

30:24 – Panelist: Spending so much time – you probably felt like it was apart of your job.

30:39 – Vitali: I really like creating and writing. It was rally amazing for me and a great experience. I feel like I am talented in this area because I write well and fast. I wanted to express myself.

31:17 – Did you edit and review?

31:23 – Vitali: I wrote it by myself and some friends read it. There were serious mistakes, and that’s okay I am not afraid of mistakes. This way you get feedback.

32:10 – Chuck: “Some people see testing in JavaScript, and people look at this and say there are so much here. Is there a place where people can start, so that way they don’t’ get too overwhelmed? Is there a way to ease into this and take a bite-size at a time?”

32:52 – Vitali: “Find something that works for them. Read the article and start writing code.”

He continues this conversation from here on out.

34:03 – Chuck continues to ask questions and add other comments.

34:16 – Vitali chimes-in. 

34:38 – Chuck. 

34:46 – Vitali piggybacks off of Chuck’s comments.

36:14 – Panelist: Let’s go back to Jest. There is a very common occurrence where we see lots of turn and we see ideas like this has become the dominant or the standard, a lot of people talk about stuff within this community. Then we get this idea that ‘this is the only thing that is happening.’ Transition to jQuery to React to... With that context do you feel like Jest will be a dominant program? Are we going to see Jest used just as common as Mocha and other popular programs?

38:15 – Vitali comments on the panelist’s question.

38:50 – Panelist: New features. Are the features in Jest (over Jasmine, Mocha, etc.) so important that it will drive people to it by itself?

40:30 – Vitali comments on this great question.

40:58 – Panelist asks questions about features about Jest.

41:29 – Vitali talks about this topic.

42:14 – Let’s go to picks!

42:14 – Advertisement.

Links:

• Vitali Zaidman’s Facebook
• Vitali Zaidman’s Medium
• Vitali Zaidman’s GitHub
• Vitali Zaidman’s NPM
• Vitali Zaidman’s LinkedIn
• Vitali Zaidman’s Medium Article
• JavaScript
• Brutalist Web Design
• Jasmine
• Cypress
• React
• jQuery
• Jest
• Protractor – end to end testing for Angular
• Test Café
• Intern
• Sinon
• XKCD

Sponsors:

• Kendo UI
• Sentry
• Digital Ocean
• Cache Fly

Picks:

AJ O’Neal

• Continuous from last week’s episode: Crossing the Chasm – New Technologies from Niche to General Adaptation.
• Go Lang

Joe Eames

• Board Game: Rajas of the Ganges
• Framework Summit Conference in Utah
• React Conference

Aimee Knight

• Hacker News – “Does Software Understand Complexity” via Michael Feathers
• Cream City Code

Chuck

• E-Book: How do I get a job?
• Express VPN

Vitali

• Book: The Square and The Tower: Networks and Power, from the Freemasons to Facebook by Niall Ferguson
• My article!

Panel:

• AJ O’Neal
• Aimee Knight
• Joe Eames
• Charles Max Wood

Special Guests: Chris Heilmann

In this episode, the panel talks with programmer, Chris Heilmann. He has written books about JavaScript, in addition to writing a blog about it and is an educator about this program.  He currently resides in Berlin, Germany. Let’s welcome our special guest and listen to today’s episode!

Show Topics:

2:19 – Chuck talks.

2:41 – Chris: He has talked about JavaScript in Berlin upon an invitation. You can get five different suggestions about how to use JavaScript. The best practices, I have found, are on the projects I am on now. JavaScript was built in ten days. My goal is to help people navigate through JavaScript and help them feel not disenfranchised. 

5:47 – Aimee: The overall theme is...

5:54 – Panelist: I really like what you said about helping people not feeling disenfranchised.

6:47 – Chris: There is a lot of peer pressure at peer conferences

7:30 – Aimee chimes in with some comments.

7:50: Chris: I think we need to hunt the person down that put...

8:03 – Panelist: A good point to that is, I try to avoid comments like, “Well, like we ALL know...”

8:27 – Chris: There are things NOT to say on stage. It happens, but we don’t want to say certain things while we are teaching people. We are building products with different groups, so keep that in mind.

9:40 – Aimee: My experience in doing this is that I have found it very rewarding to share embarrassing experiences that I’ve had. My advice would to tell people to let their guard down. It’s encouraging for me.

10:26 – Chris: It helps to show that you are vulnerable and show that you are still learning, too. We are all learning together. 90% of our job is communicating with others.

11:05 – Chuck: Now, I do want to ask this...

11:35 – Chris answers.

12:24 – What makes you say that? (Question to Chris)

12:25 – Chris answers.

13:55 – Chuck: The different systems out there are either widely distributed or...

You will have to work with other people. There is no way that people can make that on their own. If you can’t work with other people, then you are a hindrance.

14:31 – Aimee chimes in.

14:53 – Chris: They have to be very self-assured. I want to do things that are at the next level. Each developer has his or her own story. I want to move up the chain, so I want to make sure these developers are self-assured.

16:07 – Chris: Back to the article...

18:26 – Chuck: Yes, I agree. Why go and fight creating a whole system when it exists.

18:54 – Chris chimes in with some comments.

19:38 – Panelist: I still use console logs.

19:48 – Chris: We all do, but we have to...

19:55 – Aimee: In the past year, I can’t tell you how much I rely on this. Do I use Angular? Do I learn Vue? All those things that you can focus on – tools.

10:21 – Chris: We are talking about the ethics of interfaces. Good code is about accessibility, privacy and maintainability, among others. Everything else is sugar on top. We are building products for other people.

22:10 – Chuck: That is the interesting message in your post, and that you are saying: having a deep, solid knowledge of React (that is sort of a status thing...). It is other things that really do matter. It’s the impact we are having. It’s those things that will make the difference. Those things people will want to work with and solves their problems.

23:00 – Chris adds his comments. He talks about Flash.

24:05 – Chris: The librarian motto: “I don’t know everything, but I can look “here” to find the answer.” We don’t know everything.

24:31 – Aimee: Learn how to learn.

24:50 – Chris: There is a big gap in the market. Scratch is a cool tool and it’s these puzzle pieces you put together. It was hard for me to use that system. No, I don’t want to do that. But if you teach the kids these tools then that’s good. 

24:56 – Chuck: Here is the link, and all I had to do was write React components.

26:12 – Chris: My first laptop was 5x more heavy then this one is. Having access to the Internet is a blessing.

27:24 – Advertisement

28:21 – Chuck: Let’s bring this back around. If someone has gone through boot camp, you are recommending that they get use to know their editor, debugging, etc.

Chris: 28:47 – Chris: Yes, get involved within your community. GitHub. This is a community effort. You can help. Writing code from scratch is not that necessary anymore. Why rebuild something if it works. Why fix it if it’s not broken?

31:00 – Chuck talks about his experience.

31:13 – Chris continues his thoughts.

Chris: Start growing a community.

32:01 – Chuck: What ways can people get involved within their community?

32:13 – Chris: Meetup. There are a lot of opportunities out there. Just going online and seeing where the conferences

34:08 – Chris: It’s interesting when I coach people on public speaking. Sharing your knowledge and learning experience is great!

34:50 – Chuck: If they are learning how to code then...by interacting with people you can get closer to what you need/want.

35:30 – Chris continues this conversation.

35:49 – Chris: You can be the person that helps with x, y, z. Just by getting your name known then you can get a job offer.

36:23 – Chuck: How do you find out what is really good content – what’s worth your time vs. what’s not worth your time?

36:36 –Chris says, “That’s tricky!” Chris answers the question.

37:19: Chris: The best things out there right now is...

38:45 – Chuck: Anything else that people want to bring up?

39:00 – Chris continues to talk.

42:26 – Aimee adds in her thoughts.

Aimee: I would encourage people to...

43:00 – Chris continues the conversation.

Chris: Each project is different, when I build a web app is different then when I build a...

45:07 – Panelist: I agree. You talked about abstractions that don’t go away. You use abstractions in what you use. At some point, it’s safe to rly on this abstraction, but not this one. People may ask themselves: maybe CoffeeScript wasn’t the best thing for me.

46:11 – Chris comments and refers to jQuery.

48:58 – Chris continues the conversation.

Chris: I used to work on eight different projects and they worked on different interfaces. I learned about these different environments. This is the project we are now using, and this will like it for the end of time. This is where abstractions are the weird thing. What was the use of the abstraction if it doesn’t have longevity? I think we are building things too soon and too fast.

51:04 – Chris: When I work in browsers and come up with brand new stuff.

52:21 – Panelist: Your points are great, but there are some additional things we need to talk about. Let’s take jQuery as an example. There is a strong argument that if you misuse the browser...

53:45 – Chris: The main issue I have with jQuery is that people get an immediate satisfaction. What do we do besides this?

55:58 – Panelist asks Chris further questions.

56:25 – Chris answers.

Chris: There are highly frequent websites that aren’t being maintained and they aren’t maintainable anymore.

57:09 – Panelist: Prototypes were invented because...

57:51 – Chris: It’s a 20/20 thing.

58:04 – Panelist: Same thing can be said about the Y2K.

58:20 – Panelist: Yes, they had to solve that problem that day. The reality is...

58:44 – Chris: We learned from that whole experience.

1:00:51 – Chris: There was a lot of fluff around it.

1:01:35 – Panelist: Being able to see the future would be a very helpful thing.

1:01:43 – Chris continues the conversation.

1:02:44 – Chuck: How do people get ahold of you?

1:03:04 – Twitter is probably the best way.

1:03:32 – Let’s go to picks!

1:03:36 - Advertisement

Links:

• JavaScript
• So you Learned Java Script, what now? – Article
• WebHint
• Article by James Sinclair
• Clank!
• Angular
• GitHub
• Meetup
• Chris Heilmann’s Twitter
• Chris Heilmann’s Website
• Chris Heilmann’s Medium
• Chris Heilmann’s LinkedIn
• Chris Heilmann
• Chris Heilmann’s GitHub
• Smashing Magazine – Chris Heilmann
• jQuery
• CoffeeScript
• React
• Elixir

Sponsors:

• Kendo UI
• Sentry
• Digital Ocean
• Cache Fly
•  

Picks :

Amiee

• Hacker News -  How to deal with dirty side effects in your pure functional JavaScript

AJ

• KeyBase

Joe

• Framework Summit
• Clank
• ASMR

Charles

• Get a Coder Job Course
• The Iron Druid Chronicles
• Framework Summit

Chris

• Web Unleashed Toronto
• Kurzgesagt
• It Is Just You, Everything’s Not Shit

Panel:

• Aimee Knight
• Joe Eames
• Charles Max Wood

Special Guests: Ethan Brown

In this episode, the panel talks with Ethan Brown who is a technological director at a small company. They write software to facilitate large public organizations and help make projects more effective, such as: rehabilitation of large construction projects, among others. There is a lot of government work through the endeavors they encounter. Today, the panel talks about his article he wrote, and other topics such as Flex, Redux, Ruby, Vue.js, Automerge, block chain, and Elm. Enjoy!

Show Topics:

2:38 – Chuck: We are here to talk about the software side of things.

Let’s dive into what you are looking at mid-year what we need to know for 2018. You wrote this.

3:25 – Ethan: I start off saying that doing this podcast now, how quickly things change. One thing I didn’t think people needed to know was symbols, and now that’s changed. I had a hard time with bundling and other things. I didn’t think the troubles were worth it. And now a couple of moths ago (an open source project) someone submitted a PR and said: maybe we should be using symbols? I told them I’ve had problems in the past. They said: are you crazy?!

It’s funny to see how I things have changed.

4:47 – Panel: Could you talk about symbols?

4:58 – Aimee: Are they comparable to Ruby?

5:05 – Ethan talks about what symbols are and what they do!

5:52 – Chuck: That’s pretty close to how that’s used in Ruby, too.

6:04 – Aimee: I haven’t used them in JavaScript, yet. When have you used them recently?

6:15 – Ethan answers the question.

7:17 – Panelist chimes in.

7:27 – Ethan continues his answer. The topic of “symbols” continues. Ethan talks about Automerge.

11:18 – Chuck: I want to dive-into what you SHOULD know in 2018 – does this come from your experience? Or how did you drive this list?

11:40 – Ethan: I realize that this is a local business, and I try to hear what people are and are not using. I read blogs. I think I am staying on top of these topics being discussed.

12:25 – Chuck: Most of these things are what people are talking.

12:47 – Aimee: Web Assembly. Why is this on the list?

12:58 – Ethan: I put on the list, because I heard lots of people talk about this. What I was hearing the echoes of the JavaScript haters. They have gone through a renaissance. Along with Node, and React (among others) people did get on board. There are a lot of people that are poisoned by that. I think the excitement has died down. If I were to tell a story today – I would

14:23 – Would you put block chain on there? And AI?

14:34 – Panel: I think it’s something you should be aware of in regards to web assembly. I think it will be aware of. I don’t know if there is anything functional that I could use it with.

15:18 – Chuck: I haven’t really played with it...

15:27 – Panel: If you wrote this today would you put machine learning on there?

15:37 – Ethan: Machine Learning...

16:44 – Chuck: Back to Web Assembly. I don’t think you were wrong, I think you were early. Web Assembly isn’t design just to be a ... It’s designed to be highly optimized for...

17:45 – Ethan: Well-said. Most of the work I do today we are hardly taxing the devices we are using on.

18:18 – Chuck and panel chime in.

18:39 – Chuck: I did think the next two you have on here makes sense.

18:54 – Panel: Functional programming?

19:02 – Ethan: I have a lot of thoughts on functional programming and they are mixed. I was exposed to this in the late 90’s. It was around by 20-30 years. These aren’t new. I do credit JavaScript to bring these to the masses. It’s the first language I see the masses clinging to. 10 years ago you didn’t see that. I think that’s great for the programming community in general. I would liken it to a way that Ruby on Rails really changed the way we do web developing with strong tooling. It was never really my favorite language but I can appreciate what it did for web programming. With that said...(Ethan continues the conversation.)

Ethan: I love Elm.

21:49 – Panelists talks about Elm.

*The topic diverts slightly.

22:23 – Panel: Here’s a counter-argument. Want to stir the pot a little bit.

I want to take the side of someone who does NOT like functional programming.

24:08 – Ethan: I don’t disagree with you. There are some things I agree with and things I do disagree with. Let’s talk about Data Structures. I feel like I use this everyday. Maybe it’s the common ones. The computer science background definitely helps out.

If there was one data structure, it would be TREES. I think STACKS and QUEUES are important, too. Don’t use 200-300 hours, but here are the most important ones. For algorithms that maybe you should know and bust out by heart.

27:48 – Advertisement for Chuck’s E-book Course: Get A Coder Job

28:30 – Chuck: Functional programming – people talk bout why they hate it, and people go all the way down and they say: You have to do it this way....

What pay things will pay off for me, and which things won’t pay off for me? For a lot of the easy wins it has already been discussed. I can’t remember all the principles behind it. You are looking at real tradeoffs.  You have to approach it in another way. I like the IDEA that you should know in 2018, get to know X, Y, or Z, this year. You are helping the person guide them through the process.

30:18 – Ethan: Having the right tools in your toolbox.

30:45 – Panel: I agree with everything you said, I was on board, until you said: Get Merge Conflicts.

I think as developers we are being dragged in...

33:55 – Panelist: Is this the RIGHT tool to use in this situation?

34:06 – Aimee: If you are ever feeling super imposed about something then make sure you give it a fair shot, first.

34:28 – That’s the only reason why I keep watching DC movies.

34:41 – Chuck: Functional programming and...

I see people react because of the hype cycle. It doesn’t fit into my current paradigm. Is it super popular for a few months or...?

35:10 – Aimee: I would love for someone to point out a way those pure functions that wouldn’t make their code more testable.

35:42 – Ethan: Give things a fair shake. This is going back a few years when React was starting to gain popularity. I had young programmers all about React. I tried it and mixing it with JavaScript and...I thought it was gross. Everyone went on board and I had to make technically decisions. A Friend told me that you have to try it 3 times and give up 3 times for you to get it. That was exactly it – don’t know if that was prophecy or something. This was one of my bigger professional mistakes because team wanted to use it and I didn’t at first. At the time we went with Vue (old dog like me). I cost us 80,000 lines of code and how many man hours because I wasn’t keeping an open-mind?

37:54 – Chuck: We can all say that with someone we’ve done.

38:04 – Panel shares a personal story.

38:32 – Panel: I sympathize because I had the same feeling as automated testing. That first time, that automated test saved me 3 hours. Oh My Gosh! What have I been missing!

39:12 – Ethan: Why should you do automated testing? Here is why...

You have to not be afraid of testing. Not afraid of breaking things and getting messy.

39:51 – Panel: Immutability?

40:00 – Ethan talks about this topic.

42:58 – Chuck: You have summed up my experience with it.

43:10 – Panel: Yep. I agree. This is stupid why would I make a copy of a huge structure, when...

44:03 – Chuck: To Joe’s point – but it wasn’t just “this was a dumb way” – it was also trivial, too. I am doing all of these operations and look my memory doesn’t go through the roof. They you see it pay off. If you don’t see how it’s saving you effort, at first, then you really understand later.

44:58 – Aimee: Going back to it being a functional concept and making things more testable and let it being clearly separate things makes working in code a better experience.

As I am working in a system that is NOT a pleasure.

45:31 – Chuck: It’s called legacy code...

45:38 – What is the code year? What constitutes a legacy application?

45:55 – Panel: 7 times – good rule.

46:10 – Aimee: I am not trolling. Serious conversation I was having with them this year.

46:27 – Just like cars.

46:34 – Chuck chimes in with his rule of thumb.

46:244 – Panel and Chuck go back-and-forth with this topic.

47:14 – Dilbert cartoons – check it out.

47:55 – GREAT QUOTE about life lessons.

48:09 – Chuck: I wish I knew then what I know now.

Data binding. Flux and Redux. Lots of this came out of stuff around both data stores and shadow domes. How do you tease this out with the stuff that came out around the same time?

48:51 – Ethan answers question.

51:17 – Panel chimes in.

52:01 – Picks!

Links:

• JavaScript
• jQuery
• React
• Elixir
• Elm
• Vue
• Automerge - GITHUB
• Functional – Light JavaScript
• Lego’s Massive Cloud City Star Wars
• Lego Shop
• The Traveler’s Gift – Book
• Jocks Rule, Nerds Drool by Jennifer Wright
• 2ality – JavaScript and more
• Cooper Press
• Book – Ethan Brown
• O’Reilly Community – Ethan Brown’s Bio
• Ethan Brown’s Twitter

Sponsors:

• Kendo UI
• Sentry
• Digital Ocean
• Cache Fly
•  

Picks:

Aimee

• Pettier

Joe

• Lego - Star Wars Betrayal at Cloud City
• Functional-Light JavaScript

Charles

• The Traveler’s Gift
• The Shack
• The Expanse

Ethan

• Jocks Rule, Nerd Drool
• JavaScipt Blog by Dr. Axel Rauschmayer
• Cooper Press

Panel:

• Aimee Knight
• Charles Max Wood
• Joe Eames
• AJ O’Neil
• Chris Ferdinandi 

Special Guests: Charles Lowell (New Mexico) & Taras Mankovski (Toronto)

In this episode, the panel talks with two special guests Charles and Taras. Charles Lowell is a principle engineer at Frontside, and he loves to code. Taras works with Charles and joined Frontside, because of Charles’ love for coding. There are great personalities at Frontside, which are quite diverse. Check out this episode to hear about microstates, microstates with react, Redux, and much more!

Show Topics:

1:20 – Chuck: Let’s talk about microstates – what is that?

1:32 – Guest: My mind is focused on the how and not the what. I will zoom my mind out and let’s talk about the purposes of microstates. It means a few things. 1.) It’s going to work no matter what framework you are using. 2.) You shouldn’t have to be constantly reinventing the wheel. React Roundup – I talked about it there at this conference. 

Finally, it really needs to feel JavaScript. We didn’t want you to feel like you weren’t using JavaScript. It uses computer properties off of those models. It doesn’t feel like there is anything special that you are doing. There are just a few simple rules. You can’t mutate the state in place. If you work with JavaScript you can use it very easily. Is that a high-level view?

7:13 – Panel: There are a lot of pieces. If I spoke on a few specific things I would say that it enables programming with state machines.

7:42 – Panel: We wanted it to fell like JavaScript – that’s what I heard.

7:49 – Aimee: I heard that, too.

7:59 – Guest.

8:15 – Aimee: Redux feels like JavaScript to me.

8:25 – Guest: It’s actually – a tool – that it feels natural so it’s not contrived. It’s all JavaScript.

8:49 – Panel.

9:28 – Guest: Idiomatic Ember for example. Idiomatic in the sense that it gives you object for you to work with, which are simple objects.

10:12 – Guest: You have your reducers and your...we could do those things but ultimately it’s powerful – and not action names – we use method names; the name of the method.

11:20 – Panel: I was digging through docs, and it feels like NORMAL JavaScript. It doesn’t seem like it’s tied to a certain framework or library platform?

11:45 – Guest: Yes, we felt a lot of time designing the interfaces the API and the implementation. We wanted it to feel natural but a tool that people reach for.

(Guest continues to talk about WHY they created microstates.)

Guest: We wanted to scale very well what you need when your needs to change.

13:39 – Chuck: I have a lot of friends who get into React and then they put in Redux then they realize they have to do a lot of work – and that makes sense to do less is more.

14:17 – Guest: To define these microstates and build them up incrementally...building smaller microstates out of larger ones.

Guest continued: Will we be able to people can distribute React components a sweet array of components ready for me to use – would I be able to do the same for a small piece of state? We call them state machines, but ultimately we have some state that is driving it. Would we be able to distribute and share?

16:15 – Panel: I understand that this is tiny – but why wouldn’t I just use the native features in specific the immutability component to it?

16:42 – Guest: I’m glad you asked that question. We wanted to answer the question...

Guest: With microstates you can have strict control and it gives you the benefit of doing sophisticated things very easily.

18:33 – Guest: You mentioned immutability that’s good that you did. It’s important to capture – and capturing the naturalness of JavaScript. It’s easy to build complex structures – and there is an appeal to that. We are building these graphs and these building up these trees. You brought up immutability – why through it away b/c it’s the essence of being a developer. If you have 3-4-5 levels of nesting you have to de-structure – get to the piece of data – change it – and in your state transition 80% of your code is navigating to the change and only 20% to actually make the change. You don’t have to make that tradeoff.

21:25 – Aimee: The one thing I like about the immutability b/c of the way you test it.

21:45 – Guest: There a few things you can test. 

23:01 – Aimee: You did a good job of explaining it.

23:15 – Guest: It makes the things usually hard  easy! With immutability you can loose control, and if that happens you can get so confused. You don’t have a way to have a way to navigate to clarity. That’s what this does is make it less confusing. It gives you order and structure. It gives you a very clear path to do things you need to do. If there is a property on your object, and if there is a way to change it...

25:29 – Guest: The only constant is change no matter what framework you are working on.

24:46 – Chuck: We are talking about the benefits and philosophy. What if I have an app – and I realize I need state management – how do I put microstates into my app? It’s using Angular or React – how do I get my data into microstates?

26:35 – Guest: I can tell you what the integration looks like for any framework. You take a type and you passed that type and some value to the create function so what you get is a microstate.

(The Guest continues diving into his answer.)

28:18 – Guest: That story is very similar to Redux, basically an event emitter. The state changes on the store.

Maybe this is a good time to talk about the stability benefits and the lazy benefits because microstates is both of those things.

Stability – if I invoke a transition and the result is unchanged – same microstate – it doesn’t emit an event. It recognizes it internally. It will recognize that it’s the same item. Using that in Ember or Redux you’d have to be doing thousands of actions and doing all that computation, but stability at that level.

Also, stability in the sense of a tree. If I change one object then that changes it won’t change an element that it doesn’t need to change.

31:33 – Advertisement: Sentry.io

32:29 – Guest: I want to go back to your question, Chuck. Did we answer it?

32:40 – Chuck: Kind of.

32:50 – Guest.

32:59 – Guest: In Angular for example you can essentially turn a microstate...

33:51 – Guest: You could implement a connect, too. Because the primitive is small – there is no limit.

34:18 – Chuck summarizes their answers into his own words.

34:42 – Guest: If you were using a vanilla React component – this dot – I will bind this. You bind all of these features and then you pass them into your template. You can take it as a property...those are those handlers. They will perform the transition, update and what needs to be updated will happen.

35:55 – Chuck: Data and transitions are 2 separate things but you melded them together to feel like 1 thing. This way it keeps clean and fast.

36:16 – Guest: Every framework helps you in each way.

Microstates let’s you do a few things: the quality of your data all in one place and you can share.

38:12 – Guest: He made and integrated Microstates with Redux tools.

38:28 – Guest talks about paths, microstates to trees.

39:22 – Chuck.

39:25 – Panel: When I think about state machines I have been half listening / half going through the docs. When I think of state machines I think about discreet operations like a literal machine. Like a robot of many steps it can step through. We have been talking about frontend frameworks like React - is this applicable to the more traditional systems like mechanical control or is it geared towards Vue layered applications?

40:23 – Guest: Absolutely. We have BIG TEST and it has a Vue component.

41:15 – Guest: when you create a microstate from a type you are creating an object that you can work with.

42:11 – Guest: Joe, I know you have experience with Angular I would love to get your insight.

42:33 – Joe: I feel like I have less experience with RX.js. A lot of what we are talking about and I am a traditionalist, and I would like you to introduce you guys to this topic. From my perspective, where would someone start if they haven’t been doing Flux pattern and I hear this podcast. I think this is a great solution – where do I get started? The official documents? Or is it the right solution to that person?

43:50 – Guest: Draw out the state machine that you want to represent in your Vue. These are the states that this can be in and this is the data that is required to get from one thing to the other. It’s a rope process. The arrow corresponds to the method, and...

44:49 – Panel: It reminds me back in the day of rational rows.

44:56 – Guest: My first job we were using rational rows.

45:22 – Panelist: Think through the state transitions – interesting that you are saying that. What about that I am in the middle – do you stop and think through it or no?

46:06 – Guest: I think it’s a Trojan horse in some ways. I think what’s interesting you start to realize how you implement your state transitions.

48:00 – (Guest continues.)

48:45 – Panel: That’s interesting. Do you have that in the docs to that process of stopping and thinking through your state transitions and putting into the microstate?

49:05 – Guest: I talked about this back in 2016. I outlined that process. When this project was in the Ember community.

49:16 – Guest: The next step for us is to make this information accessible. We’ve been shedding a few topics and saying this is how to use microstates in your project. We need to write up those guides to help them benefit in their applications.

50:00 – Chuck: What’s the future look like?

50:03 – Guest: We are working on performance profiling.

Essentially you can hook up microstates to a fire hose.

The next thing is settling on a pattern for modeling side effects inside microstates. Microstates are STATE and it’s immutable.

52:12 – Guest: Getting documentation. We have good README but we need traditional docs, too.

52:20 – Chuck: Anything else?

52:28 – Guest: If you need help email us and gives us a shot-out.

53:03 – Chuck: Let’s do some picks!

53:05 – Advertisement for Charles Max Wood’s course!

Links:

• Kendo UI
• Frontside
• Redux
• Microstates
• Microstates with React
• Taras Mankovski’s Twitter
• Taras Mankovski’s GitHub
• Taras Mankovski’s LinkedIn
• Taras Mankovski’s Frontside Bio
• Charles Lowell’s Twitter
• Charles Lowell’s GitHub
• Charles Lowell’s Frontside Bio
• Schedule Once
• Ruby on Rails
• Angular
• Get A Coder Job
• YouTube Talks
• Email: cowboyd@frontside.io
• Working with State Machines
• Twitch TV
• BigTest
• Close Brace
• REEF
• The Developer Experience
• YouTube Video

Sponsors:

• Kendo UI
• Sentry.io – 2 months free – DEVCHAT/code
• Get A Coder Job

Picks:

Aimee

• ShopTalk Episode 327
• Professional JavaScript for Web Developers
• Technical Debt
• Stripe

Taras

• Twitch Channel
• Big Test
• Frontside

Charles Lowell

• Chalkboards
• Sargent Art Chalk

Chris

• Close Brace
• LaCroix Water
• Chris’s Git Hub

Joe

• The Developer Experience Bait and Switch
• Good Bye Redux
• Recording Dungeon and Dragons

AJ

• UtahJS Conf
• Start with Why
• The Rust Book
• VanillaJS w/ Chris
• Zero to One

Charles

• Podwrench.com -  beta
• getacoderjob.com

Panel:

• Aimee Knight
• AJ O’Neal
• Joe Eames
• Charles Max Wood
• Chris Ferdinandi

Special Guest: Julian Fahrer

In this episode, the panel talks with Julian Fahrer who is an online educator and software engineer in San Francisco, California (USA). The panel and the guest talk about containers, tooling, Docker, Kubernetes, and more. Check out today’s episode!

Show Topics:

0:00 – Advertisement: KENDO UI

1:00 – Chuck: We have today Julian. Julian, please tell us why you are famous?

1:10 – Julian (Guest): I am a software engineer in San Francisco.

1:35 – Chuck: We had you on Elixir Mix before – so here you are! Give us a brief introduction – tell us about the

1:56 – Julian: About 11 hours. You can get it done in about 1 week. It’s a lot to learn. It’s a new paradigm, and I think that’s why people like it.

2:22 – Aimee: How did you dive into Docker? I feel that is like backend space?

2:35 – Julian: I am a full stack engineer and I have been in backend, too.

3:10 – Aimee: I know that someone has been in-charge of our Dev Ops process until the first job I’ve had. When there is a problem in the deployment, I want to unblock myself and not wait for someone else. I think it’s a valuable topic. Why Docker over the other options?

3:58 – Julian: Let’s talk about what Docker is first?

4:12 – Chuck.

4:23 – Julian: Containers are a technology for us to run applications in isolation from each other.

Julian talks in-detail about what contains are, what they do, he gives examples, and more. Check it out here!

5:27 – Chuck: Makes sense to me. I think it’s interesting that you are talking about the dependencies. Because of the way the Docker works it’s consistent across all of your applications.

5:59 – Julian. Yes, exactly.

Julian talks about containers some more!

6:56 – Chuck asks a question about the container, Docker, and others.

7:03 – Guest: You don’t have to worry about your company’s running operating system, and what you want to use – basically everything runs in the container...

7:30 – Chuck: This short-circuits a lot of it.

7:46 – Guest.

8:00 – Chuck: People will use Docker if your employer mandates it. Is there a learning curve and how do you adapt it within the person’s company?

8:25 – Guest.

8:52 – Aimee: We are using it, too.

8:57 – Guest: Awesome!

9:03 – Aimee: The only downfall is that if you have people who are NOT familiar with it – then it’s a black box for us. We can’t troubleshoot it ourselves. I want to be able to unblock from our end w/o having to go to someone else. That’s my only issue I’ve been having.

10:03 – Guest: I want to see that tooling to be honest.

10:12 – Aimee: Can you talk about how Civil and Docker work together?

10:19 – Guest: Yes!

Julian answers the question.

10:56 – Chuck: How much work it is to get a Docker file to get up and running? How much work would it take?

11:18 – Guest: For the development side in about an hour or two – this is if you understand it already. Putting it into production that’s a different story b/c there is a million different ways to do it. It’s hard to put a time on that.

12:24 – Chuck: Let’s assume they have the basic knowledge (they get how server setup takes place) is this something you could figure out in a day or so?

12:47 – Guest: If you have touched Docker then you can do it in a day; if never then not really.

13:02 – Guest: There might be some stones you will fall over.

13:39 – Panel: The part of the learning curve would be...

13:52 – Guest: The idea behind the container is that the container should be disposable. You could throw it away and then start a new one and it’s fresh and clean.

Guest continues with his answer.

15:20 – Chuck: I have seen people do this with their database engine. If you need to upgrade your database then they grab their container...

15:55 – Guest: You don’t have to worry about setting it up - its provided in the container and...

16:09 – Chuck asks a question.

16:17 – Guest: For production, I would go with a hosted database like RJS, Azure, or other options.

Guest continues.

17:13 – Chuck.

17:20 – Guest: If it dies then you need to...

17:30 – Chuck: We talked about an idea of these containers being something you can hand around in your development team.

Chuck asks a question.

17:50 – Guest answers the question. He talks about tooling, containers, web frontend, and more.

18:48 – Guest asks Aimee a question: Are you using Compost?

18:50 – Aimee: I don’t know b/c that is a black box for us. I don’t know much about our Docker setup.

19:00 – Guest to Aimee: Can I ask you some questions?

19:14 – Guest is giving Aimee some hypothetical situations and asks what their process is like.

19:32 – Aimee answers the question.

20:11 – Guest: You have customizing tooling to be able to do x, y, and z.

20:25 – Aimee: They have hit a wall, but it’s frustrating. Our frontend and our backend are different. We are getting 500’s and it’s a black box for us. It’s the way that ops have it setup. I hate having to go to them for them to unblock us.

21:07 – Chuck: I have been hearing about Kubernetes. When will you start to see that it pays off to use it?

21:20 – Guest answers the question.

22:17 – If I have a simple app on a few different machines and front end and job servers I may not need Kubernetes. But if I have a lot of things that it depends on then I will need it?

22:35 – Guest: Yes.

22:40 – Chuck: What are the steps to using it?

22:45 – Guest: Step #1 you install it.

The guest goes through the different steps to use Docker.

25:23 – Aimee: It makes sense that your UI and your database don’t live in the same container, but what about your API and your database should that be separate?

25:40 – Guest: Yes they should be separate.

26:09 – Chuck: What has your experience been with Docker – AJ or Chris?

26:17 – Panel: I have used a little bit at work and so far it’s been a black box for me. I like the IDEA of it, but I probably need to take Julian’s course to learn more about it! (Aimee agrees!)

One thing I would love (from your perspective, Julian) – if I wanted to get started with this (and say I have not worked with containers before) where would I start?

28:22 – Advertisement – Sentry.io

29:20 – Guest: Good question. You don’t have to be an expert (to use Docker), but you have to be comfortable with the command line, though.

30:17 – Panel: Is there a dummy practice within your course?

30:27 – Julian: We run our own web server and...

30:44 – Panel: I need to check out your course!

31:04 – Guest: It is some time investment, but it’s saved me so much time already so it makes it really worth it.

31:38 – Panel: You are a version behind on Ruby.

31:46 – Guest: ...I just want to make code and not worry about that.

32:04 – Chuck: Updating your server – you would update Ruby and reinstall your gems and hope that they were all up-to-date. Now you don’t have to do it that way anymore.

32:37 – Guest: You know it will behave the same way.

32:48 – Guest: I have some experience with Docker. I understand its value. I guess I will share my frustrations. Not in Docker itself, but the fact that there is a need for Docker...

35:06 – Chuck.

35:12 – Panel: We need someone to come up with...

35:40 – Panel: It’s not standard JavaScript.

35:51 – Chuck: One question: How do you setup multiple stages of Docker?

36:12 – Guest: The recommended way is to have the same Docker file used in the development sate and through to production. So that way it’s the same image.

37:00 – Panel: ...you must do your entire configuration via the environmental variables.

37:29 – Chuck asks a question.

37:36 – Panel: If you are using Heroku or Circle CI...there is a page...

38:11 – Guest and Chuck go back-and-forth.

39:17 – Chuck: Gottcha.

39:18 – Guest.

39:52 – Chuck: I have seen systems that have hyberized things like using Chef Solo and...

You do your basic setup then use Chef Solo – that doesn’t’ make sense to me. Have you seen people use this setup before?

40:20 – Guest: I guess I wouldn’t do it.

40:30 – Chuck.

40:36 – Guest: Only reason I would do that is that it works across many different platforms. If it makes your setup easier then go for it.

41:14 – Chuck: Docker Hub – I want to mention that. How robust is that? Can you put private images up there?

41:38 – Guest: You can go TOTALLY nuts with it. You could have private and public images. Also, your own version. Under the hood it’s called container registry. Yeah, you can change images, too.

42:22 – Chuck: Should I use container registry or a CI system to build the Docker system and use it somewhere else?

42:35 – Guest.

43:24 – Chuck: Where can people find your Docker course?

43:30 – Guest: LEARN DOCKER ONLINE! We are restructuring the prices. Make sure to check it out.

44:05 – Chuck: Picks! Where can people find you online?

44:14 – Guest: Twitter! eBook – Rails and Docker! Code Tails IO!

Links:

• JavaScript
• jQuery
• React
• Elixir
• Elm
• Vue
• ESLint
• Node.js
• Circle CI
• Twitter – Circle CI
• Heroku
• Surge.sh
• Kubernetes.io
• Berg Design
• Rian Rietveld
• PickleJS
• Soft Cover.io
• Ebook – boilerplate
• EMx 010 Episode with Julian Fahrer
• Learn Docker
• Indie Hacker – Julian Fahrer
• LinkedIn – Julian Fahrer
• GitHub – Julian Fahrer
• Twitter – Julian Fahrer

Sponsors:

• Kendo UI
• Sentry
• Cache Fly
•  

Picks:

AJ

• Zermatt Resort
• Heber Area

Aimee

• Surge.sh

Chris

• BergDesign
• React, WP, and a11y
• gomakethings.com

Joe

• Docker Videos by Dan Wahlin
• Rock Climbing/Indoor Rock Climbing

Charles

• Extreme Ownership - Book
• Playing DND

Julian

• PickleJS
• Postive Intelligence

Panel:

• Aimee Knight
• AJ O’Neal
• Charles Max Wood

Special Guest: Gil Tayar

In this episode, the panel talks with Gil Tayar who is currently residing in Tel Aviv and is a software engineer. He is currently the Senior Architect at Applitools in Israel. The panel and the guest talk about the different types of tests and when/how one is to use a certain test in a particular situation. They also mention Node, React, Selenium, Puppeteer, and much more!

Show Topics:

0:00 – Advertisement: KENDO UI

0:35 – Chuck: Our panel is AJ, Aimee, myself – and our special guest is Gil Tayar. Tell us why you are famous!

1:13 – Gil talks about where he resides and his background. 

2:27 – Chuck: What is the landscape like now with testing and testing tools now?

2:39 – Guest: There is a huge renaissance with the JavaScript community. Testing has moved forward in the frontend and backend. Today we have lots of testing tools.  We can do frontend testing that wasn’t possible 5 years ago. The major change was React.

The guest talks about Node, React, tools, and more!

4:17 – Aimee: I advocate for tests and testing. There is a grey area though...how do you treat that? If you have to get something into production, but it’s not THE thing to get into production, does that fall into product or...what?

5:02 – Guest: We decided to test everything in the beginning. We actually cam through and did that and since then I don’t think I can use the right code without testing. There are a lot of different situations, though, to consider.

The guest gives hypothetical situations that people could face.

6:27 – Aimee.

6:32 – Guest: The horror to changing code without tests, I don’t know, I haven’t done that for a while. You write with fear in your heart. Your design is driven by fear, and not what you think is right. In the beginning don’t write those tests, but...

7:22 – Aimee: I totally agree and I could go on and on and on.

7:42 – Panel: I want to do tests when I know they will create value. I don’t want to do it b/c it’s a mundane thing. Secondly, I find that some times I am in a situation where I cannot write the test b/c I would have to know the business logic is correct. I am in this discovery mode of what is the business logic? I am not just building your app.

I guess I just need advice in this area, I guess.

8:55 – Guest gives advice to panelist’s question. He mentions how there are two schools of thought.

10:20 – Guest: Don’t mock too much.

10:54 – Panel: Are unit tests the easiest? I just reach for unit testing b/c it helps me code faster. But 90% of my code is NOT that.

11:18 – Guest: Exactly! Most of our test is glue – gluing together a bunch of different stuff! Those are best tested as a medium-sized integration suite.

12:39 – Panel: That seems like a lot of work, though! I loathe the database stuff b/c they don’t map cleanly. I hate this database stuff.

13:06 – Guest: I agree, but don’t knock the database, but knock the level above the database.

13:49 – Guest: Yes, it takes time! Building the script and the testing tools, but when you have it then adding to it is zero time. Once you are in the air it’s smooth sailing.

14:17 – Panel: I guess I can see that. I like to do the dumb-way the first time. I am not clear on the transition.

14:47 – Guest: Write the code, and then write the tests.

The guest gives a hypothetical situation on how/when to test in a certain situation.

16:25 – Panel: Can you talk about that more, please?

16:50 – Guest: Don’t have the same unit – do browser and business logic stuff separated. The real business logic stuff needs to be above that level. First principle is separation of concerns.

18:04 – Panel talks about dependency interjection and asks a question.

18:27 – Guest: What I am talking about very, very light inter-dependency interjection.

19:19 – Panel: You have a main function and you are doing requires in the main function. You are passing the pieces of that into the components that need it.

19:44 – Guest: I only do it when it’s necessary; it’s not a religion for me. I do it only for those layers that I know will need to be mocked; like database layers, etc.

20:09 – Panel.

20:19 – Guest: It’s taken me 80 years to figure out, but I have made plenty of mistakes a long the way. A test should run for 2-5 minutes max for package.

20:53 – Panel: What if you have a really messy legacy system? How do you recommend going into that? Do you write tests for things that you think needs to get tested?

21:39 – Guest answers the question and mentions Selenium!

24:27 – Panel: I like that approach.

24:35 – Chuck: When you say integration test what do you mean?

24:44 – Guest: Integration tests aren’t usually talked about. For most people it’s tests that test the database level against the database. For me, the integration tests are taking a set of classes as they are in the application and testing them together w/o the...so they can run in millisecond time.

26:54 – Advertisement – Sentry.io

27:52 – Chuck: How much do the tools matter?

28:01 – Guest: The revolutions matter. Whether you use Jasmine or Mocha or whatever I don’t think it matters. The tests matter not the tools.

28:39 – Aimee: Yes and no. I think some tools are outdated.

28:50 – Guest: I got a lot of flack about my blog where I talk about Cypress versus Selenium. I will never use Jasmine. In the end it’s the

29:29 – Aimee: I am curious would you be willing to expand on what the Selenium folks were saying about Puppeteer and others may not provide?

29:54 – Guest: Cypress was built for frontend developers. They don’t care about cross browser, and they tested in Chrome. Most browsers are typically the same. Selenium was built with the QA mindset – end to end tests that we need to do cross browser.

The guest continues with this topic.

30:54 – Aimee mentions Cypress.

31:08 – Guest: My guessing is that their priority is not there. I kind of agree with them.

31:21 – Aimee: I think they are focusing on mobile more.

31:24 – Guest: I think cross browser testing is less of an issue now. There is one area that is important it’s the visual area! It’s important to test visually across these different browsers.

32:32 – Guest: Selenium is a Swiss knife – it can do everything.

33:32 – Chuck: I am thinking about different topics to talk about. I haven’t used Puppeteer. What’s that about?

33:49 – Guest: Puppeteer is much more like Selenium. The reason why it’s great is b/c Puppeteer will always be Google Chrome.

35:42 – Chuck: When should you be running your tests? I like to use some unit tests when I am doing my development but how do you break that down?

36:06 – Guest.

38:30 – Chuck: You run tests against production?

38:45 – Guest: Don’t run tests against production...let me clarify!

39:14 – Chuck.

39:21 – Guest: When I am talking about integration testing in the backend...

40:37 – Chuck asks a question.

40:47 – Guest: I am constantly running between frontend and backend.

I didn’t know how to run tests for frontend. I had to invent a new thing and I “invented” the package JS DONG. It’s an implementation of Dong in Node. I found out that I wasn’t the only one and that there were others out there, too.

43:14 – Chuck: Nice! You talked in the prep docs that you urged a new frontend developer to not run the app in the browser for 2 months?

43:25 – Guest: Yeah, I found out that she was running the application...she said she knew how to write tests. I wanted her to see it my way and it probably was a radical train-of-thought, and that was this...

44:40 – Guest: Frontend is so visual.

45:12 – Chuck: What are you working on now?

45:16 – Guest: I am working with Applitools and I was impressed with what they were doing.

The guest goes into further detail.

46:08 – Guest: Those screenshots are never the same.

48:36 – Panel: It’s...comparing the output to the static site to the...

48:50 – Guest: Yes, that static site – if you have 30 pages in your app – most of those are the same. We have this trick where we don’t upload it again and again. Uploading the whole static site is usually very quick. The second thing is we don’t wait for the results. We don’t wait for the whole rendering and we continue with the tests.

50:28 – Guest: I am working mostly (right now) in backend.

50:40 – Chuck: Anything else? Picks!

50:57 – Advertisement: Get A Coder Job!

END – Advertisement: CacheFly!

Links:

• JavaScript
• React
• Elixir
• Node.js
• Puppeteer
• Cypress
• SeleniumHQ
• Article – Ideas.Ted.Com
• Book: Never Split the Difference
• Applitools
• Guest’s Blog Article about Cypress vs. Selenium
• Gil’s Twitter
• Gil’s Medium
• Gil’s LinkedIn

Sponsors:

• Kendo UI
• Sentry
• CacheFly

Picks:

Aimee

• How Showing Vulnerability Helps Build a Stronger Team

AJ

• Never Split the Difference
• Project - TeleBit

Charles

• Monster Hunter International
• Metabase

Gil

• Cat Zero
• The Origin of Consciousness in the Breakdown of the Bicameral Mind

Sponsors

• Netlify
• Sentry use the code "devchat" for $100 credit
• Clubhouse

Panel:

• Charles Max Wood
• AJ O’Neal
• Aimee Knight
• Aaron Frost
• Chris Ferdinandi
• Joe Eames
• Tim Caswell

Notes:

This episode of JavaScript Jabber has the panelists reminiscing on the past. First, they discuss the projects they’re working on. Tim has joined MagicLeap doing JavaScript and C++. Aaron Frost is one of the founders of HeroDevs. AJ works at Big Squid, a company that takes spreadsheets and turns them into business actions, and is expecting a daughter. Aimee has been exploring developer advocacy, but wants to focus primarily on engineering. She is currently working at MPM. Joe has taken over the CEO position for thinkster.io, a company for learning web development online. Chris switched from being a general web developer specializing in JavaScript and has started blogging daily rather than once a week, and has seen an increase in sales of his vanilla JavaScript educational products. Charles discusses his long term goal for Devchat.tv. He wants to help people feel free in programming, and help people find opportunities though the Devchat.tv through empowering content.

Next, the panelists discuss their favorite episodes. Some of the most highly recommended episodes are

JSJ 124: The Origin of Javascript with Brendan Eich (1:44:07)

JSJ 161: Rust with David Herman (1:05:05)

JSJ 336: “The Origin of ESLint with Nicholas Zakas” (1:08:01)

JSJ 338: It’s Supposed To Hurt, Get Outside of Your Comfort Zone to Master Your Craft with Christopher Buecheler (43:36)

JSJ 218: Ember.js with Yehuda Katz (42:47)

Last, the panelists discuss what they do to unwind. Activities include working out, reading, playing Zelda and Mario Kart, studying other sciences like physics, painting miniatures, and Dungeons and Dragons.

Picks:

Charles Max Wood

• Villainous Board Game

Joe Eames

• Azul Stained Glass Board Game

AJ O’Neal

• https://www.digikey.com/
• Magnetic Hourglass: Amazon | Hobby Lobby $6 

Aimee Knight

• https://www.nytimes.com/2018/12/24/well/mind/work-schedule-hours-sleep-productivity-chronotype-night-owls.html

Aaron Frost

• Matrix PowerWatch
• https://twitter.com/ChloeCondon

Chris Ferdinandi

• https://learnvanillajs.com/

Tim Caswell

• https://www.magicleap.com/
• https://textonascreen.rocks/
• https://history.lds.org/saints

Sponsors

• Sentry- use the code “devchat” for $100 credit
• Netlify
• Clubhouse
• CacheFly

Episode Summary  

In this episode of JavaScript Jabber, the panelists talk with Tommy Hodgins who specializes in responsive web design. He starts with explaining to listeners what it means by a responsive web layout and goes on to discuss the techniques in using JavaScript in CSS in depth.

He elaborates on dynamic styling of components, event-driven stylesheet templating, performance and timing characteristics of these techniques and describes different kinds of observers – interception, resize and mutation, and their support for various browsers. He also talks about how to go about enabling certain features by extending CSS, comparison to tools such as the CSS preprocessor and Media Queries, pros and cons of having this approach while citing relevant examples, exciting new features coming up in CSS, ways of testing the methods, caffeinated stylesheets, along with Qaffeine and Deqaf tools.

Links

• JS in CSS – Event driven virtual stylesheet manager
• Qaffiene
• Deqaf
• Tommy’s Twitter
• Fizzbuzz

Picks

Joe

• The Captain Is Dead

Aimee

• Developer on Call
• Tip – Try to follow a low-sugar diet

Chris

• Tommy’s snippets on Twitter – JS in CSS
• All things frontend blog
• Gulp project

Charles

• Coaching by Charles in exchange of writing Show Notes or Tags

Tommy

• JS in CSS

Sponsors

• Triplebyte offers a $1000 signing bonus
• Sentry use the code “devchat” for $100 credit
• Linode offers $20 credit
• CacheFly

Panel

• Joe Eames

• AJ O’Neal

Episode Summary

In this episode of JavaScript Jabber, Joe Eames and AJ O’Neal talk about what TypeScript is, and their background and experiences with it. They discuss the different kinds of typed languages such as dynamic vs static, strong vs weak, implicit vs explicit casting and the reasons for selecting one type over the other. AJ shares his opinion on not preferring TypeScript in general, while Joe offers a counter perspective on liking it, and both give a number of reasons to support each argument. They talk about some final good and bad points about TypeScript and move on to picks.

Links

• TypeScript
• CoffeeScript

Follow JavaScript Jabber on Devchat.tv, Facebook and Twitter.

Picks

Joe Eames:

• Cypress
• What if your dev environment was a PWA? ???? | Eric Simons
• Angular 8 Intergalactic
• Star Wars Tantive IV Lego set

AJ O’Neal:

• Measure What Matters
• @root on npm
• @bluecrypt on npm

Sponsors

• Datadog  

• Sentry use code “devchat” for 2 months free

Panel

• Aimee Knight

• AJ O’Neal

• Charles Max Wood

With Special Guest: Rene Rubalcava

Episode Summary

Rene is a software developer for ESRI and works in spatial and mapping software. ESRI has been around since 1969 and has seen their work explode since they shifted to providing address and location services. Rene talks about how he thinks about location and mapping when building software around it and things that he has to approach in unique ways. The panel discusses some of their past experiences with location software. Some of the most difficult aspects of this software is changing time zones for data and actually mapping the Earth, since it is not flat nor a perfect sphere. Rene talks about the different models used for mapping the Earth.

Most mapping systems use the same algorithm as Google maps, so Rene talks about some of the specific features of ArcGIS, including the ability to finding a point within a polygon. Rene talks about what routing is, its importance, and how it is being optimized with ArcGIS, such as being able to add private streets into a regular street network.

The panel discusses how the prevalence of smartphones has changed mapping and GPS and some of their concerns with privacy and location mapping. One thing ESRI is very careful about is not storing private information. Rene talks about the kinds of things he has seen people doing with the mapping and location data provided by ArcGIS, including a Smart Mapping feature for developers, mapping planets, indoor routing, and 3D models. 

Links

• Webricate 

• Esri

• ArcGIS

Follow DevChat on Facebook and Twitter

Picks

Rene Rubalcava:

• Old Man’s War series

• Always Be My Maybe

• Rene’s website

AJ O’Neal:

• INTL

• Colorful

• Time zones in Postgress

• Time zones in JavaScript

Aimee Knight:

• Advice to Less Experienced Developers

Charles Max Wood:

• Heber Half Marathon

• Netlify CMS

• Villainous

• Firefox

Sponsors

• RxJS Live

Panel

• Charles Max Wood

• Christopher Beucheler

• Aimee Knight

Episode Summary

Today’s episode is an exploration of the question “What is JavaScript?”. Each of the panelists describes what they think JavaScript is, giving a definition for both technical and non-technical people. They talk about how the different layers of JavaScript tie into their definitions. They agree that it’s incorrect to call JavaScript one of the ‘easy’ programming languages and some of the challenges unique to JavaScript, such as the necessity of backwards compatibility and that it is used in tandem with CSS and HTML, which require a different thinking method. They discuss the disdain that some developers from other languages hold for JavaScript and where it stems from. They discuss methods to level up from beginner to mid level JavaScript programmer, which can be tricky because it is a rapidly evolving language. They revisit the original question, “What is Java Script?”, and talk about how their definition of JavaScript has changed after this discussion. They finish by talking about the story they want to tell with JavaScript, why they chose JavaScript, and what is it they are trying to do, create, become through using the language. They invite listeners to share their answers in the comments. 

Links

• JQuery

• JavaScript

• JSON

• React.js

Follow DevChat on Facebook and Twitter

Picks

Charles Max Wood:

• The Dungeoncast 

Aimee Knight:

• This Patch of Sky

Christopher Beucheler:

• Silversun Pickups album Widow’s Weeds

• Andrew Huang YouTube channel