Title: A brief, opinionated history of the API
Speaker: Joshua Bloch @joshbloch

See the table of contents for more blog posts from the conference.

In 2012,  Josh testified in he Oracle vs Google  lawsuit.  He therefore studied APIs   And this talk came from there

History

• First subroutine libraries – 1948  paper from Princeton. Showed ol yellowed paper with assembly language. However, woul have required manual changes each time.
• Wilkes won Turing award in 60’s for actually creating a reusable subroutine library. EDSAC. World’s first stored program computer. Kept simple to get it done so fast!
• Wilkes and Wheeler wrote boot loader (first 30 words) to make reusable so programmers didn’t have to deal with binary machine code. Instead, programmers use assembly language.
• In first program on first computer ”… realization came over me that a good part of the remainder of my life was going to be  spent in  finding the errors in my own programs” —— Maurice Wilkes. Subroutine library  is a partial fix.
• Wilkes  made his student Wheeler deal with that
• ”The wheeler jump” —— call function by jumping. Requires self  modifying ocde which would be  a security nightmare now.
• 1951 – “The Preparation of programs for digital computers”. Called WWG for last names of authors.  World’s first text on computer programming and remained primary text until higher level languages arose.   Introduced subroutines to the word.
• 1952 –   Wheeler wrote about   Concepts including higher order functions. Whole paper is only  two pages long and  covers so much. Doesn’t cover platform independence because only one machine architecture. Doesn’t cover legacy code because first program
• 1968 – first reference to word API.  Josh submitted to add reference in dictionary
• 2006 – people still don’t know importance of good API design

What is an API

• subroutine definitions/protocols (Josh disagrees with tools being included)
• communicate with  software and hardware
• If it provides operations defined by inputs/outputs and allows reimplementation without compromising user, it is an API. Can ammend definition to make programming language level
• glue that connects digital universe
• ex:   Fortran standard library. 28 math functions
• ex: IBM instructon set [about half audience considers API]
• ex: C standard library
• ex: UNIX system calls – operating system kernels have APIs
• ex: DEC VT100 escape sequences – peripheral control interface. Smart terminals could blink or moe around on screen
• ex: IBM PC BIOS   – control underlying hardware
• ex: MS DOS comand line interace – not exactly API, but serves as one if using scripting language.
• ex: Hayes modem AT command set – used to type manually. Been reimplemented any times since
• ex: Adobe PostScript – language and/or API
• ex: Perl regex – API within a language
• ex:   Server Message Block – wire level protocols. Don’t program with it directly
• ex: Windows API
• ex: Java class libraries – core languages
• ex: REST API for web service

Law

• Always had freedom to reimplement APIs.
• EDSAC was even reimplemented in Japan without any communication
• 2010 – Oracle sued Google over Java APIs in Android. Claimed patent and copyright infringement. Ruled no patent infringement and cannot copyrightable. Oracle appealed and won. Supreme Court declined to hear. Appeals court determined fair use. So right now, APIs are copyrightable and need permission to reimplement. Google currently petitionining to rehear. Many parties supported Google.
• Currently need author’s permission to reimplement API. Might have to pay. Author has monopoly on API. Copyright problem is worse than patents because lasts 95 years.

My take

This was awesome! I’ve seen Josh do Java talks and I liked  this topic as well

1951

Title: Behavioral Economics and Chatbots
Speaker: Jim Clark

See the table of contents for more blog posts from the conference.

Urinal with a fly is an example of behavioral economics. The idea is to give something to aim at.

Psychology

• Nudge theory – alter decision making
• Value-action gaps – how want to be working vs how actually work
• Information deficits  – know right thing when need to know it
• Diffusion of innovation – why do teams succeed vs get stuck

OODA loop

• Observe – unmet goal
• Orient – provide context
• Decision – should action be taken. choose appropriate action
• Action – take appropriate action

Demo – follow the leader

• find out what others are doing/if issues
• chatbot notices when library version changed and if different from others/standard
• chatbot offers to set new version to others that should use later version. testifying it is safe
• then chatbot can nudge users on older version to upgrade
• can tell chatbot to upgrade it for you and chatbot creates the pull request for the update. ex: action: accept/set target/ignore

Demo – Libbis? (he said only two people call it that)

• When change code in one project, the projects that copied it get a pull request to change. For reuse smaller than libraries [seems like a hack to enable copy/paste reuse]
• Recognizes same code fingerprints
• Action: accept/reject pull request

Demo – Value Action Gaps

• Reports vulnerable libraries and whether a fixed version is available
• Artifactory can block more downloads/builds with artifacts
• Action: deal with violation/block download/upgrade
• The command is important. The nudge lowers the barrier to actual acting. Timely suggestions.

Demo – Innovation diffusion

• Shared goals
• When one project gets a new feature/microservice, encourage others to as well.

General

• Always be innovating – need to be able to try things without getting permission from a committee.
• The chatbot committed so much to github that it got recommended to do a code review.
• Make it easy to create new projects. Won’t do it if it is hard. If ceremony isn’t something you want to do, take it away.
• Lower barrier for good ideas spreading.
• Bots are not mobile CLIs. They are agents for collaboration and automate in a social context.

My take

This talk uses live demos in slack. Very cool! The range of benefit to developers is really useful. Seeing real Slack examples and real code was great.  I missed a little bit because I had to make a change to my deck for tomorrow’s presentation. (Java 11 goes feature complete tomorrow and a new feature was added.) I wish I could rate this session higher than “green”.

Title: Designing for the Human
Speaker: Charles Berg (from Google Home)

See the table of contents for more blog posts from the conference.

Over half the audience has smart speakers at home (Echo, Alexa, etc)

Most common uses of smart speakers

• Communication (calls, texts)
• IOT (turn on lights, fans)
• Clock (alarms/timers)
• Music

History

• Encourages checking out of the environment. Even a notification gets you back into your phone
• We focus on features and apps, but not the reason why users is doing something. App first human second mindset is a problem.

Smart speakers

• Unlike smart phones, they are fixed in space. Direct voice to it.
• Place it near where plan to use it.
• That usage leads to context.

Agile

• Ask questions
• Do research before had design
• Storyboards

Calling use case

• Call dentist – should be seemless
• Call Walgreens – which one?
• Hands free calling for friends is frequent

Process

• Understand context.
• In a medium to large company, there is a lot of research already going on.
• Find archived research. Don’t need to do from scratch.
• Interview – start internal to team, then friends/family
• Quickly need to expand interview to be more broad.
• Pitch teammates on ideas based on research
• Identify lead designer. Then identify themes (summary of research), brainstorm and create user journey map.
• Physical user testing. Made two rooms with a mattress instead of just talking about it.

Smart speakers and dialog

• There is a smart speaker style guide.
• Develop variations
• Test with actual people; see variation

My take

This was fun. It was a good mix of smart speakers and user focused design. I would have liked for more of the examples to be about speakers (vs an example about pretend stock quotes). Reading the abstract, I wasn’t sure how much to expect of each type of information. I don’t know if it was reasonable to expect, but I was expecting more on the smart speakers. And then right after I typed this, there was more on the speakers. Good. So maybe it wasn’t the amount of information, but the distribution of it. And the QA definitely went back to speakers.