Mike Kuphal's Thoughts

Session Speaker: Nickolas Landry

Main focus is Interacting with location service.  Not a very popular session as only five people in this session.

WP7 location services

-Phone positioning via GPS, Assisted-GPS (cell towers) and WiFi

Bing maps Web Services include: (REST & SOAP)

• Geocoding service
• Routing service
• Search service

Geospatial Data storage options

• SQL Server 2008
• SQL Azure
• Bing spatial data services

Pros/Cons of each Phone positioning technology:

-)GPS:

+ Accuracy

-Power

-Speed

-Indoors

-)Cell towers:

-Accuracy

+Power

+Speed

-Wilderness

-)WiFi: (Uses crowd sourcing)

-Accuracy

+/- Power

+/- Speed

+/- Urban areas (better in urban areas) 

Don’t have to interact the technologies directly.. Just use Location Services API.  The service is ‘smart’ and figures out which source to use given the parms you give it for accuracy/etc.

Emulator doesn’t allow for location services.  Some mock services can be used.  Next release of WP7 dev tools (coming out with Mango) will have new tools for this.  Separate window will automatically feed location  coords based on Bing Map point and click as well as some route creation.  (My guess is similar to how Android does this stuff now)

Namespace to use = Microsoft.Phone.Controls.Maps

To use maps control,  you need ot have a Bing’s map account.  Using Live ID.  This is free.  Make sure you pick Mobile as the type of app when signing up for the key.  This will allow you to request unlimited GeoCoding/Reverse GeoCoding calls, even in the enterprise.  Just needs to be run on a mobile device.

GeoCoordinateCatcher(GeoPositionAccuracy.High ) Will use GPS if can get info from it.

.Default will try to use a combo of wifi/cell tower or a cached location.

Things you need to know for LIS

• Locate the phone position
• Display a map at specific coors (lat,long)
• Pan/Zoom the map
• Add a pushpin to the map
• Geocode an address
• Calculate & draw a route on a map
• Draw a polygon on the map

LocationServices have a property that allows for reverse geocoding.  (CivicAddress Class)  Don’t have to call the Bing Maps WebService, can just use this on the device and it will abstract the stuff.

A few things coming with the Mango release: 

• Camera stream access
• Compass and Gyro API’s (Should lead to augmented reality scenario possibilities)
• Will have new options for live agents and multitasking

I felt Nick did a very good job delivering the content he set out to deliver.  Very knowledgeable and one who was willing to share his knowledge after the session too.

Session speaker: Robert Machale

Unfortunately Robert had trouble accessing his Google Docs account, so he did not have access to his slides.  Worst part was that he didn’t let the room know he was waiting to try and get on the network for the first 15 mins of the session.  After 15 mins, then finally mentioned to group he was waiting but was going to start without them.  

He feels Android will take over 3-5 years, except for iPad.  FAA recognizes iPad as a replacement for kneepad for flight deck.  Executives like iPad.  Those were main reasons he thinks the iPad isn’t going away anytime soon.

Can ask GPS receiver 3 questions:  Long/Lat/Altitude  You have to use other tools to extend after that.

Get values from GPS Satellites or Network carriers triangulation . Can choose either.  Listen to GPS or Network.  90% preferable = GPS

Claims that a Visual studio dev’s first choice should be Android over WP7 even… Likes the dev environment and says it’s easy to learn if you already do C# development.  This is a plus.

Side frustration: he polled the room and 9 out of 10 people surveyed said that have created a Android app… yet he went painfully slow through the setup process of creating a project, setting up emulators, etc.

Claims you should use Android 1.6 – Api Level 4 and all Android devices will work.  Also noted that every Android device will have an SD Card.

Tip: When your Android app runs, your SQLLite db is in your app folder (not SD card). 

Tip: flip from portrait to landscape views via:  Control F11 or F12.  Numeric 7 key allows you to toggle landscape/port mode.

Tip: You can setup “folder called layout-landscape” if you use the same input id’s… you can have two layouts and it will switch.  Says it’s more desirable to do this, instead of having the screen resize/etc using relative placing of elements.

Tip: to get through a firewall… you can set emulator command line options with Firewall Username/Password

Tip: Emulator control window will help you be able to modify the GPS info being sent to the phone.  KML = google map centric format of location controls

SQLLite is really a whole lot like MS Access

Session was disjointed, but a few tips were gathered.

Ric Telford, from IBM presented:

A private cloud is not ‘the cloud’.  This is not true.    Cloud model can be embraced by everybody.

Cloud is a delivery model for IT with these attributes:

• On demand self service
• Ubiquitous network access
• Location independent resource pooling
• Rapid elasticity

A delivery model that allows developers to get to consumers

A delivery model that everyone can do.

“Cloud is about not having to own servers.  No capital expense”  this is true.

Can get a lot of the value independent of if you own the servers or not. 

Private cloud = IT capabilities are provided as a service over an intranet, within the enterprise and behind the firewall

Public cloud = it activities/functions are provided as a service over the internet

Hybrid = Internal and external service delivery methods are integrated

Figured cloud will evolve to Platform as a Service (PaaS).  Deploy app to platform and the system takes care of capacity/redundancy/etc.

When going to cloud, encouraged to do a Total Cost of Ownership (TCO) analysis based on a financial institution:

• Divide Could implementation life cycle into 3 phases
• Analyze major cost components
• Identify tasks, skills, and considerations from each phase
• Apply best practices, fill solution gaps, and enable skills.

Realize it’s more than just server costs, look at energy costs (cooling/etc), real estate costs, etc.

Here is where private clouds are going:

Yesterday: Individual Deployment

Today: Shared hardware and Virtualized apps.

Tomorrow: Integrated Middleware platform and Image Management

Benefits of today:

• Increased utilization of infrastructure
• Location independent deployment

Challenges of today:

• Building images
• Image proliferation
• Governance of changes
• Creations of composite apps
• Connectivity to legacy and off premises apps

Benefits of Tomorrow:

• Standardized middleware
• Increased utilization of software
• Improved deployment speed
• Simplified app management

IBM Smart Cloud is IBM’s cloud offering.  Focused on enterprise customers mostly.

Hybrid cloud: Share data and process integration across boundaries (public and private cloud services).

IBM Product = Cast Iron to enable data/process integration across boundaries

Where are we going with cloud:

• To fulfill its potential as the next evolution of enterprise IT, cloud comp promises to become much more than an enabler of it efficiencies.
• It promises to become a driver of business transformation, innovation and growth.
• IT without boundaries.

Mobile and cloud… one begets the other.  Cloud will enable companies to be more responsive in the mobile space.

IBM sees Analytics as the ‘next big thing’ in the cloud.

55% believe cloud enables them to focus on transforming their business and make their processes leaner, faster and more agile.  Innovation=yes

Biggest bottleneck of cloud = network costs.  They haven’t come down like other costs.

Figure 20% (like highly regulated) of biz processes should not be migrated to cloud.

Overall, I went to three Cloud based sessions today, one by IBM (this one), one by Amazon Web Services, and one by RackSpace.  I would have to say that many of the same concepts/conclusions/points were communicated in general by each company.  IBM focused on enterprise push, Amazon on being the place for everyone, and RackSpace on their use of OpenStack.

Speakers: Paul Thurrott, moderator; Jay (saurik) Freeman, Cydia; Tyler Lessard, RIM; Aaron Hillegass, Big Nerd Ranch, Robert Scoble; Romi Mahajan, Microsoft.

This session was a free for all that jumped around quite a bit.  I liked the informality of the talk points as it felt more genuine to me in this format.

Main take aways/talking points I got were:

• Yammer… adopted virally at Rackspace
• Trend to invest in customer driven technologies is what is going to happen in the consumerization of IT.  We (the users) are bringing technology into the corporation.  IT needs to adjust to that.  Be an enabler instead of a policy enforcer.
• Carriers are not the friend of innovation though their contributions are important to the ecosystem.  They are needed, but don’t get much credit from the user base.
• Feedly app is similar to FlipBoard.  Feedly took approach to support all platforms via  HTML 5 implementation.  FlipBoard focuses just on iPad.  Is feedly’s interaction/UI good enough since compromises needed to be taken to work on all major platforms?
• Personal note: I was shocked at how many people in the audience didn’t know about the FlipBoard app.  (Based off of number of people writing during the FlipBoard background discussion (which was brief)).
• Native vs HTML.. Native will always ‘win’ from security/features/etc… can always do better.
• Group seems to believe no one winner (platform wise) will come out of this deal. (Similar to CC cards… Amex, Visa, MC example was used.)
• Tyler Lessard mentioned: 12/24 months… devices will become our wallets.  Scoble says they already are.  
• Biggest fear for Aaron Hillegass: “The death of board-em”   You tend to seek out more hearty meals when board… With a phone/mobile device: you get Frito’s instead, meaning just little bites of info, but never a full meal.  (This has lead to kids not knowing how to entertain themselves.)
• HTML5 does not equal “Thin client”

Mike Riley (@MRiley)presented mainly on low cost micro controllers, specifically Arduino micro controllers.

Arduino = most popular and cost-effective.

Arduino (and all other micro controllers) needs Actuators (like motors) and sensors

Ethernet shields allow for wired networking (TCP based networking)

Xbee Radios (for wireless)  -not 802.X as they need lots of power

Need a server to do the ‘real’ information processing.  Not going to want to do intense work on the micro but instead have it call web services to do the heavy lifting.

NetDuino = popular with .NET Dev’s… Comes built in with Ethernet board… and can use C# to program it.

These devices can use serial communications.

Best place to get schematics/plans already drawn up by others: Instructables.com  and Google searches.

Recommend creating REST-based web services… connect via serial comm library.  Keeps things light weight.

Designing the mobile client interface:

• Test first with a simple web page exposing services via HTML UI.
• Hook up UI to REST-full implementation
• When viewing data, optimize UI to show key elements.

Adafruit.com and Sparkfun.com are the choice sites to go to when you want to get hardware add ons (actuators, sensors, etc)

Mike mentioned this topic leads well into the idea of a “Internet of things” … and how this is so new… it’s ‘hacker’ space.  Refers to the networked interconnection of everyday objects.

Overall the session certainly peaked my interest in the NetDuino kit (as I would consider myself more of a .NET guy) as there are some really neat things you can make/program in this space.  I would also be very interested in seeing how 7th/8th graders would interact with this platform.  Seems like one that could certainly ignite a passion for computing/robotics/engineering/etc.

Speakers: Dan Burcaw  & Joe Pezzillo  (Push IO) – former Apple employees

Their current application infrastructure supports iOS, Android, Windows Phone 7 (and some other that they can’t discuss)

Admitted Real time data… is their focus.  Might bias their info.

SOAP is out!  Payload is just way to bloated.

REST is in (with JSON)  -lightweight

Parser Speed Iphone 3Gs: Built in iOS xml parser takes 2 seconds! Even best is just under a second.. That’s a long time on a mobile device.

Many of the fastest engines also have feature tradeoffs… just don’t have a ton of great options when looking at a XML parser from a performance perspective.

JSON performance is way faster: A few tested: Touch JSON,  JSON Framework, YAJL, ApplJSON …  Worse case of writing < 0.5 second.. Reading <0.1 sec

JSONKit is blazing fast.  This is a new one to look at.

JSON benefits:

• Compact data format (even more compact if whitespace is stripped)
• Very fast read/write speeds compared to XML
• JSON Libraries make it easy to convert from dict key/values into native objects
• JSON is well-supported on the server-side

TIP: Use JSONLint.com to view and ensure JSON is formated correctly.

Backend scalability/performance:

Data requests: Mobile is much more async.  A different kind of load that can bring down server from traditional web based traffic.  To coordinate the data your WebService is providing, You likely need to use one or more databases. 

Might be best to make a ton of smaller calls, instead of ‘a large data set’ all at once.  Don’t frontload the data load as that doesn’t scale well.

Probably best to increase the number of calls your app makes, by making lots of calls for small amounts of data, only data that you need at that point. 

Databases: Consider using in-memory databases such as Redis or Memcached to eliminate request/response bottlenecks.  Traditional disk-based dbs don’t scale well when serving medium to large scale mobile apps do to the volume of async requests.

Tip: Use in memory databases on the front end, then write to disk db periodically.  They use a ‘LAMP stack’ (these are called noSQL db’s)

Couch DB, mongoDB, Redis or Memcached are most popular NoSQL db’s now.

TIP: Web server settings: be sure to turn on GZIP compression.  This HTTP Header setting will reduce the size of the data payload sent across the wire. 

Mobile data files: not all data needed by mobile apps need a full fledged SOAP/REST WS:

Consider publishing static (vs dynamic) JSON files to a CDN, which avoids taxing your servers with dynamic requests.

This is really saying.. Determine data that is static.. and make that something different to call… instead of dynamic seek on all  data requests.

CDN pricing is ‘very cheap’ if you aren’t dealing with Video.  ( < fewer than $50 over a number of months)

TIP: When working with CDN’s, set your time to live very low. 

Static file could be written out every second (more like 30 seconds).  That’s static in the mobile world (expand your mind here)… could certainly do this thing on a min by min basis.  This really offloads traffic to the CDN instead of the Caching benefits of a CDN.

Server virtualization has some limits: Performance in particular.  MySQL performance suffers on a virtualized server.  Switched to ‘Bare Metal’ MySQL.  Even that wasn’t performing as well…  this is why they went to the in memory (noSQL) DB’s.  This is a probably when you exceed a ‘reasonable number of users’  think 10,000 users type thing.

Mobile apps… people don’t linger like on the web… lots of requests instead of just one on mobile.  (check it, check it, check it… lots of little data requests)

Registration/personalization doesn’t map well to the Mobile data files technique.  (Writes of data need to be handled differently than the consuming of data on the handheld.)

Realtime tips:

• REST-full WebServices with JSON Responses
• Gzip compression
• Mobile data files via CDN (low cache control policies)
• In-memory databases
• Load balancers and multiple worker nodes.

Theme = ”Do as little as possible in realtime” for highly scalable solutions.

Overall, I received many tips to consider.  Opened up my mind to many new possibilities to consider for the systems I currently work with and felt I gained a large amount of background info to consider as we grow our user base.  I am most interested in seeing what we might be able to do with a NoSQL DB.  This may be a great first step for us.

My notes from “A survey of Cross Platform Mobile IDE’s” session by @MRiley :

I would say at least 75% of the people at the Mobile Keynote were in this session, session was overflowing with people.   Just shows how interested people are in this topic.

Mike compared Mobile environment today (cross platform wise) to the PC environment of past(Diff SDK’s,etc between OS/platforms).

General statement was to do cross platform devopment, company has to bundle it’s platform into a vmachine (like Java) and standardize across all the platforms (can’t support every OS Specific feature, but generalize instead).

Session Summary:

• No silver bullet
• If native look and feel is paramount, develop using each platform’s native SDK
• If prototyping or function is more important than form, seek out these choices
• Current favorate is RunRev due to deep crossplatform support of mobile hardware-specific functionality.  UI Elements sill suffer due to non native implementation.  Adobe a close second.

Specific info on choices:

Adobe Flash Pro

They are the 800 pound gorrilla. Determined to move from desktop to mobile.  Spending huge amounts of money to make that happen..  They aren’t going away anytime soon.

To run on Apple, have to pull all Flash code into one single contained file (IPK File). 

To run on Android, need to have AIR/Flash runtime installed.  App is much smaller, but do take a performance hit because it launches the AIR app too.  The initial load hit is big.

Pros:

• Established Dev base
• Designer platform (UI is main focus of tools)
• Excellent iOS application conversion facilities. 
• Entrenched technology.. Isn’t going away.

Cons:

• Unpredictable Flash runtime on Android OS.  In essence have to test on all devices (for commercial app at least) to verify the Flash runtime will run your app as expected.
• Ongoing updates to Flash runtime, Frequent updates. This just compounds the above point, in additional testing on many devices.
• Can be resource intensive, especially on older mobile hardware

Rating = 4 out of 5 stars.  “Pretty Bullish” on offering

Excellent book on topic: Professional Flash Mobile Development: Creating Android and iPhone Applications by Richard Wagner

Genuitec MobiOne Studio

Attempts to create ‘Native’ apps.  Support iOS and Palm Pre now, Android later this year.

Compared to Dreamweaver.  Uses JQTouch (like Jquery on iPhone) which gives slick animations easily.

Phone Gap = close equivalent.  Takes HTML5 pages and packages them into native app.  In essence packages the HTML into an embedded web browser. 

Pros:

• Simple drag and drop HTML-centric GUI
• Supports JQTouch (jQuery plugin for mobile)
• Cheap (< $100)

Cons:

• Only supports iOS/PalmPre right now.  Android coming first 1/2 of 2011, but isn’t released yet.
• Dev tools only execute on Windows
• Does not generate native app files (PhoneGap does though)
• PhoneGap as essentially taken it’s space.  Flash CS5.5 release will make it’s world even less important.

Rating = 3 out of 5 stars.  Expects product to be gone in near future.

MoSync Basic Pro

Open source/Eclipse based tool.

Code in C/C++

Supports a huge mobile device list (>40 platforms)

Must pay for license if you use for commercial app development.

Pros:

• Large number of supported platforms
• Extensive API which supports Bluetooth, GPS, Camera, and other phone hardware
• Open source, so it’s protected against propreitary API lock in.

Cons:

• iPhone SDK and Xcode needed (iOS tool)
• Generic software emulators.  Need to do hardware deployment for testing mostly.
• A few features are missling like a weak GUI tool, a few advance API’s missing.  They are on the roadmap, but no comittments as to when they will be available.

Rating = 4 out of 5 stars.  Figures this platform will stick around for non-high end device support.  Tool is popular in Europe because of this in particular.

Mono for Android  /MonoTouch (iOS)

Port of the .net framework onto non-windows platforms. 

C# devs can develop Android and iOS apps

Pros:

• Excellent development solution for seasoned C# devs
• Produces binary apps with native platform look and feel (big)
• Mono libs offer the same level of access to mobile hardware as found in each platform’s native SDK’s

Cons:

• MonoTouch development requires Apple hardware running OSX v10.6 or higher  Also have to learn the Objective C and iPhone API’s (lots of learning.. Way worse than Android)
• MonoTouch and Mono for Android are two separate platforms:  can not recompile projects for each without significant code modification 
• Mono for Android requires a separate runtime to be installed on Android Devices.  (20 meg + another 10 meg runtimes).  Slows down initial app launch.
• No Linux version of Mono for Android available.

Rating of 4 out of 5 stars

Illumination Software Creator 3.0

Visual code generator.  No forms generation.  Simple if then else arrangement.  Simplistic forms.

Most useful for educational purposes, for looking at the native app dev and how each one platforms constructs their code to see what the code looks like. 

Pros:

• Generates native code for Android, iOS, WP7
• Useful for Prototyping designs
• Cheap

Cons:

• Requires SDK for each platform to compile generated code.
• No control over placement of UI elements
• Limited functionality

Rating: 3 of 5 starts.  Don’t see it sticking around

RunRev LiveCode Android Plug-in

Uses everything on the phone.. Full access.  Closest interactive environment for cross platform dev.  Android plugin under dev… released shortly.

iOS dev will need apple hardware device (10.6 or higher)

Pros:

• Excellent platform- specific support from a single code base.  (More of a programmers tool unlike Flash)
• Docs are good.  Company forum/support is great
• Intuitive, easy to use from design tools.  Similar to VB days.

Cons:

• Weak support for native UI controls
• Proprietary code syntax (hypercard/super card)
• Not too steep of Learning code, but is there.
• Expensive commercial license ($99 – $1499)

Rating: 4 out of 5 stars. He is most excited about tool.

Bonus question:

Given the rapid change in mobile environment.. Would you recommend waiting 6-12 months before starting commercial mobile dev (platform specific) or will it not matter?

—Mike mentioned he doesn’t think there will be a lot of improvement for cross platform dev tools.  (More platform support could happen).. Maybe a dark horse could emerge in 12 months but it seems unlikely at this point.

Overall, this session delivered excellent content and exceeded my expectations.  Theme of conn to this point very much feels that cross platform development is a pipe dream right now.  Tools just aren’t mature enough.

My notes from “Going mobile” MobileConnection Keynote by @AaronHillegass .  Key points:

-Mobile Sync is Hard/Expensive

– 78% of apps purchased are for iOS, 4% Android, 6% MS, 7% RIM.  Means should look to iOS apps to lead the way from a style and cut perspective.  (Innovation will happen on that platform first because of the volume).

-If you want to have an app work on all major platforms, will be expensive, unless you just want an app, and don’t care if it looks ‘delightful’.

-Want delightful on major platforms?  Have to go native on each.  HTML5/etc will just bring mediocrity into the game.  Look at Google Apps…. 7 years of the best programmers with a clear vision, and their word processor app is mediocre at best.

-Really need a cross functional team working on your mobile app if you want it to be successful (lower the risk).  Designer, App Programmer, WebService programmer, Management, User need to all be part of the team, but watch out for too many people in the game too.  This is classic scrum team advise.

-Be aware, mobile (and computing in general) is in a Coevolving situation.  (Like Cheetah and Gazelle.. as Cheetah gets faster, Gazelle has to either to stay alive)  Mobile Coevolving with User demand and Capacity of tools & process.   (as the tools/process gets better, the user demands go up too).  Side effect = more complex apps are being expected/asked for… which up’s the risk.

-He certainly believes that HTML5 is not the answer… Native apps are the path for the long term to “Free hour human potential”, which Steve Jobs believes in as well..  (computers = tool that allows for us to be better than we are without it)

Overall, a basic presentation on getting into Mobile app dev.  I didn’t find it extremely useful since my team has been doing Mobile app dev for years, but some good points for all to consider when diving in as well as maintaining apps long term.