Multitudes / Animal Collective names

Correct multitude naming per animal, in case you were wondering. Back to software-related info next post :)

A Crash of Rhinoceroses. 

A School of Fish. 

A Litter of Pups. 

A Flock of Sheep. 

A String of Ponies. 

A Harras of Horses.

A Pride of Lions.

A Herd of  Elephants. 

A Plague of Locusts. 

A Colony of Ants. 

A Covey of Quail.

A Kindle of Kittens. 

A Leap of Leopards.

A Pod of Seals. 

A Sloth of Bears. 

A Rafter of Turkeys. 

A Pace of Asses.

A Walk of Snipe.

A Gam of Whales. 

A Nest of Rabbits. 

A Gang of Elk. 

A Quiver of Cobra. 

A Dule of Doves.  

A Skulk of Foxes. 

A Dissimulation of Birds. 

A Prickle of Porcupines. 

A Peep of Chickens. 

A Band of Gorillas.

A Business of Ferrets.

A Bale of Turtles. 

A Pitying of Turtledoves. 

A Drift of Hogs. 

A Paddling of Ducks. 

A Siege of Herons. 

A Trip of Goats. 

A Charm of Finches. 

A Cete of Badgers. 

A Squadron of Pelicans. 

A Shoal of Bass. 

An Exaltation of Larks.

A Drove of Cattle. 

A Singular of Boars. 

A Tidings of Magpies. 

A Gaggle of Geese.

A Flutter of Butterflies. 

A Husk of Hares. 

An Unkindness of Ravens. 

A Labor of Moles. 

A Richness of Martens. 

A Cast of Hawks. 

A Knot of Toads. 

A Descent of Woodpeckers. 

A Sounder of Swine. 

A Mustering of Storks.

A Clutch of Eggs. 

A Bouquet of Pheasants.

An Army of Caterpillars. 

A Hover of Trout. 

A Flight of Swallows. 

A Troop of Kangaroos. 

A Clowder of Cats. 

A Watch of Nightingales. 

A Barren of Mules. 

A Shrewdness of Apes.

A Rag of Colts. 

A Bloat of Hippos.  

A Smack of Jellyfish. 

A Mischief of Mice. 

A Congregation of Alligators.  

A Parliament of Owls. 

A Route of Wolves. 

A Host of Sparrows. 

An Ostentation of Peacocks.
A Murder of Crows.

Hats off to CodeProject, Intel

CodeProject is currently holding a Windows 8 & Ultrabook App Innovation contest and I was fortunate enough to make it to the second round. It's a great contest, as all first round winners, myself included, were winners of a brand spanking new prototype model Ultrabook for development:

4Gb memory, Intel I-7(Ivy Bridge) Processor 2-2.5GHz,
160Gb HD, 5 Touchpoint Screen, Windows 8 OS.

I don't really have any technical points in this post, but I wanted to give some kudos to the folks at CodeProject as well as Intel, since I did have an issue with my screen cracking after a week or two. Since it was a free laptop, and CodeProject barely knows who I am, I was not hopeful about being able to get this issue resolved. And it's an unbranded prototype, so I wasn't really sure what manufacturer would be able to help me. Plus, it's a touch screen, so you can't just replace the glass like other laptops (even though it was still fully functional using mouse and keyboard).

But Chris at CodeProject pointed me to Premier Intel support, which came with the laptop, and they swapped it out for me as soon as I could give them a UPS tracking number. Five days later, I'm up and running on the replacement, and it's the best laptop I've ever owned. Fast, responsive, and boots to a functional Windows 8 login screen within 5 seconds. Thanks, CodeProject!

Windows 8 Store Deployment - Lessons Learned

After finally getting an app deployed to the Windows 8 Store, I wanted to share some learning experiences. I went through 2 multiple-hour sessions with the MS engineers - the first session focused more on coding and performance and uncovered the fact that the app was consuming a great deal of memory. It ended up that a few simple jQuery animations - which functioned OK in all other browsers including IE9  - went through the roof on memory consumption in IE10. So I minimized the jQuery animations and it resolved that issue, and now I am looking into revisiting it with the current version of IE10 and the RTM version of Windows 8.

The second interview dealt more with Win8/Metro standards and things like using Settings and the positioning of elements on the screen. At that point I was ready to deploy to the web store, which is a time-consuming process. I did find that having concise notes pertinent to each deployment did help speed up the turnaround time - the first submission took about 5 days to be rejected. By the time it was finally approved, I had deployed 3 times in one day, entering very specific details of the changes I was submitting.

A few things that bit me especially hard:
Certification Requirement #4.1 - Privacy Statement. If you use ANY user information, which includes accessing geolocation, you have to mention this in the privacy statement.

Also, if you have a privacy statement you must include it in your settings, AS WELL AS a link to a privacy statement HTML page in your store description.

Certification Requirement #6.2 - Age Rating. You have a clean app, right? Clean content, and you just implement the Sharing source contract so people can share text or an image from your app to Twitter, Facebook or whatever social network. Well, you'll have to make sure your age rating is 12+ for "uncontrolled sharing", or else you'll surely be rejected.

If you want to "control" sharing, you'll have to create some custom code to enable the user to "allow" other users to share from your application. So, assuming you're not targeting the 3 to 11-year-old crowd, you'll want to set your app's age rating to 12+ any time you implement the Sharing Source contract.

Responsive Design and Portability into Windows 8

One of the most common gotchas when you're trying to deploy your Windows 8 Metro* HTML app to the Windows Store, is that the application does not support SnapView. In case you're not familiar with SnapView, it is the mode where your app is "snapped" to a side window while another app is in use in the main FillView window.



There are easy ways to implement this in Windows 8, but one striking things about the width of our SnapView window is the fact that it is 320 pixels wide, which happens to be the standard screen width of many mobile devices in portrait mode.

So if we have an existing web application that is "mobile-friendly" - meaning we've used Responsive Design and CSS Media Queries to ensure it will adapt to whatever environment it is being viewed in - this HTML code is not only portable into Windows 8, it also satisfies the SnapView requirement.

That’s one of the great stories about Windows 8 HTML apps that isn’t really being played up as much as it should – the fact that portability of traditional web applications INTO a Windows 8 HTML project is fairly seamless. As a web developer, one of the things that first impressed me about Windows 8 was the ease of running a traditional HTML application within a default new Metro* HTML project. Even an app that uses jQuery or other JavaScript frameworks.

After merely adding a traditional app’s .html, .css, and .js files to a new, empty Visual Studio 2012 HTML application, the only thing that prevented it from running as a full-screen Windows 8 app was the fact that the references to the WinJS javascript files needed to be added. Once these 3 JavaScript includes were added to the page, the application was instantly running full-screen, like any other Metro* application. Here are the required .js files

<!-- WinJS references -->
<script src="//Microsoft.WinJS.1.0/js/base.js">
</script>
<script src="//Microsoft.WinJS.1.0/js/ui.js">
</script>
<script src="/js/default.js"></script>
<link href="//Microsoft.WinJS.1.0/css/ui-dark.css" 
rel="stylesheet" />

Of course, referencing these WinJS-specific files excludes the reuse of this HTML code outside of the Windows 8 environment. But the “portability in” story is still nice – I say this as a web developer who originally came across Windows 8 as part of an experiment in HTML portability.

*I'll still be using the word Metro until there's an official term for applications that target the WinRT

Deploying HTML5 Metro apps to the Windows Store...some common gotchas

After going through all the effort to build a Windows 8 Metro app before the OS is released, you'd think the hard part is behind you when development is done - what with the in-progress documentation, empty Google searches, and constantly mutating API. Now it's time to deploy to the Windows Store. How hard could that be?  Based on my own experiences, and insights from other early-bird developers, here's a look at some of the common offenses that will surely take you down the path of rejection:

1). Read the Certification Requirements. Really.
2). No items in the left and right swipe margins. No exceptions.
3). Buttons, in app functionality, credits, go down in the app bar or under Settings, not on screen.
4). Snapview - your app has to be usable when "snapped" to the 320 pixel sidebar section in Windows 8.

There are standard ways to handle the switch to Snapview in Windows 8, but for Metro HTML5/JavaScript apps you also should consider using Responsive Design,  Which I'll talk about next week.