API Design & Moving from Junior to Senior Developer
- 1. API Design & Junior ➪ Senior Christopher Cotton @_cotton for @NashSoftware 2012 Nov 29, christophercotton.com
- 2. The Past ✤ 20+ years Programming ✤ Been QA Tester, Junior Dev, Senior Dev, Technical Lead, Project Lead, Architect, Senior Member of Technical Staff 3 (What?!), CTO, Founder, Consultant and lots of random other jobs ✤ javax.mail http://www.google.com/#q=javax.mail+cotton
- 3. The Now ✤ iOS, Android, Ruby on Rails ✤ @NashGameDev ✤ @SpacewardHo ✤ http://handstand.io ✤ Teach Kids Programming (YSI) http://www.fssd.org/index.php? option=com_content&task=view&id=110&Itemid=207
- 4. My Version, Not “The Truth” Date
- 6. This does what? User.find_or_create_by_name("Bob")
- 8. API ✤ Contract - documented, agreement, cause/effect ✤ Interface - one service to another ✤ GEM, Library, TCP, HTTP, etc. ✤ Systems Integration
- 10. API Here, API There, Everywhere Date
- 11. Version 2010/12/31 Current Architecture All rights reserved Handstand Scraper ContentDB Packager FileStorage Content Server Blogs/Websites Article List Article Package Market Task Device App Android Market Google Log Analytics Task Ad List Config Ads Builder Amazon Builder Amazon SQS S3 App.Handstand Customer Internal Systems Date
- 12. API - How to Consume Date
- 13. How to use? What would you do?
- 20. API - How to Design Date
- 21. Lots of Other Resources ✤ How to design RESTful APIs ✤ CRUD ✤ HTTP API
- 22. What is the point?
- 23. Who will use it? ✤ Dell Digital Delivery - 10 million machines, more each year to download software ✤ Cyberdog - other developers to implement new components ✤ JavaSoft javax.mail - Developers implementing Services, or sending Email ✤ Handstand - devices retrieving travel magazine
- 25. Why Document? ✤ Another programmer will need to know how it works, and trial and error sucks ✤ Test Your API, write a client from your own docs ✤ Keeps your code honest ✤ Becomes a real API when a client is written by someone other than you from your docs
- 27. Find & Reuse Good APIs ✤ Don’t reinvent the wheel ✤ Find another similar, and expand or convert ✤ Learn from bad APIs
- 29. Key Aspects ✤ Versioned ✤ Errors - was the request successful? invalid data? server blew up? ✤ Consistent to itself - delete_book, friend_delete ✤ Iteration ✤ Design with a partner or isolation, not large groups
- 30. Iteration ✤ High Level APIs ✤ Data Model, Design Objects and Connections ✤ Keep asking, what other actions need to be done? What other data? ✤ Walk through the scenarios ✤ retrieve library, log in, add book, delete book, post comment
- 34. Q & A, Part One Date
- 35. Junior ➪ Senior Date
- 36. Characteristics of Bad Junior (or bad Senior) ✤ Worried about how you look, or what you say ✤ Focused on small parts, misses big picture ✤ Makes changes without understanding repercussions ✤ Not my part
- 37. Good Senior Developer (or Good Junior Developer) ✤ Says, “I don’t know” ✤ Takes responsibility ✤ Continually Learning ✤ Will “Take one for the team” ✤ Given Any Problem, Can Invent a solution ✤ Can learn needed skills ✤ Goes beyond the basics
- 38. Basic Mistakes
- 39. Separate Concerns of Code ✤ Putting code unrelated into one group/class ✤ Networking code in the DB code ✤ UI Controller Code, with Table Cell Display Code ✤ Too many lines! ✤ “Wasn’t sure where else to put it” Ask!
- 40. Cut & Paste Solutions ✤ Found something on Stack Overflow, paste it in! ✤ The Interweb is not always correct ✤ Take the time to understand what it does, and why
- 41. Hard Coded Values ✤ Just don’t do it. Use config, use Class definitions, or Statics
- 42. Reinvention, Bad idea ✤ Calendar formatter ✤ Network Library ✤ Search, or ask. Know your domain
- 43. Warnings, Errors ✤ Fix warning messages, they are usually there for a reason ✤ If something fails, understand WHY it failed. Interested in making sure it doesn’t happen again ✤ Know where to fix it, document your changes ✤ Example: Cucumber test with TEXTAREA gave an extra ‘r’
- 44. Be sure to test ✤ “I’m sure it must work in all those cases” ✤ Take the time to think about your code
- 45. Too Focused on Small Parts ✤ Focus on the most important parts. Don’t know? Ask! ✤ iOS app, focused on getting a particular toolbar exact to the specifications, but those specifications would change ✤ Optimizing before recording data, profiling
- 46. How will this change the app? ✤ DB code, using “select statements” and adding in specific fields ✤ Made it work in the short term, impossible to manage in the long term ✤ Change one class, but not really understand how it is used elsewhere
- 48. Mentoring Date
- 49. Ask for Feedback, Code Reviews Date
- 50. Read/Learn Date
- 51. Build Tools, APIs, Libraries Don’t do the same thing over and over Date
- 53. What is your.... Q & A, Part Deux Date