Saturday, November 1, 2014

Acer C720 - One Year Later

Well, it's been a year and it's time for a Chromebook blog...

I gave away my C720 4GB and C720 2GB models but not because I didn't love them.  The former to a colleague and the latter as a gift.  I miss me some Chromebook!

After being without my Chromebooks for quite awhile (I was primarily using my Mac-book Pro) I decided to see if there were any new Chromebooks out there and if so, if there was a compelling reason to pick something up other than a C720.  I'll cut straight to the chase...there is no compelling reason to purchase anything except the Acer C720.

After reviewing several alternatives, including the new Acer model that uses the Intel i3 CPU, I can confidently say that the original C720 is every bit as hot "sh*t" as  I thought it was when I reviewed it back in 2013.

The fact is, unless you really feel like spending more money or need a bigger display, this Chromebook is about as big a bang as you can get for your Chromebook money.  You might want to go with the 4GB model if you typically roll with lot's of tabs open, but in practice I have not had issues with performance.

I've researched a bunch of different models (HP, Samsung, Asus), read the reviews read the specs and checked them all out at Best Buy (don't ever ask their sales people questions if you want to get the correct answers).

It can be confusing, especially when sales people give you wrong information and are generally ignorant about Chromebooks to begin with.  Bottom line is that the Haswell architecture is going to give you the best price, performance, battery life of all of the Chromebooks.  If you want to sacrifice a bit of performance for battery life (and we're talking a little more, not a lot more battery life) then the new models with the NVIDIA Tegra K1 chipset should be considered.  The new Acer 13.6" model sports the new chipset and a higher price, but might be best for those looking for a little more screen real estate and as I mentioned, increased batter life.  The other features are pretty much the same (same number of USB ports and interfaces).  The new model supports MIMO Dual-Band 2.4Ghz & 5GHz wifi.

According to the Acer specs, you'll enjoy 13 hours of battery life for their HD (1366x768) and 11 hours for the Full HD model (1920x1080).  I'd probably cut that down by 10-20% depending on how bright you like your display.  It also adds about 1/2 pound to the weight over the original C720 (2.76lbs vs 3.3lbs).

Throwing a C720 on my coffee table is a no brainer.  It's cheap and powerful and I can browse, check my email and even run SSH to do some Linux development.  As a first or second laptop it works for me.  When I travel, I'm not taking my $2k Mac-book Pro, I'm throwing my C720 in my messenger bag and heading to the airport.  One of the great comforts of this is, if I lose the Chromebook, there's nothing on it that someone can steal.  If I do lose the C720, it wasn't all that expensive in the first place.

I love me some Chromebook!

Wednesday, October 29, 2014

Redis & Bedrock

Been playing a bit with Redis, a really cool in-memory database based on keys and values.  It's a key/value database on steroids and has a lot of applicability for web applications that need to scale or just want better performance.

A Perl module is available on CPAN, appropriately named Redis.  One might therefore be tempted to do something like:

<plugin:Redis server localhost:6379>
<null $Redis.set('key', 'value')>

Great idea, however it turns out that didn't work.  Is Bedrock broken? Hmmm...let's find out.

Perl modules like Redis that utilize a large number of AUTOLOAD subroutines and do not implement an appropriate can method are not going to present a code reference when Bedrock's parser calls the module's can method...so as a recognition of this possibility the Func.pm module within Bedrock's parsing does this:

my $funcref;
$funcref = $obj->can($func);
...
if ( $funcref ) {
    @ref_v = $funcref->( $obj, @funcargs );
  }
  else {
    &log_message(
     undef,
     "$self: eval function in case implemented via AUTOLOAD\n\@ref_v = $obj->$func(\@args);"
    );

    eval '@ref_v = $obj->' . $func . '(@args);';

    if ( $@ ) {
      if ( $@ =~/TagX::Scalar/ ) {
  die "attempt to invoke possibly non-existent method ($func) on a possibly non-existent scalar\n";
      }
      else {
        die "$@\n";
      }
    }
  }

Hey, umm...what's that? @args? Shouldn't that be @funcargs? Yup....bug.  Fixed in 2.4.1-snapshot today.  Okay, so anyway...

What can we do with Bedrock and Redis?

Well, generally we can use it as a persistent storage mechanism similar to the way we use the $session object.

<null $Redis.set('foo', 'bar')>

...on one page and then...

<var $Redis.get('foo')>

...on the next...

Of course that example is like saying you can use a brick to prop open a door!  There are lot more interesting and exciting things you can do with Redis.

How about counting page hits from unique IPs?

<null $Redis.pfadd('home-page', $env.REMOTE_ADDR)>

Using Redis' HyperLogLog (requires Redis 2.8.9) facility we can add a member and let Redis keep track of counting unique hits.

<var $Redis.pfcount('home-page')>

Or resetting a counter at midnight by specifying a time value (seconds since the epoch) to the expireat function.

<sqlselect "select unix_timestamp(date_add(curdate(), interval 1 day)) exp">
<null $Redis.expireat('home-page', $exp)></sqlselect>

...and of course we can store serialized data to Redis.

<null $Redis.set('env', $env.json()>

and deserialize it later to a Bedrock object...

<null:user_env --json $Redis.get('env')>

Yup...this is cool!  ;-)

Sunday, October 19, 2014

Pretty Print JSON objects

Added --pretty as an option to the <var> tag for pretty printing JSON objects.  Changes pushed to git master.

<sink><null $header.content_type('application/json')>
<hash:foo red 1 blue 2 green 3>
</sink><var --pretty --json $foo>

...would yield

{
   "green" : "3",
   "blue" : "2",
   "red" : "1"
}

Saturday, October 18, 2014

AWS with Bedrock

I'm starting to tinker with using Amazon's web services from Bedrock pages.  Embedding AWS in Bedrock applications is not new - particularly if you are running Bedrock on an EC2 instance, RDS (hosted MySQL) or you are using Amazon's S3 object storage system.   There are other Amazon web services that are particularly useful in any web development environment, exposing these to Bedrock pages looks interesting.

Plugin Bug

Fixed a bug in the <plugin>  tag.   Class names were not being parsed correctly if there was more that 1 level to the namespace.

For example, Amazon::SNS::VerifySignature was being incorrectly parsed as Amazon::SNS which happens to be valid Perl module.

Fix pushed to master.

Saturday, October 11, 2014

Amazon SNS - Verifying Signatures

While creating a Bedrock example of using Amazon's Simple Notification Service, I was surprised to find that Googling for a Perl example of verifying the signature from an SNS notification message came up empty.  So I wrote my own...

Sunday, September 28, 2014

Custom Error Pages

The default page when Bedrock encounters errors during the parsing of a page is error.roc and is distributed with the other core Bedrock files.  The page shows the developer the error and the contents of the page with each line numbered for easy correlation to the error reported by Bedrock.
Bedrock Error Page

You can customize the error.roc page if you'd like or replace it.  You probably don't want to spill code to users in a production environment.

To specify your own custom error page, set the BEDROCK_ERROR_LOCATION variable in the tagx.xml file to the fully qualified path of your own Bedrock file.

<scalar name="BEDROCK_ERROR_LOCATION">/var/www/html/error.roc</scalar>

Bedrock exposes the $ERROR object that has several methods you can use to report the error.

$ERROR.mesg() - the error message

$ERROR.line() - the line number where the error was encountered.

$ERROR.file() - the name of the file where the error occurred.

$ERROR.view_source() - an HTML representation of the source code.

Simple Example

This example uses the $ERROR object to display the error message, location of the error, and the file that was being processed when the error occurred.

<html>
<body>
<h1>Whoops! We're sorry, our slip is showing!</h1>
<pre>
message: <var $ERROR.mesg()>
location: <var $ERROR.line()>
file: <var $ERROR.file()>
source: <var $ERROR.view_source()>
</pre>
</body>
</html>

E-Mail Me the Error

Here's an example error page that will give the user a message and send an email to the developers notifying them of an error...I'm using the $SMTP plugin distributed with Bedrock to email the error message.

<html>
<body>
<h1>Whoops! We're sorry, our slip is showing...</h1>

<i>Thanks for your patience...our staff is on it!</i>

<plugin:SMTP localhost rlauer6@comcast.net rlauer6@comcast.net>

<null $SMTP.subject('A Bedrock Error has occurred!')>
<null $SMTP.header('Content-Type', 'text/html')>

<sink $SMTP>
An error has occurred <b><var $ERROR.file()>[<var $ERROR.line()>]</b>
<hr>
<b>REMOTE_ADDR:</b> <var $env.REMOTE_ADDR>
<b>SERVER_ADDR:</b> <var $env.SERVER_ADDR>
<hr>
<pre>
File: <var $ERROR.file()>
Line: <var $ERROR.line()>

<span style="color:red;"><var $ERROR.mesg()></span>
</pre>
</sink>

</body>
</html>

...and voila!  I get an email when an error occurs.