The Coding Couple

Pair programming is a lifetime commitment.

DevSpace 2019 Recap

by

DevSpace is a two day, annual technical conference back for its 5th year in Huntsville, AL. Sessions covered a wide range of topics such as functional programming, game development, machine learning, AWS, testing and more.

DevSpace 2019 Technology Conference – Huntsville, AL

This was my second time attending the conference (first time was back in 2016). This blog post will serve as a dump for all the notes I took during the conference.

Building an open source artificial pancreas

The opening keynote was by Sarah Withee. She went over a brief biology lesson on diabetes before discussing her DIY artificial pancreas with OpenAPS.

It was a really interesting session. Prior to it, I didn’t have a good understanding of how diabetes affected the body and the work diabetics had to do to keep their blood sugar levels within a safe range.

You can find her slides on the talk over at her website: geekgirlsarah.com, Building an Open Source Artificial Pancreas.

Understanding Alexa

In the Understanding Alexa session, Jeff Blankenburg (a developer on the Amazon Alexa team) covered the basics on how Alexa works and design considerations for building Alexa skills.

This was a great session and very relevant to me as I’ve been brewing on an idea for an Alexa skill for some time now. I left the session feeling pumped to start implementing my idea.

My notes from the session:

  • VUI = voice user interface
  • Make Alexa dialog sound more like a natural conversation instead of a robot
  • Alexa turns audio to a .wav file, and sends it to a server
  • Alexa has 7 microphones
  • Utterances => Intents
  • ASR = Automatic Speech Recognition
    • 4 miles
    • For Miles
    • Form Isles
    • For my isles
  • Alexa (wake word) open (launch) Little Rock Guide (invocation name) Recommend an attraction (utterance)
    • Alternative launch words: start, begin, resume, ask, tell
    • Invocation name = skill name. Want it to be easy and memorable
    • Within utterances there can be variables (slots)
  • AttractionIntent (intent) { distance: "4" } (slot value)
  • Developers of skills do not get access to the audio files nor do they receive all of the spoken words.
  • ask-sdk for Node.JS
  • Design consideration: Have the first time experience using a skill differ from n+1 times
  • Text to Speech
    • SSML: a markup language to make speech more interesting
      • pauses: well okay versus well <break time = "3s" /> okay
      • speech cons: Speak with enthusiasm.
        <say-as interpret-as="interjection">
        all righty
        </say-as>
      • SSML Prosody: control speed, pitch and volume of speech
    • Streaming audio files
  • You can whisper to Alexa and she’ll whisper back.
  • Audio clip: <audio src="sound.mp3" />
  • AWS Promotional Credits: apply after publishing an Alexa skill. Up to $100 in credits a month
  • Key Design Principles for Alexa Skills
    • Voice first (have to provide a voice only experience)
    • Cognitive Load (Consider ice cream shop example with an overwhelming number of flavors to choose from. Don’t force user to memorize options)
    • Conversational content
    • Speech
  • Build skills with a clear purpose
  • Make your skill discoverable (use intuitive names)
  • Design for natural language conversation
  • User good interactive design (give users outs, accept different version of the same answer)
  • Handle unexpected utterances gracefully
  • Watch your customers using your skills
  • Simulate human speech as much as possible
  • Interact with Alexa dev team Tuesdays at 11 am for live office hours on Twitch
  • slot type {thisthatthey}: reduces duplicates under sample utterances
    • things
    • this
    • that
    • they
    • those
  • Ask Alexa for a random date
  • Samuel L. Jackson voice coming soon
  • AWS has Amazon Polly (voice library useful for creating story games)
  • Resources:
    • GitHub: github.com/alexa
    • Dev Portal: developer.amazon.com
    • Office Hours: alexa.design/officehours
    • Training Course: alexa.design/cakewalk
    • Skills Store: amazon.com/skills

How my company saved Hundreds of hours by using Docker

This was a session by Kyle Galloway talking about how useful Docker was for his workplace.

Dockerfile examples from Kyle’s talk are available on his GitHub Page.

Additional Resources:

Write Cleaner JavaScript Today

The Write Cleaner JavaScript Today by Tyler Jennings was a session on refactoring JavaScript using functional programming techniques.

My notes from the session:

  • Reduce developer cognitive load by writing descriptive and shorter code
  • Refactoring Journey:
    • map
    • ternary operator
    • template syntax
    • arrow functions (not hoisted!!! unlike functions)
      const add = (num1, num2) => num1 + num2;
      const sum = add(1, 2);
      Encourages single responsibility. Write for a single object (handle iteration somewhere else)
    • Destructuring (can also provide default values)
    • Minimize mapping
    • Composition: take a function that goes from a to b and combine it with a function that goes from b to c
    • pipe: doesn’t exist in JavaScript today
    • A few other techniques:
      • shorthand properties
      • spread operator (can merge objects and arrays)
      • object.assign vs spread operator (both are shallow copies)
      • use JSON.parse(JSON.stringify(obj)) for a deep copy
      • object.getOwnPropertyDescriptor

Data Science for folks without (or with) a PH.D!

Data Science for Folks without (or with) a PHD session by Douglas Starnes was a nice introduction to data science and the related tools available.

My notes from the session:

  • What does it take to be a data scientist?
    • Data Science is multidisciplinary
    • Programming
      • Why Python? Clean, simple, easy to learn
      • Cross platform and open source
      • Vibrant and diverse community support
    • Mathematics
    • Business (domain knowledge)
    • Art (color theory, also see Machine Learning for Designers)
  • Tools:
    • Anaconda Distribution
    • NumPy (lowest level library)
    • pandas (data manipulation / analytics, can also read and display CSV data)
    • matplotlib (data visualization)
    • jupyter notebook (an interactive computing environment that runs in the browser. based on IPython)
    • Azure Notebooks and Google Colab are different implementations of jupyter notebook
    • seaborn (more complex visualizations for matplotlib)
    • scikit-learn (canned implementations of Machine Learning algorithms)
    • statsmodels (statistical models)
    • Alternatives to Python:
      • R
      • Julia computing (tuned for performance; kinda like Pythonic R)
    • Tableau, Microsoft Power BI, Google Data Studio, SQL Spark, Excel, OpenPyxl (Python excel manipulation)
  • Pluralsight Courses by session speaker:

The Art of API Design

The Art of API Design session by Francis Solomon covered best practices for designing RESTful APIs.

My notes from the session:

  • Make APIs that are easy to consume (internal APIs still have customers!)
  • Consistency is critical! (consider creating an API design council to compare notes between teams)
  • The principle of least surprise
    1. Result should be obvious, consistent and predictable
    2. Avoid doing unexpected things such as having unimplemented verb that the server would still respond to
  • Help your devs with good documentation
    1. i.e. swagger
    2. Instead of answering what does this pieces do answer what can I do with this and how do I do x?
  • There’s no such thing as just an internal API
  • Monetization of APIs is growing rapidly
  • Increase agility for your organization
  • What does it mean to be RESTful?
  • Expectations of a RESTful API:
    1. An API should be stateless
    2. HTTP verbs represent your actions
      • GET (retrieve one or more resource)
      • POST (create a new resource)
      • PUT (update an existing resource)
      • DELETE (remove an existing resource)
      • PATCH (partial update of an existing resource)
    3. One endpoint should work with one resource
    4. Use appropriate HTTP status codes to represent success or failure
      • 2xx: success (ie. 200 OK, 201 created, 202 accepted – status for a long running task, 204 no content – often used with delete)
      • 3xx: success (“but the princess is in another castle” ie 303 see other)
      • 4xx: (“You made a bad call” ie. 400, 404, 429 – good for monetized API calls)
      • 5xx: (“The server had a problem”)
      • Be very careful with 500.
      • Exposes internals of server implementation and can confuse the user
      • Catch the exception and send a more sensible message
    5. RESTful APIs manage resources not actions
  • RPC style: POST /v1/customer/createCustomer (returns 200 OK)
  • RESTful style: POST /v1/customers (returns 201 Created)
  • RPC style: GET /v1/customer/getCustomerById?id={id} (returns 200 OK)
  • RESTful style: GET /v1/customers/{id} (returns 200 OK or 404 Not Found)
  • Naming considerations
    1. Consider what you are representing. Extra info? Consider moving it to a subresource. (ie GET /v1/customers/{id} => GET /v1/customers/{id}/addresses/{addressId})
  • Ubiquitous language
    1. Use the same terminology throughout (ie order vs contract or customer, user, account)
    2. Look at other companies in your sector for how have APIs with similar purpose. Is there a consensus on how they name a resource? Makes transition from competitors produce easier.
  • Specific rules of naming
    1. Use nouns (ie /v1/customers/{id} not /v1/customer/getCustomersById
    2. Pluralize your nouns (aids in consistency)
    3. If a resource can only exist with in the context of another, nest it (ie /v1/customers/{id}/phoneNumbers
    4. camelCase vs snake_case (pick one and be consistent)
  • Versioning
    1. url path versioning (most common and easiest)
    2. query string versioning
    3. header versioning
    4. media type versioning (messes with the accept, not recommended)
  • When to version APIs?
    1. Adding fields to a resource does not require versioning
    2. Changing and/or removing a field requires versioning
    3. Versioning should be used as sparsely as possible.
    4. Multiple versions mean more support or maintenance.
    5. Stability is important, constantly releasing new versions will annoy your customers
    6. The need to support old versions can restrict how agile your business model can be
    7. Start the expectation of a new version in the future
  • How to version an API?
    • url-based versioning is the simplest
    • relatively trival to create branching logic based on URLs
    • Its nice to explore with a browser
  • Patterns for GET APIs
    1. Retrieving a single resource
      • GET /v1/customers/{id}
      • typically this is the primary identifier of the resource
      • use status code 200 OK
      • don’t find? use status code 404 Not Found
    2. Retrieving multiple resources
      • GET /v1/customers/?name={name}&isActive=true
      • query string segments are filtering options
      • might choose to make certain filter options present by default unless explicitly overridden
    3. Pagination support
      • GET /v1/customers/?page=2&pageSize=20
      • good when UI is calling API
      • bad when a system is calling API
      • response with pagination should be using the Location headers
      • communicate next and last pages within Location header
      • sort order is important in conjunction with pagination
      • GET /v1/customers/?orderBy=lastname,firstname
      • Always use 200 OK as response even if there no records found and send back an empty list because the list does exist
  • Patterns for POST APIs
    1. All fields for a new resource are in body of the request
    2. POST /v1/customers
    3. Not normally idempotent but you can make it so
    4. Use status code 201 Created for success
    5. Also echo newly created resource back in body
    6. Include Location header to tell client how to retrieve resource in the future
    7. Validate everything! If fails send back 400 Bad Request
    8. Optionally use 422 Unprocessable Entity
  • Partial Updates
    1. PATCH /v1/customers/{id}
    2. Partial representation { "id": 1, "isActive": false } vs JSON Patch document [{ "op": "replace", "path": "/isActive", "value": false }]
    3. important op codes: add, remove and replace
  • RESTful APIs should be:
    1. Designed thoughtfully
    2. Named carefully
    3. Implemented consistently
    4. Versioned appropriately and sparingly
  • https://github.com/francissolomon

Additional Resources on API design:

Additional reources

The Thinking Developers Guide to the Brain

  • Practical ways to make a difference
  • Monkey ball illusion
  • Teach somebody how to do something
  • Definition of luck
  • Realize your self work
  • Find something that scares you just enough that it stretches you
  • Always be looking to grow and change your perspective of yourself
  • Purposely look for difference perspectives
  • Challenge yourself on a regular basis
  • Find your devil’s advocate
  • Focus on the rule, handle the exception
  • Embrace cognitive dissonance
  • Don’t need 50%, just 10% (Malcolm Gladwell) momentum will bring a tipping point
  • Luck is recognizing opportunities and taking advantage of them
  • Overload: get every single piece of info about the problem ’til you can
  • Define the problem, then distract yourself and then go to sleep
  • The subconscious brain has been told it needs an answer to the problem
  • We’re wrong more than we’re right
  • Look for someone who will share an alternative perspective
  • Ask a question for more info, not to confirm your bias
  • github.com/gbworld
  • “Focus” by Barbra
  • “Learning How to Think”

Effective Life-Long Learning

  • @jcreekmore, Jonathan Creekmore
  • Reading is how to get ahead
  • The more flexible and adaptable you are the more employable your are
  • “The World is Flat” by Thomas Friedman
  • Think of all the disappearing jobs:
    1. taxi drivers
    2. milk delivery
    3. truck drivers in the future
  • You have to take an active approach to go out there and learn something
  • Learning is ACTIVE, not PASSIVE
  • Reading for increased understanding
    1. Reading for entertainment (Harry Potter)
    2. Reading for understanding (Deeper truths, Stretch yourself, level yourself up)
    3. Reading for information (Facts, media, magazines, not really increasing understanding)
  • 4 Levels of Reading
    1. Elementary (Basic reading techniques)
    2. Inspectional (Mime map of book, overview, where it relates to the world. Is this book worth spending your time on?)
    3. Analytical (Most complete reading with unlimited time)
    4. Syntopical (Going beyond a single book , survey a lot of different books to get an answer)
  • “How to Read a Book”
  • “How to think like Leonardo Da Vinci” – There’s a process to go through to raise yourself to genius level
    1. Curiosity
      • Unrelenting quest for continuous learning
      • Hone your question/asking ability (Ask the right question)
  • Specialization helps you exploit a niche
  • Generalization helps to keep you flexible
  • Broad experience helps you move into new areas by exploiting similarities to things you already know
  • Tech-only study can help get ahead for your job, but what if you want to change
  • Broaden your mind through a study of something different, ie history, science, classic literature
  • Taking Notes
    1. Thinking tends to express itself in words, spoken or written
    2. Can you explain it in your own words? If no, do you really understand it
  • Demostration
    1. A commitment to test knowledge
    2. You gotta DO
  • Share what you have learned
    1. Produce essay, blog post
    2. Discussion group (book club, round table)
    3. Practical demonstrations

Hacking Network APIs

  • Talk by Dan Nagle
  • Wireshark (now has USB capture)
  • Packet Sender (packet sending and receiving)
  • Common uses:
    1. Control devices beyond their original use
    2. Automation
    3. Developing network APIs
    4. Malware analysis
    5. Testing network connectivity / firewalls
    6. Security tests (SSL)
    7. Tech support
  • TCP vs UDP
    1. Guaranteed versus best effort
    2. SSL/TLS is just encrypted TCP
    3. Device control (both)
    4. File download (TCP)
    5. Device polling (UDP)
    6. http/ssh/telnet/ftp/git (TCP)
    7. live streaming video (UDP, this is where UDP shines)
    8. broadcast/multicast (UDP)

[WORK IN PROGRESS]