Of Storm Chasers, Tim Samaris, El Reno tornado, Blue Waters, AWS

Every now and then, you read something that just pushes all your buttons. At breakfast this morning, I was reading an article in Nov 17 Wired magazine (because Marla cut the daily newspaper delivery which used to be my morning staple, but I digress). The article is “Into the Vortex”, sorry I couldn’t find an online link. It talks about the May 2013 tornado that killed storm chasers Tim Samaris, his son Paul, and Carl Young.  Tornado nut that I am, I remember it vividly like it was yesterday.

The article went on to talk about how a researcher had been trying to simulate tornado formation on computers for years and finally got a chance to work with the supercomputer Blue Waters at the University of Illinois. It takes that kind of power to do the computations necessary. Using soundings from a similar EF-5 tornado from 2011, he was finally able to simulate a tornado.

Continue reading

IE Compatibility settings, or just old IE?

As a follow up to yesterday’s rant on IE compatibility settings, sometimes you forget the simple things.  In this case, while processing form submits with jQuery, the code was setup to prevent default form submission with:

event.preventDefault();

…something that wasn’t available to us in earlier versions of IE.  If it had been written in a jQuery friendly way, such as

$('#myForm').submit (function(e) {
 e.preventDefault();
});

then it would have been under jQuery’s control and handled as a jQuery normalized event.

Sorry for taking my frustration out on you IE…old biases die hard.

IE Compatibility View Settings and X-UA-Compatible meta tag

I used to hate IE with a passion.  Developing web apps for it was just a major pain in the ass. And then it didn’t bother me so much and the developer tools built into the browser finally made it a tolerable environment for building things.  It also helped that all the JS frameworks figured out how to isolate us from much of the quirks involved.

With the latest project for 1 of our clients, I’m back to “I can’t wait till MS replaces this godawful P-O-S!”  While it’s not entirely fair to current-day IE, it’s because they ever allowed those terrible IE 5 – 8 days to exist that I’m currently being punished.

Continue reading

Meteor, MEAN, and LAMP oh my

For the techies out there…
Meteor

Most of you are familiar with LAMP — Linux Apache MySql PHP.
Of more recent vintage is MEAN – MongoDB Express Angular Node.

Each represents a technology stack that focuses on a set of tools to deliver web applications. Some significant difference between the 2 stacks would be:

  • LAMP is focused on Linux as an operating system for the stack, (though WAMP would certainly be another option)
  • MEAN obviates the operating system and Apache by using Node as the built in web-server stack that doesn’t care about OS
  • MEAN also does away with separate programming languages for the front-end (JavaScript) and the back-end (PHP), and uses JavaScript everywhere
  • MEAN is focused on the single page app (SPA), while LAMP development “could” be done that way, it’s more traditional heritage is associated with a multi-page approach

Certainly, there are SPA’s being developed out there on LAMP with jQuery being a leading player in dynamic page loading from the server. But that’s not really my focus here. It’s really to point out this historical bridge from the multi-page oriented LAMP stack to the SPA approach of MEAN.

So where does Meteor fit in? Meteor is the realization of the SPA toolset into a complete package. Rather than putting the parts together in the MEAN stack, Meteor’s encapsulates everything into their framework. Here are the coolest things I like about using Meteor:

  • Full Stack Reactivity — no code needed to have pages auto-update themselves as underlying data in the database changes…very nice
  • Database Everywhere — A mini-Mongo database is maintained on the client with Collections that are tailored to that user. This is an important component leading to…
  • Latency Compensation — traditionally when a data change is made by the user, they must wait for the server conversation to take place before the page is “updated” with that change. Latency compensation allows that change to appear immediately (via the “database everywhere” component), and then confirmed (or backed out) when the server conversation is completed

Continue reading