TxJS 2011

Buildin’ Apps @txjs #2011

FAIR WARNINGIf you are sensitive to anything gtfo.

This includes...• sexuality• gender• race• religion

... and not limited to:• microframeworks vs uberframeworks• native vs web• vim vs emacs Basically, any polarizing junk debate.

Nothing is absolute; there is no right or wrong.

// embrace imperfectionnull instanceof Object// falsetypeof null// ‘object’

# whoami @brianleroux

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 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

When in doubt,use brute force. Ken Thompson

Eric S. Raymond

Rule of ModularityWrite simple parts connected byclean interfaces.

Rule of ClarityClarity is better than cleverness.

Rule of CompositionDesign programs to beconnected to other programs.

Rule of SeparationSeparate policy from mechanism;separate interfaces from engines.

Rule of SimplicityDesign for simplicity; add complexityonly where you must.

Rule of ParsimonyWrite a big program only when it is clearby demonstration that nothing else will do.

Rule of TransparencyDesign for visibility to makeinspection and debugging easier.

Rule of RobustnessRobustness is the child oftransparency and simplicity.

Rule of RepresentationFold knowledge into data so programlogic can be stupid and robust.

Rule of Least SurpriseIn interface design, always dothe least surprising thing.

Rule of SilenceWhen a program has nothing surprisingto say, it should say nothing.

Rule of RepairWhen you must fail, fail noisilyand as soon as possible.

Rule of EconomyProgrammer time is expensive; conserveit in preference to machine time.

Rule of GenerationAvoid hand-hacking; write programsto write programs when you can.

Rule of OptimizationPrototype before polishing. Get itworking before you optimize it.

Rule of DiversityDistrust all claims for “one true way”.

Rule of ExtensibilityDesign for the future, because it will behere sooner than you think.

Balance > Purity

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

practice != principlebest practices are temporaldon’t confuse a practice w/ a principleeg: technology w/ goal (eg. git vs rcs)

great principlesrevision controlissue trackingunit testingautomated builds

principle ... practicerevision control ..... gitissue tracking ......... bugzillaunit testing ............. qunitautomated builds ... hudson

mobile developmentyour development operating system(s)device operating systemssoftware development kitsIDE dependencedevices themselves

mobile developmentis a hostile environment

“It’s a poor craftsmanwho blames his tools.”

“Get some new tools.”

programming is hardfailure is likely; if not inevitable

so, what are we waiting for?

http://github.com/brianleroux/cordova

the web as a platformdeep API integration to the host envfirst class tooling support

standardsW3C various groupsTC39 * * green developer needs modules badly

mobile browser scenewebkits every-fucking-where I lookie still happensopera mini / opera mobilefirefox

device apissensorsdataoutputs

device api browser scenegeospatial business everywhere(literally!)Capture API now in Android 3.x, Operafile api partially seen in FF, Android

PhoneGap PlatformsiOS webOSAndroid SymbianBlackBerry Bada

The PhoneGap Web EcosystemAny JS framework.Any text editor.Anything appropriate for web dev.

micro vs uber

microframeworksprostiny! less code is good.does one thing wellconsnot cohesive (require glue and updates)inconsistent (different codebases)

uberframeworksprosfuture proofing built instructures your code for youconsheavy (lots of code)generalized (do not do one thing well)

It’s easy to make a case foror against either approach.

It depends.

Be appropriate.

So, how doesPhoneGap work?

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.

iOS init webview* PhoneGapDelegate.m line 178

iOS Native to JSThis was what inspired the original hack!

document.location// I shit you not

iFrame

Android webviewimport android.webkit.* * DroidGap.java

Nasty bug in Android 2.3 emulatorscaused addJavaScriptInterface to fail... Possibly some devices too.

onJsPrompt// I shit you not

Android Native to JS* ghetto, but it works and did work for a very long time

com.phonegap.CallBackServer.java

// you can’t make this stuff up!

document.cookie// I shit you not

PluginsAny native code can be called byPhoneGap.Anything: its always been this way too.Thats how it works dude.

PhoneGap APIAccelerometer EventsCamera FileCapture GeolocationCompass MediaConnection NetworkContacts NotificationDevice Storage

Closer look at Geogeolocationaccelerometergyroscopemagnometer

Closing concernsdebuggingperformancesecurityThe Future

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

debuggers are not a substitute for unit tests and linting

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

ZOMG Future!!!Windows Phone 7PhoneGap/Qt (Symbian && MeeGo)http://build.phonegap.com

Futuristic Future!!!1!Background ServicesWebGLWeb Notifications API<menu>alternate rendering engines (non-webkit)

mobile is hostile: use build tools toautomate repetitive tasksread up on those that came before; thisisn’t new stuffbuild a mobile web app firstgive vanilla javascript a try; its a neatlanguage!

thx, eh!

http://blog.derekperez.com	155
http://lanyrd.com	31
http://vimeo.com	13
url_unknown	7
http://www.vimeo.com	3
http://twitter.com	1
http://www.slideshare.net	1
http://paper.li	1
http://groups.drupal.org	1

TxJS 2011

by Brian LeRoux on Jun 11, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

9 Embeds 213

Statistics

TxJS 2011 — Presentation Transcript