Hello everyone, so like I said, I didnt get to attend as many sessions as I had hoped because I was cranking out about 10 edited videos a day but the sessions I was able to attend were pretty awesome and informative. The exhibition hall was overwhelming, I had no idea there were so many different startups in Austin, it was insane. Oh and about 90% were mobile app related. Heres some of the sessions I attended and some interesting info I jotted down from each, some of it is obvious info but others may find it interesting :
1.Agile Apps: Effective Mobile & Native Development
-Amanda Wixted, CTO & Co-Founder, Hyperspace
-Kyle Neath, Dir of Design, GitHub
-Anne Halsall, Prod Designer, Quora
-Jonah Williams, Sr Software Engineer, Carbon Five
Key Points/trends :
*Easier distribution of betas among team/staff = Higher Productivity, better apps
*All utilize Testflight for iOS beta dist
*its pronounced (get)hub, according to github dir of design lol
*move away from modular coding techniques, better to consider app as a framework and extending will become easier
*Native Code writing, a lot more time intensive than web apps
*Getting betas to users as soon as possible is best even if all functionality is not there yet (exception in gaming apps)
*Utilize built in SDK UI stuff before customizing your own
*much higher risk for native apps than for web apps...users much more critical in review of native.
*Analytics are key to measure goals etc
*Pick a key feature for spec device and build first and release, then update if necessary, instead of packing every feature of top and delaying release
*UI testing on mobile still extremely hard, apple provides framework but only for native
*Use analytics to test UI
*Possible to release to appstore to only select users, if u need to get past 100 device limit by apple adhoc
*Launch soon and collect analytics, dont worry about huge launch party :)
*under a week to get an app into appstore, maybe a day if just updating an app
*usage bump expected on update because app ends up in new apps section
*ARC for iOS is awesome, use it
2.DIY Mobile Usability Testing
-Belen Barros Pena, Interaction Designer, Open Source Technology Center (Intel)
-Bernard Tyers, Mobile Networks Engineer, Nokia Siemens Networks
Usability testing is an interaction designer’s bread and butter, but applying it to the study of mobile applications and websites brings considerable challenges. Which device should we use for testing? Can we use an emulator? How do we prototype for mobile? Can we just recycle the tasks we use for desktop software tests? Do we test in the lab or in the wild? How do we record screen, fingers and facial expressions?
Follow us in our quest to set up a mobile usability testing environment on a tight budget. We’ll show you how others do it. We’ll roam around electronics and professional video stores searching for brackets and webcams. We’ll put our DIY skills to the test and waste a lot of silicon trying to build our mobile recording device. We’ll scour the Internet for free software, and we’ll finish off building the lab and running a usability test in front of your eyes.
Key Points/Trends :
*Key considerations when buying/building a uability testing rig :
*easy to put together
*allows holding phone
*allows one-handed use
*supports all form factors
*runs tests w/ participants phones
*cap screen, face, and fingers
*give enough vid quality
-Chris Joel, Developer, CloudFlare
-Kyle Simpson, Owner, Getify Solutions
-Lindsey Simon, Developer, Twist
Join Mathias Bynens and John-David Dalton from jsPerf.com, Chris Joel from Cloudflare.com and Lindsey Simon from Google/Browserscope in this panel discussion on some of the best dev-created benchmarks and most interesting practices debunked by real-world tests.
*Your for loops suck: rewrite all your code and use: while –i BUSTED
*Double your localStorage read performances in Chrome by getting by index. TRUE
*The arguments object should be avoided. BUSTED (but isn’t as good in Opera)
*Frameworks (like jQuery) are always better at managing performance than you are, so just use what they provide. BUSTED
*Converting a NodeList to an array is expensive, so you shouldn’t do it. For instance document.getElementsByTagName() returns a NodeList, not an array, and then iterating over it compared to an array after taking the performance hit of converting it. BUSTED (also see: Static node list, which is closer to a performance with an array)
*Eval is evil, it’s too slow and quirky to be considered useful. BUSTED The performance is pretty much equal with all benchmarks.
*Regular expressions are slow and should be replaced with simple string method calls using indexOf(). BUSTED Engines are getting faster now with RegEx.
*OO API abstraction means you never have to worry about the details (including the performance). BUSTED Your API design matters more than it just being OO.
*Type torsion (===) takes more processing power than a regular comparison (==). BUSTED There is a difference, but it’s so tiny you shouldn’t be concerned.
*Caching “nested property lookup” or “prototype chain lookup” helps (or hurts) performance BUSTED In most cases the browser engine already makes the cache, and this wont matter at all
*Operations which require an implicit primitive-to-object cast/conversion will be slower BUSTED For instance, when converting a number to a toString() or toNumber() it doesn’t affect performance
*Scope chain lookups are expensive BUSTED
*Use switch statements instead of if/else if for better performance. POSSIBLY. In most cases this is true, except in Safari and Mobile Safari. The panel recommended to just use what you need.
*Use native methods for better performance. BUSTED
4.Defense Against the Dark Arts: ESAPI
-Chris Schmidt, Leader, Aspect Security
-Pamela Neal, Technical Producer, Owasp Foundation
The internet is a virtual playground for all kinds of bullies, those in it just for the "lulz" to those in it for the cold hard cash. This workshop will demonstrate how you can use ESAPI to protect your application from attacks that could lead to serious breaches from attackers ranging from script kiddies to the advanced persistent threat by examining high profile attacks and the defenses against them. Using examples such as the recent Sony and Citibank breaches we will examine how you can protect your app from the same type of attacks and also how you can leverage the components in ESAPI to detect the threat and react to it before it becomes a breach.
Key Points/Trends :
*2 api calls to encrypt and decrypt
*FUD = Fear Uncertainty and Doubt
*Most liberal open source license
*If using maven only needs to be added as dependency
*If any company claims "Advanced persistent threat" after an attack it means -> They have no idea whats going on.. :)
*Never send sensitive parameters in URL, he claims to see this in 1/3 sites he visits in a week.
*Types of cyber attacks have tripled in the recent years
- Christian Linares
“We are expected to know how to do things we’ve never done before and estimate how long they will take.”