8. ye ol’ UNIX philosophy - mythical collection of koans - bottom up and pragmatic - ignoring it is irresponsible
9. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features. Doug McIlroy
10. Rule 1. You can’t tell where a program is going to spend its time.Bottlenecks occur in surprising places, so don’t try to second guess andput in a speed hack until you’ve proven that’s where the bottleneck is.Rule 2. Measure. Don’t tune for speed until you’ve measured, and eventhen don’t unless one part of the code overwhelms the rest.Rule 3. Fancy algorithms are slow when n is small, and n is usuallysmall. Fancy algorithms have big constants. Until you know that n isfrequently going to be big, don’t get fancy. (Even if n does get big, useRule 2 first.)Rule 4. Fancy algorithms are buggier than simple ones, and they’remuch harder to implement. Use simple algorithms as well as simpledata structures.Rule 5. Data dominates. If you’ve chosen the right data structures andorganized things well, the algorithms will almost always be self-evident.Data structures, not algorithms, are central to programming.Rule 6. There is no Rule 6. Rob Pike
11. When in doubt,use brute force. Ken Thompson
12. Eric S. Raymond
13. Rule of ModularityWrite simple parts connected byclean interfaces.
14. Rule of ClarityClarity is better than cleverness.
15. Rule of CompositionDesign programs to beconnected to other programs.
16. Rule of SeparationSeparate policy from mechanism;separate interfaces from engines.
17. Rule of SimplicityDesign for simplicity; add complexityonly where you must.
18. Rule of ParsimonyWrite a big program only when it is clearby demonstration that nothing else will do.
19. Rule of TransparencyDesign for visibility to makeinspection and debugging easier.
20. Rule of RobustnessRobustness is the child oftransparency and simplicity.
21. Rule of RepresentationFold knowledge into data so programlogic can be stupid and robust.
22. Rule of Least SurpriseIn interface design, always dothe least surprising thing.
23. Rule of SilenceWhen a program has nothing surprisingto say, it should say nothing.
24. Rule of RepairWhen you must fail, fail noisilyand as soon as possible.
25. Rule of EconomyProgrammer time is expensive; conserveit in preference to machine time.
26. Rule of GenerationAvoid hand-hacking; write programsto write programs when you can.
27. Rule of OptimizationPrototype before polishing. Get itworking before you optimize it.
28. Rule of DiversityDistrust all claims for “one true way”.
29. Rule of ExtensibilityDesign for the future, because it will behere sooner than you think.
30. Balance > Purity
31. Unix Haters Handbook“...your book is a pudding stuffed with appositeobservations, many well-conceived. Likeexcrement, it contains enough undigestednuggets of nutrition to sustain life for some. Butit is not a tasty pie: it reeks too much ofcontempt and of envy.Bon appetit! Dennis Ritchie
32. practice != principlebest practices are temporaldon’t confuse a practice w/ a principleeg: technology w/ goal (eg. git vs rcs)
33. great principlesrevision controlissue trackingunit testingautomated builds
35. mobile developmentyour development operating system(s)device operating systemssoftware development kitsIDE dependencedevices themselves
36. mobile developmentis a hostile environment
37. “It’s a poor craftsmanwho blames his tools.”
38. “Get some new tools.”
39. programming is hardfailure is likely; if not inevitable
40. so, what are we waiting for?
42. the web as a platformdeep API integration to the host envfirst class tooling support
43. standardsW3C various groupsTC39 * * green developer needs modules badly
44. mobile browser scenewebkits every-fucking-where I lookie still happensopera mini / opera mobilefirefox
45. device apissensorsdataoutputs
46. device api browser scenegeospatial business everywhere(literally!)Capture API now in Android 3.x, Operafile api partially seen in FF, Android
47. PhoneGap PlatformsiOS webOSAndroid SymbianBlackBerry Bada
48. The PhoneGap Web EcosystemAny JS framework.Any text editor.Anything appropriate for web dev.
49. micro vs uber
50. microframeworksprostiny! less code is good.does one thing wellconsnot cohesive (require glue and updates)inconsistent (different codebases)
51. uberframeworksprosfuture proofing built instructures your code for youconsheavy (lots of code)generalized (do not do one thing well)
52. It’s easy to make a case foror against either approach.
53. It depends.
54. Be appropriate.
55. So, how doesPhoneGap work?
56. The technique...1. Instantiate a chromeless browser instance.2. Implement PhoneGap.exec bridge code.3. Implement native plugin code.4. Implement your JS API by wrapping PhoneGap.exec() into something pretty.
57. ... }
58. iOS init webview* PhoneGapDelegate.m line 178
59. iOS Native to JSThis was what inspired the original hack!
74. debugging?no longer a colossal PITAchrome building in smarts for remotingmost ide envs have step debug nowuntil then: pull out your weinre * * http://debug.phonegap.com
75. debuggers are not a substitute for unit tests and linting
76. performancehttp://stevesouders.com is the manlatency != init != execless code is faster code to write, exec, debugcompile, concat, min, inline, etcclosure compiler advanced mode is promisingDO NOT use css transforms (yet)AVOID gradients, text-shadow, etc