Lee Whitney III

Compare Size and Growth Trends for StackOverflow Tags

When evaluating new platforms and frameworks it helps to know how active the developer community is and how much it's growing.

I've created a tool here that shows tag activity over the last 6 months at Stack Overflow:

Stack Overflow Size and Growth Tool

For example when comparing Javascript frameworks we can see that knockout.js has a bigger community, but angular.js is growing more quickly. angular.js has a bigger community and is growing more quickly than backbone.js.

The mass is the total number of posts and the momentum is a weighted average of growth over the last six months.

Mass and momentum are key factors to knowing which developer trends will turn into decisive shifts.

 

 

Offline Capabilities: Native Mobile Apps vs. Mobile Web Apps

Many mobile apps could benefit from working without an Internet connection. Here, we take a look at how offline capabilities affect the decision of developing native apps vs. mobile web based apps.

Apps that continue to work while “offline” or “disconnected” have been important since laptops first became common. A classic example is a salesperson that wants to enter data while travelling, and then have that data automatically sync with a server when they get back to the office. Even with Wi-Fi and cellular broadband, there are many scenarios (airplanes, Wi-Fi only devices, remote areas) where people still need to work without a connection.  So, when offline access is needed should we develop a native app or web app?

Read the rest of my article here: http://buildmobile.com/offline-capabilities-mobile-apps.

 

 

 

 

Five things to know before you start developing Windows 8 Metro apps

 

The only way to build a mobile tablet app for all versions of Windows 8 will be to use the new Metro application framework, and it’s much different than previous Microsoft platforms.  Developing Metro apps for Windows 8 is a combination of leveraging your existing skill sets and learning concepts that are new to the platform.

Following are five things that make developing Metro apps new and different.  Food for thought as you dive into new waters and create the next great app that will earn you fame and fortune.

 

 

 

1.  Programming language now determines your presentation layer

Previously Windows developers could choose a programming language like C# or VB, and separately choose a presentation layer like WinForms or DirectX.

When developing Metro apps, if you choose C#, VB, or C++ you automatically buy in to XAML as the presentation layer.  If you choose Javascript, your destiny is tied to HTML5 and CSS3.   There is no mixing of C# and HTML5, and no mixing of Javascript and XAML. 

This coupling of language and presentation increases the importance of making the right language decision for your project.  Deciding which is better largely depends on what the priority is for your project. 

Javascript and HTML5 are a great investment when you want to build skills that can be reused on widely diverse projects.  For example Javascript can be used to build Metro apps, HTML pages, native apps for all mobile devices, and even server side systems like NodeJS.

C# and XAML have the advantage of a large number of developers already being experienced with the technology.  My sense is that with respect to a Microsoft platform like Metro, more developers know how to animate with XAML than with CSS3.  Not having to relearn the basics on a project with a tight schedule can be a lifesaver.

Choose your language strategically based on existing skill sets and what future projects you want to be ready for.

 

2.  NoSQL has a new meaning

Metro apps are unique in that they do not have easy access to a SQL based relational data store.  Most existing Microsoft platforms can directly use some flavor of SQL Server such as Express, Compact, or CE, but this is currently not the case in           the Metro sandbox.

Even if you downloaded and integrated an open source database like SQLite, there may be problems getting your app approved because of security requirements.  Most databases have not yet been designed to run within sandboxed environments.

So how do you manage data in a Metro app?  Of course data can be written to the file system and manually managed, and there is also an interface to an ISAM data store (ESE,  Jet Blue).   However probably the most common approach will be to use one of the semi-structured data storage mechanisms.

Metro apps have access to IE10 local storage technologies such as IndexedDB, which is an emerging standard.  It is also very simple to use a cookie style local storage mechanism for key-value pairs.  Finally, it’s still possible to call web services that make use of SQL on a separate server, but that doesn’t help with local data storage.

So all is not lost, but this is definitely a different world for developers, plan your data management accordingly.

 

3.  Background tasks work differently

Running code in the background has always had rules.  One rule that has always been intuitive to most developers is that once you start a background process it will continue to run until you stop it.  This is no longer true.

With Metro, apps that are in the background do not automatically continue to run.  Instead they are suspended until the user brings them to the foreground.  By default only the foreground Metro app will be running and taking CPU resources at any given time.  This is not a limitation; it’s by design and is a new model for app behavior on Windows.  The idea is to maximize responsiveness for the user, and to conserve resources for mobile devices.

If this all sounds familiar it’s very similar to the way iOS works.  When Apple added multitasking to the iPhone, it only allowed for background tasks to run in very specific scenarios, and so it is with Metro apps on Windows 8.  Metro apps can request to run in the background for audio playback, data transfer, and notifications.

This new model is primarily motivated by mobile scenarios, however it is also the model for Metro apps on the desktop.

 

4.  Don’t expect to have all of .NET’s functionality

We’ve come to rely on the greatness of .NET, but in Windows 7 the .NET framework was built using the entire Win32 API.  With Metro, everything is built (including .NET libraries) on the new WinRT API.  The bottom line is that .NET functionality for Metro will be a subset of all that is available with the full framework.

For example, is WCF supported for Metro apps?  Yes and no.  The core client scenarios all work, but the WS* specifications like WS-Security are not supported.  The MTOM binary attachment encoding is not supported. 

The good news is Microsoft has chosen the subsets carefully to maximize what is possible.  It’s just a good idea to double check what’s supported if you have specific needs.

 

5.  The new UX is not just new controls

Previously new versions of Windows added new controls (widgets), but the core idioms stayed the same.  Windows 1.0 (released in 1985) and Windows 7 both have menu bars, captions, and resizable app windows.  Windows 8 Metro apps have none of these.  Even the Metro-ish UX on Windows Phone 7 is different, it has things like the panorama control while Windows 8 does not.  Our cheese has been moved. 

 

Because of this our job description now includes learning about the new UX idioms in Metro so that we can know when they make sense for our apps.  Some of these include the AppBar, Semantic Zoom, Partial Page Docking, and Charms.  There is a dedicated MSDN area that covers all of these here: http://msdn.microsoft.com/en-us/library/windows/apps/hh779072.aspx.

You probably don’t need all of these new features in your first Metro app.  However if you don’t take advantage of the ones that are appropriate it could make for a less than perfect fit with Windows 8.

 

Onward and upward

Windows 8 is not just about technology changes for change sake.  All of the items above are part of a bigger picture to enable better apps and faster development.  Visual Studio 11 is the primary tooling for Metro development, and fortunately it retains the title as the best development platform on the planet.  Overall Metro is calling us to create the next killer Mobile apps.

 

Startup advice and scavenger hunts

People who are interested in startups are always in need of feedback because the ideas they come up with on the first, second, or 100th iteration will probably still have lots of flaws.  Our need to constantly evolve is even codified into concepts like MVP (minimum viable product strategy).  The result is that entrepreneurs are in a constant loop of asking for and giving feedback from everyone around them. 

Most people agree such feedback loops are a good thing, but the trickier question is when should you change what you're doing based on the opinion of others and when should you ignore what you hear?  The two schools of thought I see most often argue to embrace or reject advice based on a person's resume.

Resumes win

This approach gives weight to a person's opinion based on prior experience or successes.  Many would say trust your friend's opinion more than your mother's because your friend has worked at a startup and your mother has not.  Trust Steve Job's opinion more than your friend's because he is currently the embodiment of entrepreneurial success and your friend is not.  It's a simple set of equalities:

        Your friend at a startup  >  Your mother

        Steve Jobs > Your friend at a startup 

The side benefit here is being very easy to sell to investors, partners, and employees.  You have to spend very little time convincing people of your decision with this technique.

If you ignore resumes you could lose big - remember these are (many times) extremely smart and experienced people.  

Resumes lose

The alternative recognizes that successful people can be horribly wrong and if they "just don't get the vision" can be utterly blind to a great idea.  

Some prominent venture capitalists famously got up and left during EBay's pitch because they thought  "selling antiques online" was a bad idea.  Fortune 500 execs are constantly making strategic mistakes that look obvious to others.  Many think Research In Motion is the only one who doesn't know their strategy is flawed, even though the company has been wildly successful in the past.

The corollary to this is equally dangerous - not only do big resume people easily make mistakes, people with modest credentials are constantly delivering break through ideas.   EBay's relatively unknown founder was right and a talented VC was 100% wrong.  That was literally a billion dollar decision point.

Going against the grain or against resumes in some ways is like playing the Megabucks jackpot in Las Vegas.  It's risky, many people will think you are wasting your time, but if you are actually right about something no else even understands yet, the reward could be more wealth than you could imagine for rescuing a rebel princess.

Scavenger hunts

I think the best approach frames a successful startup more like a scavenger hunt rather than what types of people are right or wrong.  To have a successful startup you must collect the right "list" of "items".  The list is the group of items necessary and sufficient for one type of startup to be successful.  The items are ideas, strategies, and information.  Therefore the goal of listening to the feedback of others should be to collect items on the list. 

The items we seek are held both by people of the highest socioeconomic status and the lowest, and we ignore either at our own peril.

Only you know what's on your list so people will try to convince you their items are valuable, but that may or may not be true.  They are usually not lying, they just have their own lists which may be different from yours.

In this analogy maybe a person's previous experience and/or "success", means that they are good at scavenger hunts.  They are good at finding and collecting items.  We should listen to these people to learn their skills and techniques.  We should realize the more different our list is from the person we're listening to the easier we can be led astray.  We should realize that in this scavenger hunt it's possible my mom is holding one of the items on the list.

Yesterday I gave advice to some friends on their startup.  I hope they can pick out which of my items are on their list and which are not.

 

 

Quantum Mechanics, Negative Entropy, and Super-fast Computers

The overlap of computer science and theoretical quantum physics grew a little today when the journal Nature published a very cool new paper from scientists in Zurich.

What entropy means to software people is usually much different than what it means thermo-dynamics people.  Turns out the concepts can be unified via a deeper understanding of quantum mechanics.

If you are a normal person you probably fell asleep reading the last two sentences.  If you're an abnornal person and are interested in things like the ultimate limits of super-fast computers, it's worth a read.

Here's an article on the paper from Science Daily. 

 

iPhone OAuth Starter Kit for LinkedIn

 

I've created a starter project for using the LinkedIn Api via objective-c and the iPhone/iOS. 

 

 

I'm sharing this because I don't know of anywhere else you can get these in one place:

• One project with OAuth, JSON, and LinkedIn Api examples integrated
• Fully functioning, add your app keys and run
• Uses JSON data, includes the fastest iOS parser available
• Does not use HTTP body, everything in Authentication header
• WebView integration, no figuring out how to mix in the UI pieces
• XCode 4.01 project

Hopefully this can save someone some time.  OAuth has 1,000 tiny details that can go wrong - and usually do when you're first starting out.

Any feedback on the project or code is welcome.

Updated 4/11/2011: Rebuilt with XCode 4.01, added icons.

Download OAuthStarterKit_iOS_1_1

 

iPhone / iPad OAuth for LinkedIn, Facebook, Twitter

Most apps these days have some kind of tie-in to a social network of sorts.  Which means your iOS code has to potentially authenticate a user to many different services.  

The good news is there is a standard for this called OAuth.  The bad news is it is one of the most error prone developer tasks I've seen recently.

OAuth is not hard conceptually like Quantum Mechanics, rather it's hard like there are a thousand little things you can do wrong that cause it not to work, and you end up spending time tracking down what little parameter is wrong by 1 character.

Normally in this situation a quick Google search will reveal lots of carefully refined libraries so you can just drop them in and go.

One problem with OAuth in finding a helper library is the major players like Facebook and LinkedIn are not implementing the standard in the same way.  For example Facebook uses OAuth 1.0 while LinkedIn uses 1.0a.  Just enough difference to require every library user to waste time finding the same subtle differences.

For iOS, I've yet to find a single OAuth library that supports all major services.  I mean out of the box without digging and tweaking for each service.  Yes I've seen things like the OAuthConsumer project and others, but again none are plug and play for the major services.

If anyone else finds one drop me a line, otherwise I'll consider releasing my own.  It's too late for me to not waste time on this, but others can be saved.

We need an open, canonical, objective-c library that makes these services codable by my 9 year old son.

 

 

 

! The Beauty of Creating iPhone Apps

Most people would agree the iPhone is pretty far ahead of Windows Phone 7; however there is a harsh irony that is only known to developers who use both platforms.  The irony is while the iPhone user experience is ledgendary, Microsoft’s development platform makes Apple’s tools look like it is from the Stone Age.

 

A few examples of developer water boarding:

 

Pointers still, really?

Pointers are all around you in Objective-C.    Garbage collection is a great productivity advance and available on both Android and WP7 for most code.   If Apple is going to use a language based on Smalltalk can we at least keep one of it’s best features?  Welcome back to non-null invalid object references. 

Nilla Wafers

Many nilla wafers = good.  Many forms of nil = bad.  The concept of a null reference is pretty well established after decades of use.  However for iOS apps you have:  Nil, nil, NULL, and NSNULL.  Yes all 4 needed for different subtle reasons and yes this alone has generated tons of posts from people trying to figure it out.  Love it.

ActiveX for iPhone

One of the nasty things about ActiveX controls was that referencing counting was a fundamental requirement to manage object lifetimes and it drove people crazy trying to master and manage it.  The iPhone platform, like ActiveX, has referencing counting as a fundamental requirement.  In both cases it is the source for many developer headaches.

We don’t need no stinking namespaces

This one is more comic relief than it is a problem.  Since objective-c does not support namespaces *every single framework method must be prefixed with NS* to avoid collisions.  So everywhere in your code is NS this and NS that.  Really this can be funny to look at.

Not all bad

To be fair I’ve been using all the preview releases of Xcode 4 and the IDE has made huge improvements and has some nice features.  For example I can set a nice bell to sound when a build is successful right from within the IDE while on Windows you have to do this in the control panel.  That’s something isn’t it?  :-)

 

Live from New York

A Surface application I’ve been working on has just gone live to the public in Manhattan, NY.  You can check it out at Bloomingdale’s in the Clinique area.

 
All the real products you see in the photo can be used interactively.  For example you can place a tube of moisturizer on the table and have it sent to your Facebook wall or e-mail.

 

 

Everything “feels” great to use – the gestures, discoverability, and design I all like personally.  Although the last statement may sound self-serving it’s really to the credit of the designers and Clinique product team.  By the end the process they really “got it” and have enabled a special experience.

 

 

 

Intel CPU vs. NVidia GPU: Video transcoding

There are some new benchmarks that imply Intel’s new CPU (Sandy Bridge) may actually match dedicated GPUs at video transcoding.

Intel today showed for the first time special new CPU instructions in action optimized for this task.  Encoding performance is a tricky business and all details are not available yet, but what we have so far is Intel looking very good.

The numbers compare standard Core i7 quad-core encoding with NVidia GPU and Sandy Bridge CPU encoding performance.  The encoders used were Handbrake (x264) for Core i7, Badaboom for NVidia’s GTX 260 GPU.  The Sandy Bridge encoder is not known but Intel maintains its own encoder so it may be a special version optimized for Sandy Bridge.

*Units are seconds of source video, not frames

 

 

The source and target video profiles were respectively 1080p and iPhone 480x320.

 

Grains of Salt

Now for the caveats and uncertainties that must be understood to put these numbers in context.  Consider the above numbers rough comparisons for reasons including the following:

• The encoder settings and output quality are not known to be equivalent.  This can make a massive difference in results.

• I did not run the benchmarks myself.  The Core i7/Badaboom numbers come from overclockersclub, and the Intel benchmarks were timed by Anand Lal Shimpi on his watch from the audience.

• We don’t know the exact clock speed and turbo mode for the Sandy Bridge demo.  It could be a mid-range model or a high-end extreme equivalent.

• X-Factor: The x264 encoder runs on CPUs only and it is widely considered the best encoder available.  On their team are some insane geniuses who seem to be able to optimize almost anything.  So if Intel's encoder is fast, the x264 version will likely be even faster.

Caveats not withstanding we are gettting a glimpse of the CPU/GPU video encoding battle shaping up here.  For a company like Badaboom the final results could determine their entire viability as a going concern.  For NVidia GPU encoding has been the poster child for one of the most mainstream uses of general purpose GPU computing.  For Intel it’s about staying relevant for more workloads in a new era of massively parallel computing.

The Verdict

So what do you think, will Badaboom or NVidia be hurt by Sandy Bridge?  Or is it too little too late for Intel in the encoding battle?

The final answers will start to unfold when official Sandy Bridge review samples arrive before the end of 2010.