6/13/14

Using Google BigQuery to find the temperature history for your birthday or the best day for your wedding

Want to know what the average temperature has been on your birthday for the past several years or maybe the most sunny day of the month for your wedding?

Log into google and wander over to:

https://bigquery.cloud.google.com/table/publicdata:samples.gsod

This will let you query the GSOD (weather observatory station records) thanks to google big data.

Then execute this query:

SELECT year, mean_temp, max_temperature FROM
 [publicdata:samples.gsod] where wban_number=14742 and month=X and day=YY order by year asc;

You'll have to determine the nearest wban_number for the weather station closest to you - to get this yead over to:

http://academic.udayton.edu/kissock/http/Weather/citywbanwmo.txt

And search for your city or state.

Once you are done, you'll end up with numbers than can be plotted as a trend thusly:


If anyone can find a public dB of WBAN lat/lon let me know.

have fun.

bill

5/16/14

SHA256 and classic ASP VBSCRIPT for intercom.io secure settings and others

I've recently been using intercom.io to manage my member communication and they require a secure mode to be enabled that passes a hashed value with each session.

On the back end I needed to create javascript that looked like this:


The user hash needed to be a SHA256 hash of the users email address and the unique "salt" or secret key provided by intercom.io on a user account basis.

The problem was that I'm using Vbscript/classic ASP so was having trouble sorting this out with the limited VBScript library.

The solution was found courtesy of:

/*
 * A JavaScript implementation of the Secure Hash Algorithm, SHA-256, as defined
 * in FIPS 180-2
 * Version 2.2 Copyright Angel Marin, Paul Johnston 2000 - 2009.
 * Other contributors: Greg Holt, Andrew Kepert, Ydnar, Lostinet
 * Distributed under the BSD License
 * See http://pajhome.org.uk/crypt/md5 for details.
 * Adapted into a WSC for use in classic ASP by Daniel O'Malley
 * (based on an SHA-1 example by Erik Oosterwaal)
 * for use with the Amazon Product Advertising API
 */

Basically you create a stand alone file called sha256.wsc that lives in the same directory as the function - then pass in the appropriate variables.

VBScript Function:

The contents for sha256.wsc follow at the end of the post. Good luck and happy coding

4/21/14

Black Diamond Convert Ski review - spring skiing - corn and mashed potatoes

After looking for a while for a good light weight but still kick ass ski I finally settled on a pair of BD Converts which I mounted with DynaFit bindings. I ride them with BD Factor boots and am 155 pounds 5'10".

Haven't had them in powder yet (all gone here in VT) but I have ridden them in 2" of slush on top of harder snow, and in several inches of corn/mashed potatoes and on some pretty icy hard pack.

So far I'm blown away at how versatile they have been - really easy to turn, stable at speed and super fun to turn. No appreciable chatter on hard pack and good at holding edges. So far my only worry has been how well the dynafit will release/retain as I ride them harder.

They also have a really nice feeling 'swing' weight  - enough weight to feel solid but light enough to make quick jump turns very easy.

5 stars.



3/31/14

La Sportiva Vapor Nano Review

I recently (yesterday) had a chance to demo the Nano at Smugglers' Notch Vermont during the Backcountry Demo days. Conditions were very mixed - with some mashed potatoe style powder, breakable crust, hard pack and bumps. I was using a pair of BD boots w/ a tech binding. I'm 5 10 and 155 pounds. Pretty good skier.


My standard setup is a pair of older Dynastar Legend Pro's with a Marker Duke binding. My immediate reaction to putting the Nano's on was "holy shit, these are light". Not just a little bit lighter, but light like "did these fall off my feet by mistake light". Freaky light is the only way I can put it.

First run was down some well skied main lines and I found the ski to be pretty scary at speed on hard pack. The lightness let the ski get pushed around a bit by bumps and bits of crud and I had to really control my speed to stay happy.

Next run was down a very steep mixed (some packed, some ice and some mush) chute - narrow enough to require jump and fast turns. Here the skis were both amazing and scary. The ease with which I could snap the ski around from one landing zone to the other was incredible. With some practice I think I could probably make a 4' vertical leap with these things on. Make a jump turn or quick chute kick turn was stupid easy and I found myself just jumping over obstacles that I might have side stepped over normally.

Again - the light weight was so incredibly light that I didn't feel terribly secure when work across the fall line on ice and hard pack, but the maneuverability was pretty amazing.

Last run was through a combination of fresh spring 'powder' (think sierra cement) and some breakable crust. Here the flex pattern and weight really came into play - with the tip riding up and over nicely. Tail seems stiff enough so that I could get out of the backseat pretty easily. Excellent float.

My take away was that these would be ridiculous to have on a nice powder day in the back country - really easy to skin up with and sweet through trees and pow. As an inbounds and out of bounds ski they are just too light to be trust worthy (not to mention I'd hate to break a $1,200 pair of skis skiing shit conditions).

For really steep skiing I'd again want to have a little more substance under foot.

-bill

1/21/14

Responsive web design and form fields

Love them or hate them, entry forms and form fields are a part of life. Sign up, registration, log in, purchase, update, contact us... the variety of forms we encounter online today are endless.

As the prevalence of online forms increases, so do the variety of devices people are using to view and complete online forms. From desktop devices to iPhones, iPads, Android devices and Wii browsers it is becoming increasingly important to ensure that online forms can be easily completed from any device.

I was reminded once again of the importance of multi-device testing when developing forms and form fields  last month when testing (just prior to launch...) a simple online comment submission form. The page we had developed had a fixed footer which was 'glued' to the bottom of the web page so visitors would always have access to important site links while they were browsing the site.

<screen shot 802 quits>

When testing an entry form from desktops this footer served as a nice graphical element and didn't interfere with the entry process. The problem was that when viewed on an iPad or iPhone, clicking on the text area entry element caused the entry pad to appear behind the fixed footer - rendering it impossible to complete the form. If we hadn't tested our form on an iPad we would have never discovered this bug.

After sorting out this issue (we simply modified the footer on the form page to be at the end of the page as opposed to fixed to the bottom of the window) I began searching for best practices for form field management across multiple devices. Creating a truly responsive and multi-device optimized form turns out to be quite challenging and is a topic for multiple blog posts.

For starters I want to focus on a single type of form field - date entry. Developers typically use some sort of JavaScript based date picker to 'enhance' the user experience by spawning a graphical calender on click (see example below).




The problem is that when this same code is used on a mobile device you end up seeing:


Clicking on the date field causes both the calendar graphic AND the input type pad on the iPhone to appear - rending them both unusable.

There are several possible solutions - ranging from complex to easy.

The complex and ideal solution is to take advantage of the fact that all mobile devices can now read HTML5 form field types - like date.

Creating an entry field for this example would use code something like:
<input type="date" name="pickme">
Clicking on a form field coded like this on an iPhone or iPad would cause the native date picker function to appear on the iPhone - giving you a nice input experience like this:



The problem is that not all browsers understand an entry field of type "date" so you have to allow for both HTML5 friendly browsers and those that aren't. This requires using some more Javascript wizardy and writing a function to cause either the native date picker or our fancy graphical date picker to appear depending on the device.

It turns out there is another simpler solution. We can simply add the "readonly" attribute to the example we first encountered. Adding this attribute makes the iPhone keypad stay hidden, while the graphical calendar appears.

The result is shown below:


Because I like my graphical date picker better than the native iPhone date picker, this is my preferred solution.

Next time you are using your iPad or iPhone to enter dates (hotel reservations or airline bookings are my favorite test cases) pay attention to the behavior of the date fields. You'll immediately be able to tell if the developers were thinking responsive when they put together the code.

Next topic - optimized number entry fields.

Happy coding.