Of course, you’ll find amazing work in graphic design, architecture, photography, illustration, etc., but what you may not know is that Behance is a great place to find really good UI/UX designers too.

Check out some of the portfolios in the UI/UX category – http://www.behance.net/search?field=132 –

The community of Behance users is huge and growing.  Check out these stats – http://www.behance.net/facts

Here are the key features that sold me on the NEX-6:

• It supports RAW and RAW+JPG (and allows me to switch back and forth with one button).  If I’m doing snapshots, I’ll shoot JPG.  However, if I need maximum dynamic range and quality, I’ll shoot RAW and use Adobe Lightroom and Adobe Camera Raw to perfect the images.  Every camera I’ve owned in the last 10 years has had this capability.
• Like most modern compact cameras, the NEX-6 has sophisticated auto features but it also has aperture priority, shutter priority, and full manual.
• Instant response when pressing the shutter button.
• The interface doesn’t require me to go into the menus to make common setting changes (a show stopper for me with many cameras).  It has a simple mode-dial, and two dials I can turn with my thumb to change shutter speed and aperture.  Changing ISO is also very convenient.  There are also programmable buttons that allow me to put other setting changes a button press away.
• Fantastic low-light performance.  ISO 3200 on this camera is better than ISO 800 on my D300!  This is like a free lens upgrade in many ways!  The max ISO is 25,600 and it’s actually somewhat usable!
• Really good 16MP resolution using a APS-C (23.5 x 15.6 mm) sensor.  That’s about the same size sensor as my D300 and a lot bigger than the Panasonic DMC-LX3/5/7 and most other smaller cameras.
• Wi-Fi support – I can transfer images from the camera to my iPhone or iPad (or Android device) with no Wi-Fi network nearby.  The camera basically becomes a Wi-Fi hotspot that your mobile device can connect to, and with the help of a mobile app, download the images from the camera.  The camera also has the ability to push images to a computer if there is an available Wi-Fi network.  DPReview covers this in great detail here.  I honestly wasn’t looking for this feature, but I have to admit, it’s very useful.  NOTE: The NEX-7 doesn’t have this feature.
• 1080/60p HD movies – and they look fantastic.  Surprisingly, you can change the camera settings during the recording of the video.  I’ll post some samples later.  There are several good ones on YouTube already.

The camera also has a ton of  bells and whistles that didn’t really play into my decision, but I do enjoy them — Auto HDR, Sweep Panorama (both horizontal and vertical sweeps), apps, and hand-held anti motion blur.

There were four unexpected features in the NEX-6 that surprised me:

1. Focus Peaking – The NEX-6 offers focus peaking which highlights the in-focus details of the image in yellow (or red or white – it’s customizable).  Sam Mallery has a great article that demonstrates this here.
2. AEL Toggle – There is a AEL button on the back of the camera that works as you would expect – when you hold down the button, it locks the exposure until you let it go.  However, I discovered in the menus that you can turn this button into a toggle.  When set to toggle, you point the camera and press the AEL button and it will lock the exposure until you press it again.
3. Customizable Settings – the NEX-6 allows you to customize several buttons on the camera.  I think Mike Hendron covers this really well here (along with details on his own customizations)
4. Apps – I honesty snickered at the idea of “camera apps” when I first noticed this feature, but then I discovered that there are indeed some really cool apps for this camera.  An app basically adds new functionality to the camera.  You can see the entire list of available apps at https://www.playmemoriescameraapps.com.  Be sure to check out the Time-lapse app!  Note: The NEX-7 doesn’t support apps.

Why not the NEX-7?  I looked at the NEX-7 because it offers even higher resolution (24MP), but it’s lacking Wi-Fi capabilities and app support.  The NEX-6 also has higher ISO available.  There is a good comparison SnapSort.

Another pleasant surprise is that Adobe Lightroom already has a lens profile for the 16-50mm lens that came with the camera:

Lightrooom 4 Lens Correction Dialog

Disappointments:

I love this camera, but there are a few disappointments:

• Auto-focus sometimes gets confused in low light and takes a second or two to lock-in.  Maybe I’m spoiled by the near-instant focusing of my D300, but I wish the NEX-6 was a little better.  It’s still better than most compact cameras, but not up to high-end SLR-levels just yet.
• The battery life is a little disappointing.  It’s not terrible, but it’s not as good as my D300 or my DMC-LX5.
• My D300 and DMC-LX5 each have a feature that allows me to specify the lowest acceptable shutter speed when the camera is set to full auto exposure.  I’m actually decent at shooting hand-held at 1/15th of a second with the 16-50mm lens, but the camera assumes that I need some ISO boost when the shutter goes below 1/60th of a second.  It’s not a big deal since I can quickly switch to manual mode but I’m hoping that a future firmware update will add this level of customization like many of my other cameras.
• I find it almost impossible to stop a video recording without shaking the camera forcing me to cut out the final second of the video post-shoot.  It’s not a big deal, but I think the button should be a little easier to press.

Despite these disappointments, I am very happy with the camera.  I’ll definitely take it on my next Aerial Photography assignment, but my D300 will be nearby just in case!  There’s a huge difference between taking a few photos around the house and shooting from 1500 feet while moving at 120MPH!  I suspect the NEX-6 will work out.

Other Reviews and Info

• DPReview.com’s review of the NEX-6
• Sony NEX-6 Brochure (PDF)
• List of all Sony brand e-mount lenses (all work NEX-6)
• DPReview.com’s Sony NEX forum
• Camera Labs Review
• Sony’s home page for the NEX-6
• Great article on customizing the NEX-6
• Comparison of the NEX-6 with the Nikon 1 V2 (if you are a Nikon fan like me, this might hurt a bit)
• NEX-6 Tips and Tricks page on Facebook (my own creation so go LIKE it!)
• Amazon.com’s page for the NEX-6
• Other recent mirrorless camera options

Comparing it to other Sony NEX models (snapsort.com)

• NEX-6 vs NEX-5N
• NEX-6 vs NEX-5R
• NEX-6 vs NEX-7
• NEX-6 vs NEX-7N
• NEX-6 vs NEX-3
• NEX-6 vs C3

Using my Nikon Lenses (lens adapter)

I have several Nikon/Nikkor lenses, including a 50mm f1.4, Tamron 18-270mm and various others.  After some research, I found that there are several choices of adpaters that allow you to use your Nikon lenses on the NEX-6.  I purchased this one and so far, it seems to work really well.  I’ll do a separate blog post on the specifics soon.  There is a catch to this type of adapter however — you have to manually focus and manually control the aperture, but that’s no big deal, especially with the NEX-6′s focus peaking feature.

Summary

This camera could easily become my walk-around camera and also my pro camera for many types of assignments.  It’s awesome to have a camera with this many features fit into my computer bag.  I’m still in the honeymoon phase, so I’ll let you know how I feel about it in a few weeks.

Sample Photos

I have only had the camera for 4 days, so I haven’t had a lot of time to experiment but I do have a handful of shots to give you an idea.  If you click on any of the following photos, you will go to a larger version where you can view the original image and see the camera EXIF data.  I’ll do a followup blog post after the honeymoon period and will include many more pictures and some videos.  In the meantime, the reviews above have tons of sample images.  You can find good NEX-6 video samples on YouTube.

55-200mm lens, manual exposure, ISO 400, 1/125th at f7.1

55-200mm lens, manual exposure, ISO 400, 1/160th at f7.1

Full auto – untouched

Manual focus, Nikon mount Tamron 18-270mm lens with adapter

ISO 3200! Click to see a larger version and original image.

This blog is an aggregation of all of our blogs in chronological order.  When you click an individual article, you will go to the original source article  on the author’s blog.

You’ll also notice a combined Twitter feed that is from this Twitter list (member list)

Creating iOS web apps can be very error prone. The size requirements for icons and splash screens are odd and there are a few things that are non-obvious (e.g. the iPad landscape splash image is actually a portrait-shaped image but has its contents rotated; Retina displays reserve 40 pixels for the status bar while non-retina reserve 20 pixels, etc.). Also, if you screw something up, you get no errors. It just simply doesn’t work leaving you to guess/hack.

What started as a 15 minute attempt to get icons and splash screens working for my web app resulted in a couple of hours of what felt like pure hacking. Many of the online resources (including Apple’s!) were out of date and didn’t include information on handling iPad retina icons/images. I decided to share my results to hopefully spare others from the frustrating experience.

I created templates that show the proper use of apple-mobile-web-app-capable, apple-touch-icon, apple-touch-startup-image and how to use them with everything from an iPhone 3Gs, iPhone 4/4s, iPad 1, iPad 2, iPad Retina, etc.

You can find everything you need including working samples at https://github.com/gwilson/iOSWebAppTemplates

The Curiosity program got me thinking back about the Mars Viking program.  In 1976, NASA landed two probes on Mars that sent back the first pictures from the surface of the planet in history.  This was the first time a human-created device had landed on the planet, so there were a ton of unknowns.  I was very young, but I remember waiting for those first pictures from Mars, anxious to find out if the little green men would be friendly.

Here’s the first panorama ever sent from Mars (shot by Viking 1 lander – click it to go to the source and high-res versions):

This morning, I was reading about the Viking missions and stumbled on a little known, yet fascinating fact about the Viking 1 lander.  On November 11, 1982, an over-the-air software update was broadcast to the Viking 1 lander to correct a battery charging issue.  The update had an error in it and accidentally overwrote the wrong bits resulting in a bricked lander.  Basically, they accidentally overwrote the memory reserved for the antenna pointing code which immediately terminated all communications.  The mission had already been a huge success, so it wasn’t a huge deal in the grand scheme of things, but I bet those responsible for the error had a big “oh crap!, we just killed the probe!” moment.   I’d love to meet these guys.  I bet it’s a great story.  I imagine a few NASA engineers in a conference room going through a list of memory addresses that were part of the update, trying to figure out why they didn’t get any acknowledgement from the probe, and then finding the mistake and looking at each other in shocked disbelief and fear.

I can remember working from home on a production system and accidentally typing in the wrong iptables command resulting in the instant inability to connect to the server.  At least I was able to drive 30 minutes to the data center and connect a console to the server and undo my mistake!

Russian oops Phobos 1

I also learned that a similar mistake happened with the Russian Phobos 1 orbital mars mission.  From http://en.wikipedia.org/wiki/Phobos_program –

“Phobos 1 operated nominally until an expected communications session on September 2, 1988 failed to occur. The failure of controllers to regain contact with the spacecraft was traced to an error in the software uploaded on August 29/August 30, which had deactivated the attitude thrusters. By losing its lock on the Sun, the spacecraft could no longer properly orient its solar arrays, thus depleting its batteries.

Software instructions to turn off the probe’s attitude control, normally a fatal operation, were part of a routine used when testing the spacecraft on the ground. Normally this routine would be removed before launch. However, the software was coded in PROMs, and so removing the test code would have required removing and replacing the entire computer. Because of time pressure from the impending launch, engineers decided to leave the command sequence in, though it should never be used. However, a single-character error in constructing an upload sequence resulted in the command executing, with subsequent loss of the spacecraft.”

Software Heroes – Galileo

I also stumbled on a fascinating story about the NASA Galileo Jupiter probe launched in 1989. During it’s long trip to Jupiter, the high-gain antenna failed to open, even after many genius attempts at spinning the probe to free it (among other wild tactics).  This meant that NASA was stuck using the low-gain antenna.  The difference in bandwidth was dramatic — 10bps vs 134kbps (10,000 times slower)!  While the crippled probe was hurtling on the way to Jupiter, software engineers had to do some serious software rewriting to try and salvage as much of the mission as possible.  They rewrote the encoding/decoding software to get better compression and optimized the image compression algorithms among many other improvements.  Then they had to push these updates to the probe.  Can you imagine the stress?  Amazing stuff.  More details at http://www.nasa.gov/offices/oce/appel/ask/issues/42/42s_galileo_rocky_road_jupiter.html and at http://www.lpi.usra.edu/publications/newsletters/lpib/lpib76/gal76.html.

Software developers that write code for spacecraft are my heroes.  They work under incredible stress and have to cope with extremely low bandwidth, very limited resources, a non-touchable, non-upgradable hardware platform and they typically are writing very low-level code.  There are engineers still occasionally sending updates to the Voyager probes launched in the ’70s!  They communicate at 160bps and it takes 16 hours for any instructions to be received.  I get impatient when a git pull takes more than 5 seconds!

The trials and tribulations of ones and zeros!

UPDATE: I was reminded by a friend of yet another mission where engineers saved the day, and this one was fairly recent (2004) — The Huygens Titan probe.  Read all about it at http://www.thespacereview.com/article/306/1

See the code, docs, and sample usage at https://github.com/gwilson/getAccurateCurrentPosition

@myfriend Hello

Almost every friend I asked had the same answer, “All of your followers”. That’s actually incorrect. Only users that follow both of us see the tweet. This is documented in the Twitter help pages (under “Things to Note”).

To clarify, this only happens when the tweet starts with a “@”, which indicates that the tweet is a reply and replies get special treatment.

Recently, someone tweeted to promote a recent blog post of mine, but they wrote it this way:

@gregsramblings just blogged about …..

Unfortunately, their 10k+ followers didn’t see it. Only users that follow both of us saw it, which is a much smaller number, so I decided to create a little illustration of this Twitter oddity below.

Notice the common workaround of prepending a dot to the tweet as shown in the 4th tweet below. There is nothing special about the “.” character. It could have been any other valid character. If you want all of your followers to see the tweet, don’t start it with a “@”. Notice the 2nd tweet below.

It’s important to note that the filtering of replies is a feature of twitter, not a shortcoming. Most replies should have limited visibility because you are typically involved in an exchange of tweets with another individual. However, it’s important to understand the difference between a reply and a normal tweet.

Hover or tap one of the tweets below to see which followers will see it in their Twitter timeline.

What is it?

The Application Cache is a new HTML5 capability that is different from the normal browser cache that we’ve had for years.  The normal browser cache maintains copies of recent files that you have accessed and keeps copies of those files on your computer so that when you need the same file again, it won’t have to re-download it.  Other than some simple browser settings to control the overall cache size and a few meta tags to turn it on and off, you really don’t have any useful control over how it’s used.

The application cache is a web-application-specific cache, the content and behavior of which is controlled by the application itself.  The application cache is persistent and provides full off-line capabilities. It is currently supported in Chrome (v4.0+), Safari (v4.0+), Firefox (v3.5+), and Opera (v10.6+). It’s not currently supported in any shipping version of Internet Explorer, but it is coming in IE10.

Try it now with an offline-enabled website:

Go to http://phraffle.com using Chrome, Firefox, Safari or Opera.  You’ll see a simple one-page site that I created that people use to raffle off giveaways at speaking events.  Nothing special, right?  Now disconnect from the Internet and go to the site again using the same browser.  It still works in your browser as if you were still connected!  Your browser now has a copy of the website cached in the application cache and it will remain cached there until the user removes it.

Looking under the hood from Chrome browser:

If you are using Chrome, you can check out what was downloaded at chrome://appcache-internals/:

You can also see the files being downloaded from Chrome’s JavaScript console:

The console after hitting the same site for a second time:

More information about cache-related events is below.

Try an offline-enabled HTML5 Web app on an iPhone or iPad:

If you have an iPhone, iPad or iPod Touch, go to http://phraffle.com using Safari.  Tap on the share icon and select “Add to Home Screen” (you will see a popup pointing to the share button shortly after the page loads thanks to a cool JavaScript lib at http://cubiq.org/add-to-home-screen).

You’ll now see what looks like a regular app on your home screen with my custom icon.  Now, tap the icon to run the app from your home screen (with or without Internet).  Notice that the app is running full-screen with no Safari browser controls.  This is an iOS HTML5 web app.

I’ll show you how to set this up later in this article.

Setting up application caching:

Here are the exact steps I used to set up the above example:

• I modified the <html> tag to reference my soon-to-be-created HTML manifest  – <html manifest=”phraffle.appcache”>   This should be added to each HTML file that will be cached so that the user’s browser will be instructed to cache the files regardless of which HTML file was used as an entry point to your site.
• I then created my cache manifest file called phraffle.appcache in the web root folder.  This file contains a list of files required to run my site offline.  You can view mine here. Notice that it contains all of my HTML, JavaScript, CSS and image assets.  The manifest file name can be named anything, but .appcache  seems to be an established convention.

  CACHE MANIFEST
  
  # Version 1.5
  
  NETWORK:
  *
  
  CACHE:
  index.html
  jquery-1.7.2.min.js
  jquery.backgroundPosition.js
  jquery.spritely.js
  raffle.js
  images/reel_blur_numbers.png
  images/reel_blur.png
  images/reel_dash.png
  images/reel_normal_numbers.png
  images/reel_normal.png
  images/reel_normal.psd
  images/reel_x.png
  

• My web server has no idea what a .appcache file is so, by default, it will serve it up as a regular text file.  In order for app caching to work properly, the cache manifest file needs the MIME type set to text/cache-manifest.  I’m using Apache web server, so I simply created a .htaccess in my web root folder that has the following line: AddType text/cache-manifest .appcache   If you are using IIS or another web server, you’ll need to do a quick web search to determine how to associate the mime type “text/cache-manifest” to your .appcache file extension.
• That’s all that is needed to cache the files.  It works offline in any compatible browser, including mobile Safari, Android browser, desktop Chrome, Safari, Firefox, and Opera.

Breaking down the manifest file:

• The first line is “CACHE MANIFEST” (without quotes) and is required.
• Comments start with “#”
• The CACHE: section contains a list of files to be cached.  Wildcards are not allowed here.  You must list each file that needs to be cached.  In my file, it wasn’t necessary to add the “index.html” line to the list of cached files since every file containing <html manifest=”…”> is automatically cached, but it’s still good practice to include it.
• The NETWORK: section contains a list of online resources that are used by your app.  This is the most misunderstood part of the manifest file.  Cached apps do not have access to network resources unless those resources are listed in the NETWORK section of the cache manifest.  Wildcards are allowed here (thankfully!).  In my file above, I simply used “*” which basically means “you can access anything you want”.  (You may be wondering what network resources my silly apps needs… I’m using TypeKit and Google Analytics, both of which require Internet access).
• If I omitted the NETWORK section of my manifest file, my app would still work, but the fancy TypeKit font I used would not be loaded so the boring backup font of Arial would be used, and Google Analytics would not record the page hit.  Even if the user is online, access attempts to any network resource would be ignored as if the app were permanently offline.
• If a filename is listed in the NETWORK section (e.g. login.php), the current site URL will be prepended.  So listing “login.php” in the NETWORK section is equivalent to listing “http://mysite.com/login.php”.  In this case, the login.php file will not be cached and any accesses to the http://mysite.com/login.php will be from the website itself, not the cache.
• You can see the specific rules on how the NETWORK section is handled in the actual spec (see bullet 30.)
• I recommend starting with a simple “*” when you first start playing around with this stuff.  You can always change it to be more specific after you get everything working.
• The FALLBACK:section specifies fallback pages if an online resource is inaccessible.  I did not need this feature in my app, but below is an example of what a FALLBACK section would look like.  The first URI is the resource, the second is the fallback. Both URIs must be relative and from the same origin as the manifest file. Wildcards may be used.

  FALLBACK:
  *.html /offline.html
  *.jpg /images/missing.jpg
  

iOS – Making the web app run full-screen without Safari controls:

• After the above changes, I can use mobile Safari on my iPhone and iPad to access the page.  After accessing it once, it’s saved for offline use.  I wanted it to be more app-like, so I added the following meta tag to the  index.html:

  <meta name="apple-mobile-web-app-capable" content="yes"/>
  

  This will make the cached app run in full-screen mode so the user doesn’t see the Safari controls.

iOS – Adding custom icons and a startup image:

• By default, iOS will use a screenshot as the app icon.  I wanted something a little nicer.
• I created the 3 required icon sizes (57×57, 72×72 and 114×114) and added the following 3 lines to my index.html’s HEAD section:

  <link rel="apple-touch-icon" href="icon57.png" />
  <link rel="apple-touch-icon" sizes="72x72" href="icon72.png" />
  <link rel="apple-touch-icon" sizes="114x114" href="icon144.png" />
  

• You’ll notice that the images I used are square with no rounded corners (e.g. http://phraffle.com/icon144.png).  The rounded corners, drop shadow, and reflection are added by the device automatically.  You can avoid these “enhancements” by adding “-precomposed” to the filename (e.g. icon72-precomposed.png).
• It’s also possible to add a startup image for a web app. I didn’t do this on mine, but if you want to try it, here’s all you need in your html:

  <link rel="apple-touch-startup-image" href="startup.png">
  

Last year, the Financial Times rolled out their new iPad webapp using this same technique to avoid the Apple app-store rules (specifically, Apple’s requirement to take 30% of any in-app purchase).  Obviously this isn’t a perfect solution for many apps, but it’s a good option to have in some cases.

By the way, if you would like to build more sophisticated apps using HTML/CSS/JS, and take advantage of native APIs and true app-packaging, check out PhoneGap.

IMPORTANT — Updating your app (updating the user’s cached files):

• If you make any changes to your HTML, CSS, or other cached assets,  you will need to modify the cache manifest file so that users with previously cached versions of the files receive fresh ones.   The contents of the manifest file must change for it to be re-processed on the client side (simply updating the timestamp of the file isn’t enough).  You’ll notice that in my phraffle.appcache file, I have a simple comment with an arbitrary version number.  I simply increment the number each time I modify any files in the cache list to force previously cached files to be refreshed.
• It’s not currently possible to update a single file in the cache list.  It’s all or nothing.  When the browser sees a newly modified cache manifest file, it will re-download all files in the CACHE section again.  This is obviously a bit of a shortcoming.  Hopefully we’ll see this addressed in the future.
• If any of the files listed in the manifest are not accessible, the caching will abort.  The JavaScript console in Chrome will show the file caching activity, so you will quickly see any 404 or similar errors.
• I highly recommend validating your cache manifest using the following site – http://manifest-validator.com/
• Double-reload needed — when you access phraffle.com, your browser always checks the manifest file to see if it’s been updated (you will see this happen in the JavaScript console).  If the manifest was updated, the browser will download all of the files in the cached file list, BUT, the original content will have already loaded at this point (remember that it’s already cached, so it loads super fast!).  This means that you will not see the new content until you hit refresh again.  This is a bit of a pain at times!  There is a workaround that you can implement using the following JavaScript code:

  if (window.applicationCache) {
      applicationCache.addEventListener('updateready', function() {
          if (confirm('An update is available. Reload now?')) {
              window.location.reload();
          }
      });
  }
  

JavaScript Application Cache APIs:

There is an AppCache API that provides several hooks into the caching.  Everything is defined in the applicationCache object.  The two main methods are updateCache() and swapCache().  In addition, there are several cache events that you can listen for:

• checking - Fired once when the app reads the manifest file to see if it has changed.
• noupdate - The manifest file has not changed.
• downloading - Files are being downloaded
• progress - Fired once per each file downloaded. If you have 15 files, you’ll see 15 progress events. Unfortunately, the event itself doesn’t contain information about which file just completed, so it’s fairly limited in its current form.
• cached - Files have finished downloading.
• updateready - A new copy of the cache is ready to be swapped in.
• obsolete - The manifest file is code 404 or code 410; the application cache for the site has been deleted.
• error - An error occurred when loading the manifest, its parent page, or a listed resource, or the manifest file changed while the update was running. The cache update has been aborted.

If you want to see these fire, you can use the following code:

function logEvent(event) {
  console.log(event.type);
}

window.applicationCache.addEventListener('checking',logEvent,false);
window.applicationCache.addEventListener('noupdate',logEvent,false);
window.applicationCache.addEventListener('downloading',logEvent,false);
window.applicationCache.addEventListener('progress',logEvent,false);
window.applicationCache.addEventListener('cached',logEvent,false);
window.applicationCache.addEventListener('updateready',logEvent,false);
window.applicationCache.addEventListener('obsolete',logEvent,false);
window.applicationCache.addEventListener('error',logEvent,false);

Although it’s not part of the applicationCache object, you might want to know how to programmatically check if the user is online or offline.  This is done by simply checking navigator.onLine (boolean).

Using Google Analytics, Typekit and other services with Application Caching

When I first offline-enabled phraffle.com, I didn’t have the NETWORK section in my cache manifest. All of the files were still cached, but to my surprise, my Typekit “bello-pro” font wasn’t displaying and I was suddenly not recording hits on Google Analytics, even when I was online.

Typekit, Google Analytics and many other services obviously require internet access, but my lack of a NETWORK section in my cache manifest meant that all external URLs were inaccessible. Once I added the NETWORK section, everything worked normally again (when I was online of course).

Other fun facts, quirks, and ramblings:

Resources I used:

Here are the resources I found while researching this today:

• A Beginner’s Guide to using the Application Cache - HTML5Rocks.com tutorial
• Building and Offline Mobile Web Application by Christian Cantrell
• Offline Web Application – Dive info HTML5 Take this Offline
• Appcache Facts - Good reference for the cache manifest file contents.  This page claims that Firefox doesn’t allow a simple “*” in the FALLBACK section, but my current version seems to work fine, so I suspect that it needs a minor edit.
• Storing Data on the Client (Apple)
• Configuring Web Applications (Apple – covers the Apple-specific meta tags, icons, splash screens, and more.
• Building an Offline Mobile Web Application
• Configuring the Viewport (Apple – important information on controlling the viewport)
• Application Cache is a Douchebag – a colorful rant about some of the limitations of app caching.
• DOMApplicationCache Class Reference (Apple)

I did some research and found a few ways to disable scrolling altogether by intercepting the touchstart and/or touchmove events and calling preventDefault() on the event.   After some experimentation and studying the touch events documentation, I found a near-perfect solution.

In simple terms, when your finger touches the screen, it fires the touchstart event.  I then capture the X/Y coordinates. As soon as your finger moves across the screen, it fires the touchmove event where I capture the new X/Y coordinates. I then check to see which way you are trying to move the page by comparing the movement along the X and Y axis.  If it’s vertical (change in Y > change in X), I call preventDefault(), which prevents the scroll.

Here’s the code:

var xStart, yStart = 0;

document.addEventListener('touchstart',function(e) {
    xStart = e.touches[0].screenX;
    yStart = e.touches[0].screenY;
});

document.addEventListener('touchmove',function(e) {
	var xMovement = Math.abs(e.touches[0].screenX - xStart);
	var yMovement = Math.abs(e.touches[0].screenY - yStart);
    if((yMovement * 3) > xMovement) {
		e.preventDefault();
    }
});

Tweaks — I found that simply checking for change in Y > change in X wasn’t enough because I could drag diagonally at a near-45 degree angle and it would still tug my title bar down.  I wanted it to be more of a 20 degree check, so I added a multiplier of 3 on the y-axis movement (I don’t remember enough trig to know that 3  was the right multiplier to use — it was a bit of trial and error).

The results are good.  Grab your iPad and go to http://lottatweets.com, login, and once the tweets are displayed, try to scroll vertically.  The title bar and footer are locked in place nicely.  If you try hard enough, you can find an angle that will allow you to drag diagonally, but it’s good enough!

NOTE:  If you’re building an app with PhoneGap, there is a better solution that I blogged about earlier.  The above solution is for web apps accessed via iOS Safari.

UPDATE April 5, 2013 — Twitter killed the Twitter Anywhere API so the app is broke.  I’ll try to refactor it soon to use the newer APIs.

What is it?

LottaTweets is a web-based tool that fills your screen with tweets in a multi-column, newspaper-style layout allowing super fast reading.  In addition to being able to quickly scan tweets, there are a few neat features:

• Color coded retweet rate — Tweets are color-coded based on the number of re-tweets per minute.  It’s a quick way to visually identify tweets that others have found important enough to share.  There is also a button that will toggle filtering based on the retweet rate.  I originally was only using the re-tweet count, but I realized that it’s not a good measure since older tweets will always have more retweets than new tweets.  The re-tweet rate seems to work well.
• Noise factor — Each tweet shows the noise factor of the tweeter.  The theory is that if you have tweeted 2000 times but only have 50 followers, you are “noisy”.  The noise factor is computed by number_of_tweets / number_of_followers.  There is also a button that will toggle filtering based on noise factor.
• Infinite horizontal scrolling — you can keep scrolling right and it continues to load more tweets for you to read.
• Auto-refresh — if you check the box for auto-refresh, it will prepend any new tweets every 60 seconds.
• It’s read-only –  I configured my Twitter API endpoint to be read-only, so you don’t have to worry about the app tweeting anything on your behalf.  Each tweet has a link (timestamp) to the tweet on Twitter.com so you can reply, retweet, etc.  Each thumbnail image is a link to that user’s Twitter page.

Technical Details and the Development Experience:

• Lotta tweets is a pure JavaScript app with no server infrastructure other than a web server and Twitter’s Anywhere APIs.
• The layout is using CSS3 columns and works great with latest versions of Chrome, Firefox, and Safari.  It’s about 90% functional with Opera (there are some re-layout issues when filters are applied).  CSS3 columns are not supported by IE6/7/8/9, but should be available in IE10.  In order to support IE 6/7/8/9, I would need to use another means of multi-column formatting such as the jQuery columnizer plugin.  For now, I’m leaving it as-is.
• I had a great head start on this project from Tom Germeau’s Fork-a-Twitter-Client (FATC) project.  This provided the basic Twitter API interactions and saved me some hours of hacking.  The project uses a StratifiedJS implementation called OniApollo.  This was the first time I’ve seen StratifiedJS.  It’s a clever way to simplify complicated asynchronous applications.
• I found a few browser bugs (no web dev project would be complete without finding new browser bugs!):
  • Safari — I originally set each tweet div with overflow:hidden in case the tweet wrapped beyond the confines of the div.  This worked fine on Chrome, but on Safari, everything in columns two through n was hidden!  There were a lot of blank boxes with hidden text.  Only column one was correctly displayed.  I abandoned overflow:hidden for now since it’s very rarely needed.
  • Firefox — Firefox doesn’t use up all of the vertical space when laying out the divs.  I always had a blank space that was a few pixels taller than what is required to hold another row.  I believe that this is a layout issue because it only happens with Firefox.  As a workaround, if the user is using Firefox, I manually increase the height of the wrapper div to trick Firefox into thinking another row will fit.
  • Opera — when you resize the screen, or apply a filter, Opera doesn’t handle the re-layout correctly and things get a bit scrambled.
• Mobile — The site runs great on desktop Chrome, Safari, Firefox and Opera.  It runs OK in Safari on iPad, but the scrolling is a bit un-refined and slow.  I’ll work on this soon.  I haven’t tested yet on an Android tablet.  iPhone and other mobile phones are really too small for this type of layout.
• The font in the top bar is Felt Tip Roman, a font available on TypeKit.com, a fantastic service that I’ve only used once before on Phraffle.com.
• I use Modernizr to check if the user’s browser supports CSS3 columns.  A simple alert() is displayed if not.
• The Twitter Anywhere API uses OAuth to authenticate the user, but the cookie it drops is a session-only cookie, so you will have to re-connect each time you access the page after closing the browser.  The subsequent connects should only require a simple confirmation click and not your email/password.  If the site gets decent traction, I’ll look into using the “Sign into Twitter” APIs, which will give me more control over it.
• Yes, I know, I need a designer! (don’t we all?!)
• There is currently a bug – if you turn on a filter and it results in zero tweets, it will crash.  The workaround is to follow more people!
• The code is a bit messy and still fairly hack-ish, but it’s fairly easy to understand.  View the source, and let me know if you have any suggestions.

Any suggestions on features?

Any suggestions on code/architecture?

However, I also discovered that starting with PhoneGap 1.5 (release notes), a new key was added to the PhoneGap.plist (now Cordova.plist) called UIWebViewBounce.  It’s set to YES by default (I have no idea why).  If you set it to NO, your app will be anchored in with nails and the bounce removed.

This is also now configurable with PhoneGap Build by setting webviewbounce to false in your config.xml (documented here).

Last week, I tried a variation of this at a Tampa meetup with an audience of about 100 people and it worked really well.  Late  Friday night, I created Phraffle (phone + raffle = Phraffle!) — http://phraffle.com.  It’s obviously a very simple and somewhat silly app, but it was fun to build.  It was also my first use of TypeKit (font used in the logo).  The spinning effect is based on a blog post I found by Saurabh Odhyan.  He basically pans an image across a div using JQuery.spritely.  Once the speed increases, the image is switched to a blurred version.   I loved the effect so I took his example and made some modifications until I had the right look and feel.

Let me know if you have any ideas on how to improve this or if you have seen other interesting ways of handling raffles.  I might create a tiny app for phones/tablets for off-line use-cases.  It all depends on how bored I get next weekend.

• Tampa —  5/9/2012 6:00PM please RSVP on the site – if it’s full, try again later in the day
• Orlando —  5/8/2012 6:00PM EDT at Full Sail University – DONE – Had a packed room and over 35 online!

Even if you have looked at PhoneGap already, we’re going much deeper than an introduction.  We’re going to show how to build production-quality, high-performing apps using HTML and JavaScript.  This goes well beyond the typical demos.  Micro-frameworks such as backbone.js, twitter boostrap and more will be used.

The folks at Full Sail University put together a poster for the Orlando event (see below).  Now I feel like we need some sort of cool music playing when we enter the room!

To give you a sense of the activity levels, here are a few ChessJam stats:

• At any time, day or night, there is an average of 100 users logged in playing chess.  We’ve seen it as high as 180 concurrent on weekends.
• Our average load is about 2 or 3 chess moves per second.
• During the month of March, 2012, more than 4,500 users played 128,920 games (5.8 million moves in one month)

Not bad for no marketing budget I think.  It’s not a huge amount of activity compared to a lot of applications, but the performance demands are very high. Serious chess players don’t tolerate delays in response time, so we have to make sure we have plenty of CPU and bandwidth to spare.

Hosting history:

Late 2009/Early 2010 — development and early production – hosting from my home office

During development and the first few months of production, ChessJam was hosted from a computer in my home office.  The cost was around $70/month for FiOS fixed IP address plus whatever power my server was drawing. This was fine until the Florida summer storms took out my power twice in a single month. That’s when we realized the difference between a real data center and my personal data center! It was also a bit stressful when I traveled because it left my wife in charge of late-night server repairs.

Late 2010 — moved to rack mounted servers in a real data center

We acquired two used (circa 2008) rack-mounted IBM servers and rented some rack space at a local data center.  Reliable power and Internet were no longer a problem, but the hardware was ours to manage and eventually repair.  It was better, but it wasn’t a great situation. Once we settled in, our cost was around $190/month (rack space rental and bandwidth).

Why didn’t we move to Amazon EC2 instead of the data center?  We did consider moving from my home office to Amazon EC2 instead of the data center, but at the time, Amazon didn’t have an instance type that suited us.  The small instance type was affordable, but it only offers 1.7GB of memory, which just won’t cut it for our server app (we tried). The next step up was the large instance type with 7.5GB of memory, but it was too expensive and overkill.

Two months ago, Amazon filled the huge gap between the small and large instance type by announcing the new “medium” instance type. It provides 3.75GB of memory as well as a decent amount of CPU for a good price… so we decided it was time to make the move.

Our EC2 configuration:

• Medium EBS instance running Ubuntu Linux.  EBS is “Elastic Block Store”, which basically means that the storage is persistent.  If you haven’t looked at EC2 in the past two years, you might not know that persistent storage on server instances is an now an option.  With EBS storage, you can shut down your server and all of the data is saved (just like a physical server).
• 200GB EBS disk volume – for our MySQL database and fast growing log files.

AWS and bill anxiety

Most people exploring Amazon EC2 ask the same question I asked… “What is this really going to cost me?”. When you dig into how EC2 is priced, you’ll find that there are multiple variables, which creates a bit of uncertainty. Basically, it boils down to the server instance type, the disk space used, and the amount of data moved in and out of the instance. There are other small charges for number of I/Os and any unused IP addresses, but these are typically only a few cents and don’t have much impact on the final bill (based on my experience).

• The server instance — this one is easy and predictable. Amazon charges by the hour. For example, our medium instance is $0.16 per hour. You could fire up a medium server instance and spend a full 8 hour work day playing with it and only pay about $1.30. Not bad! Our app runs 24/7 so 24 hours per day * 30 days = 720 hours per month. So, our monthly cost can be calculated with $0.16 * 720 = $115/month.  (later in this article, I explain how reserved instances work and how they can lower this price by nearly half)
• Disk volume – this one is also easy and predictable as well. It cost $0.10 per GB per month. We have a 200GB volume, so that’s 200*$0.10 = $20/month.
• Disk I/Os — The EC2 pricing page also shows a $0.10 charge per million I/Os. We do about 300,000 I/Os per day (based on my last bill) so that comes to about 9 million I/Os per month resulting in less than $1/month… so we’ll just call that a rounding error.
• Data transfer charges — this is the part that scared us. Amazon charges $0.12 per GB of data transferred out of our EC2 instance. They do not charge for inbound traffic. This method of charging for data is very different than how our data center charges us. The data center uses “95th percentile peak billing” which means we are charged based on the average rate that we move data, not the volume of data moved. I’ll spare you the details, but it doesn’t translate to Amazon’s model. However, our data center provider does have a report that shows the total amount of data transferred each month and we used that number to estimate. Now that we’ve been up and running a few days, I know that we transfer about 250MB of data every hour or 6GB of data per day. So, 6GB * 30 days * $0.12 = $21/month.

Summary: $115.20/month for our server instance, $20/month for our disk volume and $21/month for data transfer which comes to about $156.20/month. That’s already about $30 less than we were paying the data center.  That price is already lower than what we were paying… but with reserved instances, we can lower it considerably.

Saving money with reserved instances

A lot of companies use Amazon EC2 in a much more “elastic” fashion than ChessJam does.  They set up load balancers and auto-scaling to dynamically increase and decrease instances based on the load. However, our app is not nearly that sophisticated (although eventually our usage may justify re-architecting our back end!).  Our app uses a consistent amount of EC2 resources.  Thankfully, Amazon offers special pricing for this type of use-case called reserved instances. Reserved Instances give you the option to make a one-time payment for each instance you want to reserve and in turn, receive a significant discount on the hourly charge for that instance. Basically, Amazon is rewarding you for being predictable. There are three different options, light utilization, medium utilization, and heavy utilization. Our server is up and running 24/7, so our best deal is the heavy utilization model.

I reserved a medium instance for one year by paying an upfront fee of $390. Now, instead of paying $0.16 per hour, we pay $0.032 per hour (just over 3 cents!).  Some simple math shows the savings:

• With a normal “demand instance”, we paid $0.16 per hour * 24 hours per day * 365 days per year resulting in a yearly cost of $1,401.60 (plus disk, I/O, transfer)
• With the reserved instance, we paid $390 up front and then $0.032 per hour * 24 hours per day * 365 days per year resulting in a yearly cost of $670.32 (plus disk, I/O, transfer)

Bottom line cost including disk, data, etc.

• We paid around $2,280 a year to the data center.
• We now pay $1,160 a year to Amazon EC2 – saving us over $1,000 per year (not counting any hardware costs we could have incurred).

There are two smaller instance types – micro and small.  You might can get by far cheaper for your app/site.  With reserved instance pricing, you can get a micro instance for about $100 per year!  I currently host 6 low-use websites on a single micro instance (local bagel store, my aerial photo site, etc.).

TIP: If you plan to use Amazon’s micro instances, you should be aware of how they throttle CPU.  It’s unique to the micro instance type.  I blogged about this months ago.

TIP: Amazon’s billing data is updated several times per day, so you can quickly determine what your run-rate is for everything. I was able to project our monthly cost after 24 hours of activity.

We didn’t move to EC2 just to save money

Yes, we’re saving some money – that’s awesome, but to be honest, it’s not the reason we moved.   The real reason we wanted to move to a cloud solution like EC2 is for peace of mind and to prevent us from dealing with a hardware failures.  We had a backup server in the data center, but if there was a failure in the primary server, it would likely result in a 30 minute drive to the data center and a few hours in a cold room moving hard drives from server to server and hoping it all goes well.  It was a precarious situation!  Now, if there is a hardware failure (rare, but they happen on EC2), I simply launch a new instance with a few clicks of the mouse, mount our disk volume to it, tweak a few things, and get us back online.  All of this while watching Big Bang Theory in my PJs!

I know that a few of you IT-minded folks are seeing some holes in my final architecture, and yes, you’re correct. The above scheme doesn’t address a disk volume crash. Disk volume crashes are very rare on EC2, but I do plan to make a few more enhancements to the architecture. I could start up a new instance and use it as a slave server to replicate data from the primary server’s database (MySQL).  I could start this backup instance in a completely different zone, which basically means that it’s in a different physical facility.  This would allow us to quickly recover if Amazon has a massive failure like the one a year ago that brought down several popular sites for a few hours. However, I might go the cheap route and create a 2nd disk volume and use a file system that allows me to mirror the database between the two disk volumes. I think this will be adequate until someone buys us for a $1 billion.

Another option to mention is Amazon RDS (MySQL in the cloud). If we used RDS for our database, it would give us more redundancy and scalability, but for now, we’re going to avoid that cost and stay on the single instance until we grow more.

It may not be for all applications

Our experience with EC2 was very positive, especially with this application.  However, it’s not perfect for all applications.  The server is still “virtual” so the performance is not perfectly
consistent.  Things like disk I/O speed, network bandwidth, etc., is what it is.  You can’t tell Amazon that you need a SSD for your swap drive and 10,000RPM drives for your databases. In other words, you don’t have as many ways to tweak performance as you do by managing your own real hardware.  However, if your app runs well on EC2, why bother with that stuff?!  I personally feel that I’ve served my time in computer rooms during my career.

The rest of the Amazon Web Services world

Everything we’ve talked about in this article has been specific to the low-end instance types of Amazon EC2.  There are many other instance types and other related features including load balancers, auto-scaling, monitoring, automatic alerts, etc.  Also, EC2 is only one of many services offered by Amazon.  Check them all out at http://aws.amazon.com/.

Check it out for free

Amazon recently started offering a “free tier” for EC2 newbies. You basically get a year free of a micro instance along with some disk space and bandwidth. See http://aws.amazon.com/free for more details. Remember – you can resize instances anytime. It’s very common to use a micro instance during development, and then upgrade as needed when you go live.

May 2012 table of contents:

• CSS Regions and CSS Exclusions, by Deepa Subramaniam
• Drag and drop with jQuery UI on mobile devices, by Michaël Chaize
• JavaScript Object Creation, by Keith Peters
• Using Backbone with jQuery Mobile, by Christophe Coenraets
• Crafting native looking iOS apps with HTML, by Christophe Coenraets
• Demo of Handlebars, by Raymond Camden
• Real-time data exchange in HTML5, by Ryan Stewart
• Swipe to delete items, by Michaël Chaize
• App-UI, a library by Andrew Trice
• HTML5 Multimedia components, by Ian Devlin
• Interview of Pamela Fox
• Colour Match, Cutest Paw, Bit Timer: showcase
• Which Element ? Pull quotes, comments
• PhoneGap and the File API
• WTFJS: False advertising
• Generate color palettes from HTML5 video
• CSS variables draft
• News

More information at http://appliness.com/download-the-second-issue/

If you are a C++ programmer with a desire to work on a highly visible team that is having a huge impact on the future of the web, it’s time to apply!  You can go to http://adobe.com/jobs and search for the keyword “WebKit” to find the current open positions.  You can also email WebKitJobs at adobe dot com to apply.

This will be a monthly magazine with articles about writing applications using web standards. Some of the articles have interactive content and video.

All of this was done using Adobe Digital Publishing Suite (the same technology used for popular magazines such as Wired, National Geographic, and many more).

Michael Chaize was the driving force behind this and has a blog post with more details. Maile Valentine also played a huge role in the creation of Appliness – THANK YOU BOTH!