One Man Dev Team - FATC 2011

Transcript

1. Jonnie Hallman destroytoday.com ONE MAN DEV TEAM adobe / destroytoday
2. HOW I STARTED WHAT I MADE WHAT I LEARNED
3. we got our first computer in 93, a mac performa 476, 25mhz, 4mb ram
4. Jane Blob i got really good at clarisworks. jane blob story, couldn’t change license name. i didn’t know much about how digital stuff worked (apps, games, etc)...
5. I was really into video games and made websites for video game cheats/moves using geocities & angelfire, but they always had banners....
7. JONHALLMAN.COM dad noticed my interest, bought me jonhallman.com and hosting for christmas
8. $300 for lifetime of hosting - he still sends me the $0 invoices
9. tried really hard to ‘brand’ myself, but was never happy with the result, so the website remained a ‘coming soon’ page for months
10. it was around this time that i learned about flash i was the tech person for the middle school morning announcements
11. we needed an intro and i made an animation using shape tweens.
12. macromedia had a free 30 day trial for their apps, so instead of buying them...
13. i would reinstall OS 9 every 30 days didn’t take too long for a 5 gig harddrive
14. how i got started i was inspired by flash gods like joshua davis...
15. ...and robert hodgin, so i made experiments they had such cool names, so i thought i needed one myself
16. FIRST-IN-LINE.NET jonhallman.com wasn’t cool, so i also got first-in-line.net, possibly the worst domain name to remember
17. inspired heavily by praystation i’m the kind of person who feels empty when i’m not producing always had a stack of loose papers with sketches on them coded the ideas when i got home from school each day super lame, had multiple email addresses for no reason
18. around flash mx 2004, i had enough and gave up on it... I got deep into PHP and made dynamic web apps, like jpixel
19. it takes a 100x100 image and blows it up 10x, using dot patterns to represent each pixel
20. i got into graphic design during pre-college at risd and mica and turned my digital work into print I tiled outputted JPixel images, making huge 12x10 ft prints
21. SHAW JELVEH DESIGN started working for a small studio called shaw jelveh design first thing they asked is whether i can make flash websites
22. they had me design and develop 3 sites in my first 2 months with tight deadlines, i learned how to code fast, esp since i worked 10 hours a week i also learned to keep things simple
23. produced a dozen websites in less than a year some of them, i only had a week or 2 before they were due
24. on my friend’s birthday, I was at his house and I challenged myself by coding luke’s site in the duration of high fidelity
25. as well as learning how to code fast, i also learned how to learn fast greenbuild, conference for sustainability
26. in my junior year, I heard about AIR and fell in love with the idea of apps rather than websites I replaced most of my gd classes w/ independent studies
27. USERS VS CLIENTS TOOL VS PRESENTATION INCREMENTAL VS ONCE AND DONE I liked app development because of this you have to please clients. try to make users happy, but don’t have please them all.
28. NO RESTRICTIONS ANY LANGUAGE ANY PLATFORM ANY IDEA apps became very personal
29. DESIGNER DEVELOPER PROJECT MANAGER CUSTOMER SUPPORT YOU requires many roles I was ready because of shaw jelveh
30. 1 HOUR 1 HOUR 1 HOUR 1 HOUR 4 HOURS what takes 1 hour for each person will take you 4 hours
31. DESTROYFLICKR i took a photo imaging class.
32. we used flickr for critiquing i hated the site - white background, static pages, very slow to navigate
33. i thought of taking this opportunity to make my own app using flickr’s api i started sketching and brainstorming
34. since i was new to UI design and had such a heavy background in web design, the app looked just like a website, but on the desktop.
35. (sorry, Ryan) and i wasn’t an icon designer by any means, so i took inspiration from CS3, since most of my dock was adobe apps. i later met the icon designer during my adobe interview.
36. (movie of DestroyFlickr too large for download) the end result was an app that had a better environment for photos (dark background) it was very fast because it only needed to load the images you could page through hundreds of photos in seconds with animated transitions
37. i tried to make features that were unique and that I would get a lot of use from, like drag and drop downloading. you could drag a handful of thumbnails and it would download the hi-res versions.
38. I took it a step further and made it so you could drag and drop a contact to download their entire photo library
39. i released it for free and shared it with friends and fam the install count went from 30 to 3000 i started getting tons of emails. some reported bugs, others requested features, and some just said thanks. I tried to respond to every single one. many didn’t realize I was one guy. someone even gave me a ps3
40. flickr caps the api at 1 query per second, once destroyflickr reached that, instead of throttling DF...
41. they interviewed me
42. on top of that, i won an adobe design achievement award i knew now that maybe app dev was a good direction
43. enhance!
44. enhance!
45. WHAT DID I LEARN?
46. THE WORD “DESTROY” SCARES PEOPLE many didn’t use it because they thought it would delete their account. at the same time, many used it because of the name.
47. DON’T DEVELOP AN APP YOU WON’T USE you’ll miss essential features and ux will suck i didn’t use flickr much, so i missed essential features like sets/groups
48. NO APP SHOULD REQUIRE A GIG OF MEMORY memory - not a concern for web, but definitely for apps keep track of everything you allocate memory for
49. a feature like this shows complete disregard for memory
50. MOST GOOD FONTS DON’T SUPPORT A WIDE RANGE OF CHARACTERS selecting all the glyphs you want to embed doesn’t mean the font has those glyphs arial ms unicode is the only font with (almost) every glyph
51. i thought all i needed to do was check these boxes
52. USE PROVEN METHODS AND CONVENTIONS i didn’t go to school for programming, so i didn’t know any design patterns or any of the terminology use an architecture framework (mvcs, robotlegs) follow a common coding style otherwise you’ll spend more time refactoring when you discover your way doesn’t work well.
53. since I only ever dev’d by myself, I didn’t really know what good code looked like. the style I used was based on what I found useful and it was soooo bad
54. KEEP APPS UP TO DATE WITH DEPENDENCIES if you want to continue developing an app, keep it current with your libraries I was able to develop DF fast because I had a lib for common classes, like images, text, etc. i forgot to update DF with my libs, and it was too late
55. TALK ABOUT TWITTER!
56. To me, Twitter is a background service, like IM. It’s not fulltime, like Photoshop or Flash Builder. When I want to tweet, I’ll open it, tweet, then hide it. All the current apps were bloated and cumbersome, so I made DT super light and super intuitive. Hotkeys galore.
57. DESTROYTWITTER spent a day researching others, jotting down pros/cons then coded v1 in 10 days over christmas break
58. MOST USERS KNEW “DESTROY” (old people don’t use Twitter) so it didn’t scare people as much
59. PERFECT APP FOR COLLECTING FEEDBACK also made it easier to respond to users, instead of emails bottling up
60. I i knew to use a proven framework, like Robotlegs
61. It was my first persistent app—open for long periods of time. Because of this, I paid extra attention to memory and CPU usage.
62. And once I got the basic Twitter functionality down (tweeting, streams, etc), I started adding special features I wanted. Because of unfollow drama and events, I added filters. DMs and unfollow notifiers make things awkward, and i’ve been confronted
63. Since Twitter is reading-intensive, people want it to be easy for them to read. For some, that means black text on white, for others it’s white text on black, so I made themes. Now no one complains.
64. With so many users, you have thousands of opinions. Everyone wants the app to work different, so I added preferences when anyone wanted something a specific way. It quickly overflowed the preference pane.
65. Place a file called ‘debug’ here to receive RTEs with full stack traces. I set up a script to email users’ stacktraces to me.
66. 300,000+ INSTALLS 1 MILLION+ TWEETS/MONTH
67. WHAT DID I LEARN?
68. A RESIZABLE WINDOW IS A REQUIREMENT NOT A FEATURE support a resizable window
69. DO NOT PUSH AN UPDATE BEFORE YOU GO TO BED a bug will always exist http://http:// story
70. USE A PROPER VERSION CONTROL SYSTEM ...
71. I kid you not, this is what my version control system was. I didn’t know version control existed, so I’d zip the folder.
72. NOT EVERY UPDATE IS FROM 1.0 TO 1.1 backwards compatibility
73. PEOPLE LOVE ANYTHING PRIVATE & BETA (especially teen ‘professionals’) free quality engineers
74. PUT FRESH EYES ON YOUR CODE working alone on something for too long makes you too familiar and you miss things. go open source or set up code reviews. everyone learns.
75. we use code collaborator at adobe
76. AUTOMATE AS MUCH AS YOU CAN since you’re just one man, the more you set up to run automatically, the more time you have to be productive use build scripts, unit testing, continuous integration, make a common lib
77. use jenkins
78. FINAL THOUGHTS
79. MAINTAINING AN APP IS A HUGE COMMITMENT (especially alone) think years and make sure you’re ready to invest your time and energy
80. MOTIVATE YOURSELF WITH VARIETY if you code all day for work, the last thing you’ll want to do is code all night. your work will use up all of your creative juices and you won’t have much left for your apps.
81. HAVE FUN Enjoy what you’re working on.
82. THANK YOU
83. ONE MORE THING...
84. I AM OPEN SOURCING DESTROYTWITTER
85. website destroytoday.com email jonnie@destroytoday.com twitter @destroytoday