The miscellaneous ramblings and thoughts of Dan G. Switzer, II

Using simple conditional logic in JsRender

I've been updating some code that was built using jQuery Templates, but since jQuery Templates has been discontinued, I've decided to migrate my code to use JsRender.

The syntax is close enough for the most part that translating existing templates is straightforward enough. For the most part it's updating to the new mustache-like bracket syntax and changing variables from ${var} to {{=var}}. However, there was one thing that was tripping me up—simple conditional statements.

JsRender uses the mustache like "codeless" syntax for conditions:

{{#if varName}}output{{/if}}

This fine if varName is a truthy statement, but what if you need to check if varName  is equal to a specific value? Having gone through all the JsRender sample code, it appeared the only way to accomplish any kind of comparison conditional statement was to use custom code. This syntax ends up being very ugly and verbose. Here's an example of writing an attribute dynamically based on the value of a variable named varName :

<div class="base{{* if($view.data.varName == 'None'){ result += ' none';  } }}">{{=varName}}</div>

This seems overly complicated for such a simple comparison. I figured there had to be a better way.

After digging through the code, I found there's some undocumented features of the if tag. You can actually use the following syntax to do the same thing:

<div class="base{{#if varName eq='None')}} none{{/if}}">{{=varName}}</div>

While this syntax ends up being pretty close to jQuery Templates, it uses the "hash" functionality of JsRender's custom tags. The odd looking part is that you need the equal sign between the conditional operator and the value. Other operators include:

  • eq = equals
  • ne = not equals
  • lt = less than
  • le = less than or equal
  • gt = greater than
  • ge = greater than or equal

I actually would prefer to see "lte" and "gte" used for the "or equal" functions, so I've added that to a ticket.

So, while the syntax isn't ideal, it's certainly better than using using the code syntax. Since the project is still in development, it possible the syntax will change.

iPhone 3GS vs 4S data speed

On Friday I upgraded my iPhone 3GS to the new iPhone 4S. One of the things that's changed in the 4S is that it's supposed to support HSPA+. Well not truly "4G", it should offer faster data transfers on AT&T's network. Before heading into the AT&T store to pick up my new phone, I decided to run a couple of tests on my 3GS in my car while parked in the parking lot.

My initial tests on the 3GS reported data xfer speeds around 970Kbits/s.

Once I had my new 4S in hand, I returned to my car to repeat my performance tests. I immediately saw the numbers jump to somewhere in the 1820Kbits/s—almost double the speed.

While this was not an exhaustive test by any means, it does appear that there is a nice speed jump on AT&T's network—provided your in an area covered by HSPA+.

Here's the screenshot showing my min/max results:



Important! The Olson Time Zone Database has been shut down

There was some disturbing news yesterday—and I'm not talking about the death of Steve Jobs. The "Olson" time zone database was taken offline. While the immediate impact may not be felt, this is a very important open project and shutting it down is potentially going to cause a lot of problems.

For those that don't know, the time zone database has been maintained by a group of volunteers over the years and hosted at National Institutes for Health and contains historical, present day and known future information on day light savings changes around the world. This database is used by a huge of array of platforms to keep accurate time—Java, Unix, *nix, smart phones, etc. If you have an app that can tell you the current time in another location, there's a good bet it's based on this time zone database (either directly or via the underlying language's platform.)

Here are some good articles with more insight:

As many have already commented on, I'm not sure how this law suit can hold up since historical information can not be copyrighted. However, the law suit will have an impact—especially for applications in use by locations where the day light savings is in frequent flux.