ye ol’ UNIX philosophy mythical collection of koans bottom up and pragmatic ignoring it is irresponsible
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
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 and put 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 even then don’t unless one part of the code overwhelms the rest. Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don’t get fancy. (Even if n does get big, use Rule 2 first.) Rule 4. Fancy algorithms are buggier than simple ones, and they’re much harder to implement. Use simple algorithms as well as simple data structures. Rule 5. Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. Rob Pike Rule 6. There is no Rule 6.
When in doubt, use brute force. Ken Thompson
Eric S. Raymond
Rule of Modularity Write simple parts connected by clean interfaces.
Rule of Clarity Clarity is better than cleverness.
Rule of Composition Design programs to be connected to other programs.
Rule of Separation Separate policy from mechanism; separate interfaces from engines.
Rule of Simplicity Design for simplicity; add complexity only where you must.
Rule of Parsimony Write a big program only when it is clear by demonstration that nothing else will do.
Rule of Transparency Design for visibility to make inspection and debugging easier.
Rule of Robustness Robustness is the child of transparency and simplicity.
Rule of Representation Fold knowledge into data so program logic can be stupid and robust.
Rule of Least Surprise In interface design, always do the least surprising thing.
Rule of Silence When a program has nothing surprising to say, it should say nothing.
Rule of Repair When you must fail, fail noisily and as soon as possible.
Rule of Economy Programmer time is expensive; conserve it in preference to machine time.
Rule of Generation Avoid hand-hacking; write programs to write programs when you can.
Rule of Optimization Prototype before polishing. Get it working before you optimize it.
Rule of Diversity Distrust all claims for “one true way”.
Rule of Extensibility Design for the future, because it will be here sooner than you think.
Balance > Purity
Unix Haters Handbook “...your book is a pudding stuffed with apposite observations, many well- conceived. Like excrement, it contains enough undigested nuggets of nutrition to sustain life for some. But it is not a tasty pie: it reeks too much of contempt and of envy. Bon appetit! Dennis Ritchie
practice != principle best practices are temporal don’t confuse a practice w/ a principle eg: technology w/ goal (eg. git vs rcs)
great principles revision control issue tracking unit testing automated builds
principle ... practice revision control ..... git issue tracking .........bugzilla unit testing ............. qunit automated builds ...hudson
mobile development your development operating system(s) device operating systems software development kits IDE dependence devices themselves
mobile development is ahostile environment
“It’s a poor craftsman who blames his tools.”
“Get some new tools.”
programming is hard failure is likely; if not inevitable
onJsPrompt // I shit you not
Android Native to JS * ghetto, but it works and did work for a very long time
// you can’t make this stuff up!
document.cookie // I shit you not
Plugins Any native code can be called by PhoneGap. Anything: its always been this way too. Thats how it works dude.
PhoneGap API Accelerometer Events Camera File Capture Geolocation Compass Media Connection Network Contacts Notification Device Storage
Closer look at Geo geolocation accelerometer gyroscope magnometer
Closing concerns debugging performance security The Future
debugging? no longer a colossal PITA chrome building in smarts for remoting most ide envs have step debug now until then: pull out your weinre * * http://debug.phonegap.com
debuggers are not a substitute for unit tests and linting
performance http://stevesouders.com is the man latency != init != exec less code is faster code to write, exec, debug compile, concat, min, inline, etc closure compiler advanced mode is promising DO NOT use css transforms (yet) AVOID gradients, text-shadow, etc