Wednesday, November 26, 2014

2nd Annual Fairfield County Beer Advent Calendar (2014)

Sunday November 30: Narragansett Bohemian Pilsner
Monday December 1: Heavy Seas Peg Leg Imperial Stout
Tuesday December 2:  Evil Twin Low Life
Wednesday December 3: Two Roads Road 2 Ruin Double IPA
Thursday December 4: Gasthaus & Gosebrauerei Berliner Style Weisse
Friday December 5: Otter Creek Wolaver's Oatmeal Stout
Saturday December 6: Dixie Blackened Voodoo Lager

Sunday December 7: Victory Golden Monkey
Monday December 8: Traveler Illusive Traveler Shandy
Tuesday December 9: Samuel Smith's Imperial Stout
Wednesday December 10: Kcco Black Lager
Thursday December 11: Saint Arnold Santo
Friday December 12: Rogue Hazelnut Brown Nectar
Saturday December 13: Shipyard Blue Fin Stout

Sunday December 14: Flying Dog Old Scratch Amber Lager
Monday December 15: Geary's Hampshire Special Ale
Tuesday December 16: Harpoon White Unfiltered Wheat Beer
Wednesday December 17: Thornbridge Saint Petersburg Imperial Russian Stout
Thursday December 18: Schneider Weisse Aventinus Wheat Doppelbock
Friday December 19: Ayinger Brauweisse
Saturday December 20: Two Roads Unorthodox Russian Imperial Stout

Sunday December 21: Ballast Point Sculpin IPA
Monday December 22: Maine Beer Company King Titus Porter
Tuesday December 23: North Coast Brother Thelonious
Wednesday December 24: Samuel Adams Thirteenth Hour Stout

This year with Bill Farrell!

Source: Total Wine of Norwalk, CT, Whole Foods of Fairfield, CT, and Mo's Wine & Spirits of Fairfield, CT

Tuesday, October 28, 2014

The Order of Adapters in Lawnchair

If you are using Lawnchair and you want to explicitly define the order in which adapters are used, then you must open the unminified file and make sure they appear IN REVERSE ORDER THAT YOU WANT THEM in the source.

I have no idea if this is a bug new to version 0.6.1, but you can inspect Lawnchair.adapters in your dev tools of choice to see the order and run tests to confirm they are what you expect -- and I strongly recommend you do this.

For me, I have them pasted in my Lawnchair file as window name, Web SQL (a separate download on the site), then Local Storage, which puts them in the order for actual use: Local Storage, Web SQL, then window name.

Saturday, June 7, 2014

jQuery show() and hide() Don't Seem to Work with jQuery Mobile

That's not entirely true. Chances are you're running into this type of situation.

I was trying to hide a set of ui-block-* elements in a JQM grid when the user tapped a button. On the same set of ui-block-* elements, my media query for an iPhone was setting display: block !important. When the user would tap the button the elements would animate to hide but then suddenly re-appear.

This was not a problem on an iPad or in a desktop version of Chrome. But on the iPhone (iOS 6 and 7 at least), the !important directive was winning -- was dictating the final display.

That !important directive was unnecessary in my case, so when I removed it the calls to hide() and show() began working as expected.

Quick and Dirty Forms Auth to Test Something Else

Recently I needed to test how an Application Cache would operate, if at all, when resources where protected by ASP.NET forms authentication within a ASP.NET MVC application. I didn't need a full forms auth implementation, just something quick. I've done most of this before, but had nearly forgotten the details.

The Web.config:

    <authentication mode="Forms">
      <forms loginUrl="~/Account/Login" timeout="2880">
        <credentials passwordFormat="Clear">
          <user name="admin" password="password"/>

The AccountController with the [Authorize] attribute:

        public ActionResult Login(string returnUrl)
            ViewBag.ReturnUrl = returnUrl;
            return View();

        public ActionResult Login(LoginModel model, string returnUrl)
            if (ModelState.IsValid && FormsAuthentication.Authenticate(model.UserName, model.Password))
                FormsAuthentication.SetAuthCookie(model.UserName, false);
                return RedirectToLocal(returnUrl);
            ModelState.AddModelError("", "The user name or password provided is incorrect.");

            return View(model);

        private ActionResult RedirectToLocal(string returnUrl)
            if (Url.IsLocalUrl(returnUrl))
                return Redirect(returnUrl);

            return RedirectToAction("Index", "Home");

The LoginModel class:

    public class LoginModel
        [Display(Name = "User name")]
        public string UserName { get; set; }

        [Display(Name = "Password")]
        public string Password { get; set; }

The Login.cshtml file:

@model OfflinePartial.Models.LoginModel
    ViewBag.Title = "Login";
@using (Html.BeginForm())
        @Html.LabelFor(m => m.UserName)
        @Html.TextBoxFor(m => m.UserName)
        @Html.ValidationMessageFor(m => m.UserName)
        @Html.LabelFor(m => m.Password)
        @Html.PasswordFor(m => m.Password)
        @Html.ValidationMessageFor(m => m.Password)
    <p><input type="submit" value="Log in" /></p>

Saturday, February 15, 2014

First attempt at a Web Worker for a Lunr.js index

Most of the applications I've been building lately are internal mobile web apps using jQuery Mobile and they function offline using the Application Cache plus a bit of Local Storage. The latest one also has a search requirement using some textual data even if the user is offline. I decided to give Lunr.js a try and it works great. The one problem I've had is that it takes a couple of seconds to index the 400+ reports I'm trying to handle on an iPad 2 running iOS 7. It's not awful, but every time that loading spinner hangs I squirm.

Enter Web Workers.

This seemed like a perfect opportunity to try out a Web Worker. The search page has a couple of other features, so I don't want the user to be forced to wait for indexing to complete to use the page and, of course, I don't want to lock up the UI at all. Index creation only has to happen once, and moving it off to a background thread until complete seemed to make sense. The only issue to keep in mind, and it comes into play in my scenario, is that data is copied from the main thread to the worker thread. I have noticed a bit of a UI hitch when that fires, but it's been a huge improvement.

Here's a stripped down example with comments. You will need to run this from a web server. You cannot run it using local file:// access as far as I know.


 <title>Web Worker with Lunr.js</title>


 <script type="text/javascript" src="javascript/lib/underscore-min.js"></script>
 <script type="text/javascript" src="javascript/lib/lunr.min.js"></script>
 <script type="text/javascript" src="javascript/lib/jquery-1.11.0.min.js"></script>

 <script type="text/javascript" src="javascript/SearchIndexWorker.js"></script>
 <script type="text/javascript" src="javascript/SearchMobileModule.js"></script>
 <script type="text/javascript" src="javascript/app.js"></script>


A small app.js file to bootstrap the process:

// You'll need to run this from a web server.

var app = app || {};

// I have two search modules: mobile and desktop.
app.isMobileDevice = true;

//  We'll use local data for this example. This is a small set.
//  The benefit comes when you have several hundred of these.
var data = {
    reports: [
        { 'reportId': 1, 'reportTitle': "Jane Doe visited Company ABC to review business renewal." },
        { 'reportId': 2, 'reportTitle': "John Smith visited XYZ, Inc. to review sales over lunch." }

// You'll have to decide when to init the index.
// We currently do it if the user visits the reporting section of the app.
$(function() {, $('p'));

I have two different search modules, one for desktop users which communicates with the server to retrieve the full set of data and one for mobile users which is limited to the past 6 months of data and works offline.

(function (app, $, _, lunr) {

    // Private
    var reportsPointer = [];
    var index;

    // Public
    var search = {};
    search.setIndex = function (serializedIndex) {
        // Source:
        index = lunr.Index.load(serializedIndex); 

    search.init = function (reports, $uiNotice) {
        console.log('Attempting to init the Lunr.js index.');
        // We're going to hold a pointer to the reports.
        reportsPointer = reports;

        // Create the Web Worker.
        // You may see a browser error in Chrome or Safari while testing that says:
        //   'Uncaught ReferenceError: importScripts is not defined'
        // Not sure why that happens, but it works.
        var worker = new Worker("javascript/SearchIndexWorker.js");
        // Here we're adding a listener for messages coming back from the worker to us. 
        worker.addEventListener('message', function (evt) {
            // The property has the response from the worker.
            // The Web Worker cannot modify a global, so it passes back the index for us to use.

            // We'll update the UI here for now.
            $uiNotice.html('Ready! Open the console and try something like:"Jane")');
            console.log('The Lunr.js index is ready.');
            // Memory footprint will be large with all that data copied around. This kills the worker.
        }, false);
        // Sends a message to the worker and passes it *a copy* of the data it needs. 
        // I'm sending a string to be consistent across browsers.
        worker.postMessage(JSON.stringify({ reports: reports }));

    search.query = function (query) {
        if (!query) return [];

        // We're going to keep things simple and handle all the results here.
        // Searching with Lunr.js isn't really the point here.
        var lunrResults =;
        _.each(lunrResults, function(el, idx, list) {
            $('<pre>').text(JSON.stringify(_.findWhere(reportsPointer, { reportId: parseInt(el.ref, 10) }))).appendTo('p');
    }; = || {}; = search;

}( = || {}, jQuery, _, lunr));

Finally, the Web Worker itself.

// This is the Web Worker script. No DOM, window, or document access at all.

// Import the scripts we'll need in this worker.
importScripts('lib/lunr.min.js', 'lib/underscore-min.js');

var index = lunr(function () {

var buildIndex = function (reports) {
    if (!reports || reports.length === 0) return;

    for (var i = 0; i < reports.length; i++) {
        index.add(reports[i], false); // Don't emit any Lunr events.

// This is a listener on the worker for incoming messages.
self.addEventListener('message', function (evt) {
    // has the data passed to this worker.
    var data = JSON.parse(;

    if (data.reports) {

    // Now we send a message back to the script that created this worker.

    // Memory footprint can be large with a lot of data copied around. This kills the worker.
}, false);

I hope someone else finds this useful!