Jeff Bergier: Teaching Swift to Non-Developers

Transcript

1. Build and Run▶ The do’s and don’t on teaching iOS and Swift to non-developers
2. Jeffrey Bergier UX Designer @ Riverbed TA @ General Assembly Teacher @ MobileBridge Addicted iOS Dev @ Home @jeffburg jeffburg.com
3. A global group of volunteers dedicated to uplifting underserved communities in tech
5. @MobileBridgeSF bridgetroll.org github.com/mobilebridge MobileBridge
6. Standard Format • All Day Workshop on Saturday 9:30 to 5 • “Installfest” on day before workshop to get Xcode installed • Build a functioning app • Retrospective after workshop • Post workshop drinks with Students and Teachers
10. Plug (only one) • Volunteer Teachers • Volunteer TA’s • Volunteer Curriculum Developers • Office Space for Events • Food for Events • Volunteer Organizers
11. All Right Lets get started
12. Do A fully functional app. ☑
15. Expectations Have Changed
16. Tip Calculator Storyboards Outlets Actions Basic Math
17. Rotten Tomatoes Download JSON Parse JSON Storyboards Display in Table Download Poster Artwork
18. Do Know your student(s) existing skill level. ☑
19. Possible Questions • Do you know what a variable is? • Have you heard of “Object Oriented Programming” • Have you ever done web or flash programming?
20. Don’t Assume Beginners Know how to use Desktop Computers ☠
21. This the Mobile Age • Filesystems are hard • Windows are hard • Full screen windows are a nightmare
22. Do Believe in your students ability to learn this stuff ☑
24. Do Show common iOS design patterns. ☑
29. Quicktime Trick
31. Don’t Fight the framework. ☠ (Don’t B*tch to Students)
32. Don’t B*tch to Students • Storyboards • UIViewController • AutoLayout • Xcode • CocoaPods
33. Don’t Teach Swift ☠
34. Don’t Teach (the intricacies of) Swift ☠
35. Swift is a means to an end • We like Swift for many many reasons. • Unless you’re students are already developers, they likely won’t understand those reasons. • Focus on getting things on the screen. • Don’t teach Swift features or syntax beyond what is needed for the project at hand.
36. Do Be prepared. ☑
37. Questions for yourself • How long is the teaching session? • Is this the only session or is this daily / weekly? • Is this one-on-one or is it a group? • What am I teaching today? • Have I built this app on my own recently? • Getting lost in your own content is extremely disruptive.
38. Do Build and Run often. ☑
39. Get Something on the Screen • Run often • Spend the time to get the app running on their device (remember, its free now) • When you hook up an IBAction, use print() to show it works • When you hook up an IBOutlet, change the text to show it works. • Coding for more than 10 minutes straight is a complete SLOG. Try to keep it to no more than 5 minute stretches of code.
40. Do Crash often. ☑
41. Do Crash often. (on purpose) ☑
42. Common Crashes • Rename IBOutlet (Key Value Coding compliant) • Rename IBAction (Does not response to selector) • Unknown Cell Identifier • Found nil while unwrapping • Array out of bounds
43. Don’t Lecture ☠
44. Ask Questions • “What do you think will happen when we build and run?” • “Why do you think that happened?” • “Ok, now that that works, what do you think is next?” • Classes can sometimes be really quiet. Try to be humorous about it. “Bueller?”
45. Do Err on the side of Storyboards, rather than code. ☑
46. Storyboards are Amazing! • Even though you may not like them, they’re amazing. • No platform has anything as powerful • Its even great for designers, you can make such great workflows with ZERO code • (I know android has the equivalent of NIB’s, but they don’t have storyboards)
47. CTRL Drag • And lets not forget the amazing experience of IBOutlets and IBActions
50. Don’t Be a soup code Nazi ☠
51. Be unsafe, but tell them • !!!!!! • valueForKeyPath as! String • NSData(contentsOfURL: “sure is easier than NSURLSession”) • If you have time at the end, go back and make the coder safer.
52. Do Provide starter project. ☑
53. Do Provide starter project. (If needed) ☑
54. Starter Project • Does the project rely on a CocoaPod? • A lot of custom UIViewController and UITableViewCell subclasses? • A lot of boilerplate code? NSURLSession code? • Does any API used by the project use completion handlers? • Is there an API key for the service you’re using? • Does ATS f*ck up network access?
55. Don’t Teach AutoLayout ☠
56. AutoLayout • Very tedious • Lots of fiddly buttons in Xcode • Try UIStackView if you dare • Ask the students what iPhone models match these screen sizes.
57. Do Save time for customization at the end. ☑
58. The App Works • Customize background colors in the Storyboard • Customize fonts in the storyboard • Show how to have even/odd cell layouts • Show how to add an about screen • This sounds small. But this is HUGE. The satisfaction level of students that experience this step is ginormous compared to the students who didn’t.
59. Don’t assume beginners know how to use desktop computers Do know your student(s) existing skill level. Do show common iOS design patterns. Do be prepared. Do Build and Run often. Do crash often (on purpose). Do err on the side of Storyboards, rather than code. Don’t lecture Don’t be a soup code Nazi Provide starter project (If needed). Don’t teach AutoLayout Do save time for customization at the end. Don’t fight the framework. Don’t teach (the intricacies of) Swift Do a fully functional app. Do believe in your students ability to learn this stuff
60. Thank You Now get out there and teach the next generation of great creators ☑
61. Q&A