We discuss developing mobile Android applications with Andy Street, an engineer at Facebook working on React Native

01:12 - MIKMIDI

02:17 - Adding Features or Changing the Way a Library Works in an Open Source Projects

04:49 - Deprecation

07:23 - Deprecation vs Replacing

09:37 - Semantic Versioning

15:14 - What is a breaking change?

17:51 - Choosing Issues and Bugs to Tackle; How long should it take?

24:31 - Maintainer Responsibility

26:33 - Being a Good Contributor; Documentation & Examples

31:01 - Using Badges

32:12 - How Travis CI Integrates with an Open Source Project

35:22 - Hosting for Open Source Projects

36:37 - Generated Documentation

39:07 - Licensing

40:56 - What’s changed in MIKMIDI? (Since Episode #57)

Picks

The Big Star Story (Jaim)

02:06 - Steven Bristol Introduction

02:32 - “Churn”

03:08 - The Genesis of LessChurn

04:04 - How does it work?

06:45 - SaaS Products

09:41 - Steven’s Background

10:58 - The SaaS Path (Advice)

18:36 - Churn University

21:48 - Outbound

24:14 - Pricing

26:43 - Customer Trust

32:44 - The Psychology of Churn

34:54 - Zombie Revenue

36:28 - Keeping Customers Around

Picks

Why Johnny Can't Brand: Rediscovering the Lost Art of the Big Idea by Bill Schley (Philip)

02:28 - Ward Bell (and Co.’s) Documentation Contributions for Angular 2

05:39 - Peter Bacon Darwin (and Co.) & Jade

07:38 - John Papa and the Tour of Heroes Tutorial

09:01 - Geoff Goodman & Plunker

10:07 - GDE (Google Developer Expert) Program/Summit

13:37 - Thomas Burleson & Angular Material

16:07 - The Angular Team <3

17:13 - Rob Wormald: ng2 + Rx + redux Plunker

19:13 - The Go Programming Language

19:51 - Jeff Whelpley and Patrick Stapleton & Angular Universal

22:52 - Minko Gechev

25:56 - FiveFilters.org

26:35 - Aurelia & Other Frameworks + Collaboration and Dialog

Picks

02:10 - Brian Underwood Introduction

02:55 - Neo4j

04:31 - Graph Databases vs Traditional Databases

06:02 - Relations Have Directions

06:58 - Modeling a Domain as a Graph; How it Works

13:25 - Built-in Query Processor

15:04 - Neo4j.rb => ORM; OGM

18:06 - Declarative Schema

21:09 - The Ruby Client vs The Java Client

25:48 - Use Cases

35:53 - Who is using Neo4j?

38:42 - Challenges as an Open Source Maintainer

39:44 - Funding Neo4j

41:00 - Working Abroad

42:16 - Getting Started with Neo4j

Picks

Elle Luna: The Crossroads of Should and Must (Jessica)

Check out JS Remote Conf!

02:22 - Elijah Manor Introduction

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

10:21 - Copy/Paste Code Error

13:11 - Using ES6 to Eliminate Code Smells

15:48 - Refactoring Case Statements

21:29 - Juniors and Code Smells

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)

"Red. Green. Refactor" is a great slogan for Test-Driven Development. It's less great as a guide to actual TDD practice. The slogan provides no guidance for two very important questions in a TDD process: "What do I test next?" and "How do I break my problem into testable pieces".

You may have struggled with TDD on these two issues, leading to giving up, or winding up with "uncanny valley" tests that are hard to maintain but don't provide support for change. Using a puzzle problem, we'll show how to expand on Red Green Refactor, so you can take advantage of the code-quality benefit of TDD.

"Red. Green. Refactor" is a great slogan for Test-Driven Development. It's less great as a guide to actual TDD practice. The slogan provides no guidance for two very important questions in a TDD process: "What do I test next?" and "How do I break my problem into testable pieces".

You may have struggled with TDD on these two issues, leading to giving up, or winding up with "uncanny valley" tests that are hard to maintain but don't provide support for change. Using a puzzle problem, we'll show how to expand on Red Green Refactor, so you can take advantage of the code-quality benefit of TDD.

"Red. Green. Refactor" is a great slogan for Test-Driven Development. It's less great as a guide to actual TDD practice. The slogan provides no guidance for two very important questions in a TDD process: "What do I test next?" and "How do I break my problem into testable pieces".

You may have struggled with TDD on these two issues, leading to giving up, or winding up with "uncanny valley" tests that are hard to maintain but don't provide support for change. Using a puzzle problem, we'll show how to expand on Red Green Refactor, so you can take advantage of the code-quality benefit of TDD.

A discussion about creating animations using various React Native apis.