Blog

A message from the bears

The bears in California are smart. Not only did they figure out how to speak exceptionally articulate English, but they also commissioned this sign for the Mono Pass trailhead.

Attention Humans! A message from the bears
Attention Humans! A message from the bears
Sunset on the way into Bishop, CA
Sunset on the way into Bishop, CA

We were excited to read the explanation of what could happen if you went ahead and drove away from the pump with the nozzle in the gas tank. This has been a constant fear I’ve had since I started driving. I’m glad to hear that some gas stations have gone ahead and posted the exact cost of replacing the parts in such an event.

Changing icon font data attribute with jQuery

Icon Fonts are all the rage I guess, but they’re a little tricky to deal with when it comes to replacing one of them. Since they rely on data- element to display the icon, if you need to do any changes (such as changing an up arrow to a down arrow) you might run into a fun little issue.

Assuming you’re encoding your site in utf8 with a header tag, that data-icon tag will probably show up as a blank box character, since it’s not something that utf8 wants to agree with. Typically you just use the html special character code, such as ⇝ to display an icon font.

The problem shows up when you try and make a change to the data-icon with jQuery. If you simply try and set the $(‘#element’).attr(‘icon’,’⇝’), this breaks. The problem is that jquery passes the string in encoded in utf8, not the html entity that the data-icon element is looking to access.

To fix, you need to get the html decoded value for the html entity before setting the data-icon from jquery.

In order to get the decoded value, you can use something like this

function htmlDecode(input){
  var e = document.createElement('div');
  e.innerHTML = input;
  return e.childNodes[0].nodeValue;
}

Extending and Benchmarking Multiple Objects in PHP

Chaining Multiple Objects in PHP
I like encapsulation. Unfortunately PHP is a language that presents some interesting challenges to the classical interpretation of Object Oriented Programming.

There’s a couple things you should know about objects in PHP:

  • Objects became available in PHP in version 5. We’re still on version 5 today, even though it came out in 2004… *rolls eyes*
  • At this time, PHP Doesn’t support multiple inheritance. This means you can only chain objects together one by one.
  • Object oriented php is a little slower than procedural php, as discussed here
  • Constructors are only called on the implemented object.

The last one is a little important. If you instantiate an object, only that object’s constructor will be called by PHP. This is important when you start extending other objects that also have constructors. You’ll have errors unless you manually call the constructor of each parent with

parent::__construct();

Is it Worth It?
Some would say, no, just chuck every function that’s needed for this sort of thing into one big object. Personally, I like encapsulation. At the least, it makes functions easier to read. At the best, it keeps everything clean and organized and functioning properly while allowing reverse compatibility during future changes.

After building a few objects and changing them by simply using the extends keyword, I wanted to know if all that work I just did to encapsulate 5 different objects was actually going to be run slower by PHP than if I had left it as one big blob.

The Code

$iterations = 10000;
//--------------------------------------------------
$start = microtime(true);
class test{

public $apples;
public $oranges;
public $pares;

public function apples(){
$this->apples++;
}
public function oranges(){
$this->oranges++;
}
public function pares(){
$this->pares++;
}
}

$test = new test;
for($x=0; $x<$iterations; $x++){ $test->apples();
$test->oranges();
$test->pares();
}
$end = microtime(true) - $start;
$output .= '<hr/>Single Object Elapsed: ' . $end;
//--------------------------------------------------

//--------------------------------------------------
$start = microtime(true);
class apple{
public $apples;
public function apples(){
$this->apples++;
}
}
class orange extends apple{
public $oranges;
public function oranges(){
$this->oranges++;
}
}
class pare extends orange{
public $pares;
public function pares(){
$this->pares++;
}
}
class test2 extends pare{

}

$test2 = new test2;
for($x=0; $x<$iterations; $x++){ $test2->apples();
$test2->oranges();
$test2->pares();
}
$end = microtime(true) - $start;
$output .= '<hr/>Multiple Objects Elapsed: ' . $end;
//--------------------------------------------------

 

The Results

.

single objectmultiple objects

.

average0.028138…0.028823…

.

Trial 10.01950.0314

.

20.02120.0331

.

30.02810.011

.

40.01130.0557

.

50.02130.0312

.

60.02130.0312

.

70.02130.0476

.

80.01120.0115

.

90.04130.0113

.

100.05350.0334

.

110.01130.0113

.

120.04330.0109

.

130.01120.0113

.

140.01120.0112

.

150.03130.0338

.

160.02130.0314

.

170.02750.0312

.

180.01120.0112

.

190.02110.0331

.

200.0220.0604

.

210.02110.033

.

220.04140.0312

.

230.04560.0365

.

240.06980.0546

.

250.03720.0294

.

260.05510.0215

Conclusion
Now I’m just more confused than when I started. On average, it looks like chaining objects together is marginally slower than just lumping all the functions together in one object. Although the fringe cases prove that sometimes it is much faster… and yet, sometimes much slower.

Looks like a wash to me.

Amazon’s Kindle Fire: No Ice Cream Sandwhich; Still Worth It?

Since Amazon announced their Kindle Fire Device, to be released November 5th, I’ve been wanting to pre-order it. It seemed like a no brainer at first: A tablet that runs android, for much much less than the Apple iPad.

The Amazon Silk browser stores highly used content in the cloud and pre-loads it to your device when you hit a page — In other words, it guesses what you’re going to click on next, so when you hit a webpage, the Fire is working in the background to load what you’re most likely next clicks will be, which results in a lightning fast experience for most users. Sounds great!

But upon further investigation, it turns out that what has happened is that Amaon has forked android in a totally different direction… which makes me a little concerned.

Amazon aims to release its own App Store, which will circumvent the Android Marketplace. App Programmers will now need to optimize for Apple’s App Store, the Android Marketplace, and now, Amazon’s App Store for Android… which, clearly, is not a one-to-one relationship to the Android Marketplace as I had originally assumed.

So the question becomes, is the Kindle Fire still worth it? I want access to Android Apps, but what I’m really interested in is a cheap tablet that I can use to hit Google Reader and other sites — I sit infront of a computer long enough during the day that I want a different experience when I’m casually browsing the web.

But is the Kindle Fire taking us in a different, bastardized direction?