Review of the Boxee TV

November 4th, 2012 by bbieber No comments »

Boxee released a new product called the Boxee TV. Contrary to what some believe, this is not Boxee Box v2, this is a completely new product, targeted at a very different market — a much broader market. This is a device not for techies, but for people that are fed-up with cable tv and looking for an easy alternative to everything they love about the DVR from their cable company.

Initial Setup

Unboxing the Boxee TVThe unboxing was exciting — almost like an Apple Product targeted towards a little kid. The device is sized like a cable-converter box, like those that added digital over-the-air (OTA) signals to your old analog TV. Hookup is dead-simple, as long as your TV has an HDMI input (which means it already supports OTA HD signals, so why did you buy an external OTA HD device?). The setup instructions tell you to plug the power in first, network second, cable third, HDMI fourth etc. I thought the order was a little funny, because the device powers on automatically and plays a fancy intro, similar to the Boxee-Box startup. Wouldn’t you want users to see that as their first-impression?

Like every high-tech device that connects to the Internet, once it powers on, it wants to upgrade. The upgrade went fast and in no time I was trying to initialize my new Boxee TV device and sign in to an Internet account (required). You’re directed to boxee.tv to log in and register your device. Once thing that tripped me up — your old boxee account means nothing now. You need to create a new boxee.tv. After I blasted 5 or so username/email/password attempts across the ‘net, I noticed the small text stating that “Boxee Box users must create a new Boxee TV account.” Uh, OK. Here’s all my information, again. What is funny is that they support federation with Facebook for logging in, but they didn’t support federation with the Boxee Box accounts.

Over the Air Channels

Once you’re powered on and activated, it wants to scan for OTA channels. I hooked up the tiny antenna that is included in the box and began scanning. One surprise, the tiny antenna extends telescopically, like the rabbit-ears of old. Charming. The scanning took no time at all, which surprised me because my digital TV takes forever to scan for channels. After scanning, the UI reported something to the effect of, “Couldn’t find any channels.” Bummer. I thought, well the little antenna is cute, but useless, so I’ll hook it up to the antenna that is on my roof. Once I’d connected my roof antenna, I re-scanned, and again no-channels found. Total bummer. At this point I’m thinking I got a device with a bad tuner. Oh well, I thought, let me check out the UI and see what I can do.

After exiting the setup and channel scanning, LIVE college football immediately showed up. TADA. I was elated. It did find OTA channels, and the picture quality was in beautiful HD. I used the funky square remote and browsed what else was available. To my surprise, it picked up all the OTA channels I watch regularly. One interesting note is that the Boxee TV automatically skips the .2, .3, digital subchannels — leaving only the .1 primary channels. The reasoning is that they view the subchannels as infomercial channels, not worthy of watching. I feel mostly the same way, with the exception of our local PBS subchannel, NET 12.2, which I watch occasionally.

The Boxee TV changes channels fast. I have two TVs that we watch OTA digital TV on regularly, and neither of them change channels as fast as this device. I could flip through the channels as fast as I did when I was a kid.

On-Off, Volume

Boxee Box vs Boxee TV remotesTwo items I found odd are that there is no easy-to-find On/Off button. I suspect they want you to leave it on all the time and just turn your display (TV) off. Volume is the same. There’s no volume up/down buttons — you’ll have to control that separately. The Up/Down buttons on the remote changes channels immediately. Right/Left brings up a channel-submenu from the bottom of the screen with cover-photos of the programs currently on each channel (beautiful!). I have successfully locked it up twice. Holding down the pause button has brought me back to the home menu and stopped the live TV, and another time it simply froze the UI with a bunch of progress/loading bubbles. The reset button is on the back of the device — find it, because you’ll probably need it.

Unlimited DVR

One drawback, the Unlimited DVR is only available in select markets right now. This fact actually hints at how they’re handling the DVR. I’m guessing Boxee has placed an OTA receiver and a ton of storage in each of these markets that will record what the collective user(s) have requested, and is being broadcasted. I’m basing this on two things, you can only record OTA channels, and the UI implies that only some channels will be available for recording. This tells me that even if you receive the channel, you likely aren’t the one doing the recording and uploading your recording to some cloud storage.

When users request a recording from the cloud DVR, they’re actually streaming from the single high-quality recording that Boxee keeps on-hand, just like Netflix, but for your local OTA programming.

Does it support a local-dvr?

Maybe. The UI hints that there will be something available in the future. When you’re watching live TV and hit pause, the UI responds “pausing is not available… yet.” They obviously need to add some sort of LIVE-TV buffering for live sporting events etc. I suspect this will be through locally attached storage.

DLNA/Network Shares

Currently there’s no support for DLNA or pulling media from network shares. This is where the Boxee Box owners will be very disappointed. If you’re like me and have invested quite a bit in your media server for centralized media storage, this device is not for you (right now). There are some hints that they’ll be adding support for DLNA, but no word on when that will happen.

Sum It Up

Buy this if love your DVR, and use it to record channels you could otherwise get over-the-air, and live in the few markets where they support the no-limit DVR.

Don’t but this if you want Boxee Box 2, as you’ll be really disappointed.

 

Installing PHPUnit with Pyrus

October 3rd, 2011 by bbieber 1 comment »

I rarely use PHPUnit (I prefer phpt), but a project I’m really interested in uses it for its test suite. I also rarely use PEAR (I prefer pyrus), but PHPUnit’s only installation method is with PEAR.

So, I took the extra 5 minutes to install it using Pyrus and decided to document how to do it for a completely self-contained PHPUnit install.

First, create a directory to store phpunit:
mkdir ~/phpunit
cd ~/phpunit

With pyrus, set the bin_dir so phpunit will be installed to ~/phpunit/bin/phpunit
pyrus `pwd` set bin_dir `pwd`/bin

Next, we need to get around ez component’s stupid channel which doesn’t support HTTP properly (bug detailed here: https://github.com/pyrus/Pyrus/issues/32):
pyrus `pwd` install http://components.ez.no/get/ConsoleTools-1.6.1.tgz http://components.ez.no/get/Base-1.8.tgz pear.phpunit.de/PHPUnit

Here we just install the ez components by using the direct path to the latest releases, followed by pear.phpunit.de/PHPUnit.

Once you’ve got it installed, you should set the include_path on the bin/phpunit dir to where the files are located.

You can do this by adding the include_path to the first line of bin/phpunit:
#!/usr/bin/php -d include_path=/Users/bbieber/phpunit/php

End result, a completely localized PHPUnit install.

Fail Early

June 9th, 2011 by bbieber No comments »

The following is some thoughts I jotted down after debugging a bit of code at work. After I fixed the errors I realized it might be a good example to show other developers as to why it’s a good idea to fail early.

I think the first time I heard the ‘fail early’ mantra was from Paul M. Jones. This is not the ‘fail early, fail often’ story from Jeff Atwood, but rather a development ideal to improve readability in code. The idea is that errors should be handled immediately. Don’t delay any error handling and remove any else statements you can by throwing exceptions early.

It took me a while to realize what was wrong with this code in an application at work. I had to walk through it about 5 times with my coworker Aaron as my ‘rubber duck‘ before I saw the error. It doesn’t matter who wrote this (it was probably me), but it’s a very good example of why we should always fail early, and always throw exceptions inside if clauses instead of else clauses.

Take a look at this snippet, see if you can follow the logic, and don’t peek at the later revisions:
https://gist.github.com/1018042/d06eadca597fd779010683c12a81a896aee71a1c

Ok, so what the heck is going on here?

First we check to see if the logged in user doesn’t match the person that created the story. If that’s true, see if the user selected the ‘delete’ option. If that’s true, we check all the newsrooms to see what the status is. If the story status is NOT pending, throw an exception and tell the user they can’t delete the story. After checking all the newsrooms and we’re all good, delete the story and return the result.
ELSE, throw an exception and notify the user they can’t delete a story they didn’t create.

See the slight logic error? When I get to the last line I think, “ehhh, yeah that might be right. I remember checking for that somewhere above.” I didn’t even realize that the !== was not what we were expecting.

I read through it again and again and things sounded right, but something felt out of place. That else statement and exception throw is so far away from the IF clause I didn’t even remember what we were checking for and if we’re throwing an exception for the right thing.

OK, so we can improve the readability by throwing the exception inside the IF clause and remove the else:
https://gist.github.com/1018042/2a6f0926511ceeb1bd0de09c524d37d3a0beb97d

Better. The exception is now inside the if clause, and it’s obvious why we’re throwing the exception. It’s still a little messy though, more cleanup:

https://gist.github.com/1018042/7a7df90b6185d7a6f5222c60e3e7a395f2eeb442

Ahh, better. I’m not happy with how status is checked, but it is much easier for me to grasp what’s going on. It’s not beautiful, but now I can easily explain it to a rubber duck. :-)

Using Pyrus To Manage PEAR Installable Vendor Libs

January 8th, 2011 by bbieber 6 comments »

Many developers currently employ a technique known as ‘component based software development.’ Component based software development is a development style in which the developer has a buffet of libraries to use, and chooses components or libraries for required functionality and writes a small amount of glue to hold all these components together. When these components are easily accessible, installable, and upgradable, the development lifecycle is vastly improved. In the PHP world, this means the components are available through a PHP Extension and Application Repository (PEAR)-compatible channel, and they are installable using the PEAR installer or Pyrus. Historically, the libraries installed would be closely tied to the machine they were installed on, but with Pyrus and the PEAR2 standards this is no longer the case. I’d like to share how we manage vendor libraries in many of our projects at the University of Nebraska-Lincoln.

Typically your project might include a vendor or lib directory, which contains external libraries for your current project. In some cases this directory is outside of the current project, and stored in one location on the system, or it is included in the project directory and committed to a version control system. The advantages of committing the libraries to your repository is that every developer can get up and running quickly with just a checkout or clone, and these external dependencies can be tracked along with your own files.

Pyrus, the next generation installer from PEAR, is a self-contained .phar file that requires no complex setup. Pyrus can also create self-contained registries of installed packages, which can be committed to a repository, moved around your filesystem, or moved to other machines. This makes the Pyrus installer an ideal candidate for managing vendor libraries and external components. (Download pyrus.phar here)

Ok, back to our project, and how Pyrus can help us.

Here’s a typical application layout -
src/
data/
www/
vendor/

In the vendor directory you would place your Zend Framework files, various PEAR packages, Doctrine etc. With Pyrus, all those external components can be installed locally, and when a new upgrade is available, anyone on your team can upgrade the dependency with a one-line command and commit that to the repository. On the next svn up or pull, every developer is up to date with the latest versions. Developers have been doing this for years, but the difference is that all the libraries are easily upgraded and dependencies are handled automatically.

Here’s how to use Pyrus to install Doctrine into a vendor directory -

wget http://pear2.php.net/pyrus.phar
php pyrus.phar ./vendor set bin_dir ./vendor/bin
php pyrus.phar ./vendor install pear.doctrine-project.org/DoctrineDBAL-beta

Each command in detail:

1. Grab the latest version of Pyrus.
2. Set the bin_dir to vendor/bin so the Doctrine scripts are also included in our self-contained repository. Note: Because binaries are machine specific and need to be in system paths, scripts will be installed alongside your PHP executable, unless you specify another location.
3. Next we install the DoctrineDBAL package.

The Doctrine DBAL library is now installed in vendor/php/Doctrine. When a new version comes out, you can simply run `php pyrus.phar ./vendor upgrade doctrine/DoctrineDBAL`

Find out more at http://pear2.php.net/

SVN Switch and Relocate Everything

July 22nd, 2010 by bbieber 3 comments »

We recently had a server DNS name change that affected our main SVN repository server, and required every checkout to be svn switch –relocate ‘ed.

In Eclipse I have every project checked out in ~/workspace/ so every directory with the matching server root would need to be switched. This shell script handled all the svn switch –relocate statements for me. Replace oldservername and newservername.

for dir in `ls -1 */.svn/entries | xargs grep -H -l oldservername | grep -E -o "^[^\/]+"`; do
svn switch --relocate `svn info $dir | grep ^Repository\ Root | cut -f 3 -d ' '` `svn info $dir | grep ^Repository\ Root | cut -f 3 -d ' ' | sed 's/oldservername/newservername/'` $dir
done

It may be best to make a backup of your project directories, especially if you have local uncommitted changes. This script works on bash-like command lines, such as Mac OS X.

On Experience

February 15th, 2010 by bbieber No comments »

I came across an interesting quote on experience which made me think about those that disclose how long they’ve worked in a field (myself included of course). The context in which I’m thinking about this is a bit different than the author which was ‘the trades’ and apprenticeship, but, food for thought nonetheless. :-)

“When the Union Delegates called upon me to insist that none but men who had seven years’ apprenticeship should be employed in the works, I told them that I preferred employing a man who had acquired the requisite mechanical skill in two years rather than another who was so stupid as to require seven years’ teaching. The delegates regarded this statement as preposterous and heretical. In fact, it was high treason. But in the long run we carried our point.”

James Nasmyth: Engineer; an autobiography by James Nasmyth

A New PEAR Channel Frontend

December 21st, 2009 by bbieber No comments »

It seems like PEAR2 has been brewing forever. I mean, we’ve been talking about PEAR2, namespace usage, and a brand new installer for a long time. But, now that PHP 5.3.0 is a reality and 5.3.1 is so close out the door – things are actually taking shape and getting to the point where not only can we show you what we’ve been working on, but you can actually try things out for yourself.

What I’ve been working on the past couple of days months is a new PEAR channel frontend; the basis for the PEAR2 website. I wanted a simple PEAR channel frontend, that just looks at the local filesystem for all the channel info, and would display the basics: what packages are available, categories, releases etc. Basically, just a simple web view that would not need a database backend, or any complex installation.

It would be simple to create a standalone library that just parsed xml files and read out the data, but having each underlying piece a reusable component would be very beneficial.

  • a simpler XML library for parsing files
  • an HTTP request library
  • a library to talk to PEAR channels
  • a simple templating system with php as the template language
  • html/css templates to present the content in

So when you consider the all the pieces that are required, this is quite an undertaking.

Implementation:

Ordinarily the pear installer, or pyrus, communicates to a PEAR channel through the xml files that describe the packages available. What we’ve done, is used the installer as the backbone for channel discovery and information retrieval, and we’ve told it to look at the local filesystem instead of at a remote channel. This is done using a “filesystem” adapter for the PEAR2_HTTP_Request package, which turns your local filesystem into a fake Internet. This is a fairly simple concept, that makes for a very simple PEAR channel frontend.

So, if you couple that model for data retrieval with a completely new PHP 5.3+ template system with roots in Savant, we’ve got a really nifty base for building pear channel websites.

So! The package is in the pear2 sandbox and is titled PEAR2_SimpleChannelFrontend as a companion to the PEAR2_SimpleChannelServer which makes channel creation (with categories!) a breeze.

I’ve added it to my local PEAR channel by simply dropping the .phar file in the web root as index.php, add a small .htaccess file and that’s all that is needed. Check it out at http://pear.saltybeagle.com/

As of tonight you can try it out for yourself by grabbing the PEAR2_SimpleChannelFrontend-0.1.0.phar off of the PEAR2 website and saving it along side your channel.xml and browsing to the phar file. I named it index.php for simplicity, and placed the following .htaccess file in place:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . index.php [L]
</IfModule>

Also, my thanks to Amir for the coding help with SimpleChannelFrontend, and the pear2 site. Things are moving along quite nicely.

PHP Template Wars – A New Hope

November 6th, 2009 by bbieber 2 comments »

Templating has been a recent issue up for debate in the PHP community, which is why I think it’s time to share what we’ve been up to with PEAR2 and Savant.

Savant is the foundation of the top PHP-based templating systems. In particular Solar View and Zend Framework’s View have roots in Savant and the great work of Paul M. Jones. Each of these are very successful templating systems, and they make for a proven foundation for templating and ease of use. So now that PEAR2 is gathering energy, and needs a strong templating system, Savant makes a good fit. But, with PEAR2, we have a lot of new features available with PHP 5.3, which means we can re-think some aspects of templating.

First, I want to talk about template/view annoyances, then about how Savant has solved these issues in PEAR2_Templates_Savant.

Annoyances:

1.) assigning data to the view

This is a problematic issue. Either you manually assign all of the data to the view, or choose individual pieces of data. Assigning individual pieces takes too much time and can lead to missing data in the view if new fields are added to a model and not assigned, or mismatched variable names. Data assignment is also difficult when the model uses magic methods or iterators for data retrieval.

2.) view selection

If you’re a sane person you probably have a pretty strong map between your models and views. Meaning, for the BaseballPlayer model, you’re probably going to be using a BaseballPlayer[.tpl.php|.phtml] file. This model to view mapping should be logical and happen automatically.

3.) isolation/sandboxing view data and template system

The data used within the view should be isolated from the templating system. The contextual data should not interfere with the templating system and vice-versa. Protected/private methods in the template system should not be callable within the template.

4.) view system setup

You should only have to set up your view system once per application, not per template.

5.) controller and flow logic in templates

It’s easier to maintain one template file for the site rather than separate sandwich templates pieces for the header and footer. The sandwich template method can lead to out of sync HTML tags, but it is difficult to use one template for the site without introducing controller logic into this view.

6.) data escaping

Sometimes this is necessary, sometimes it isn’t. Should the developer handle this or the designer? Does it matter? Flexibility should be allowed for either, and if we want data to be escaped it should happen automatically while still allowing access to un-escaped data if I know what I’m doing.

PEAR2_Templates_Savant – A New Hope

First, I want to talk about the concept of partial templates. If you’ve used the partial helper within Zend View or Solar View, you know how beneficial this can be. Partials are a simple way to break up large templates into smaller templates. This makes for a very object-oriented template usage, which matches many MVC applications, and also aids in data isolation and limiting variable scope. This is the default method of rendering in PEAR2_Templates_Savant.

Now the pitch.

How PEAR2_Templates_Savant fixes the annoyances above

1.) assigning data to the view

Because partials are the default method of rendering, there is no more assignment of data to the view. The data is made available to the template as the $context variable. This means instead of $view->name = $baseballplayer->name; or using $view->assign($baseballplayer);, you’ll simply use $view->render($baseballplayer, [tpl]);

This means that there is never any confusion about what data was assigned, or how to access the data from within the template. It also means that views have access to the public methods of the object rendered, which helps for objects which use getters and setters, or magic methods for data retrieval.

For those of you used to the old way, you can still pass a stdClass object with your own custom assignments.

2.) view selection

The render method accepts two parameters, contextual data and the template you wish to use. BOTH are optional arguments, but the magic happens when the template name is null.

Back to our ‘sane’ developers who know that a BaseballPlayer object should always be rendered using the BaseballPlayer.tpl.php template. They have taken the time to build a good structure for the models in their applications, and by doing so, their life is made easier by eliminating what template to select. PEAR2_Templates_Savant uses a mapper which will map objects to templates (configurable of course). The default mapper simply maps class names to template files.

BaseballPlayer => BaseballPlayer.tpl.php
BaseballCoach => BaseballCoach.tpl.php
BaseballTeam_Phillies => BaseballTeam/Phillies.tpl.php
BaseballTeam\Phillies => BaseballTeam/Phillies.tpl.php

You can assign simple replacements to apply to the class name and the file extension is also customizable for the .phtml fans out there. Of course you can provide your own template mapper which implements the MapperInterface.

ClassToTemplateMapper.php

3.) isolation/sandboxing view data and template system

This is where PHP 5.3 shines. Closures allow us to create little sandboxes for data to play in. Feel free to pass in a __config value to the view, knowing that the data won’t interfere with the view object (who would do this?) – without using nasty global variables. Also, your template system can have private/protected methods which aren’t available inside the view which makes the class easy to extend if you need to customize. Side effect, we don’t use $this-> to get to the data, we use the $context to access data given to the view, and $savant to render further partial templates. Win for data and template separation!

4.) view system setup

Because partials are used as the default rendering, the view setup happens once and is used through the entire application.

5.) controller and flow logic in templates

When used in an application which maps objects to templates, this makes it very easy to pass off data to other templates without knowing the type of data. This means there’s no more controller-ish logic within a template such as:

<html>

<body>
<?php
if ($this->mydata instanceof BaseballPlayer) echo $this->partial('baseballplayer.tpl.php', array('name', $this->mydata->name));
elseif ($this->mydata instanceof BaseballTeam) echo $this->partial('baseballteam.tpl.php', array('name', $this->mydata->name));
?>
</body>
</html>

Now, you can create one outer page template, and hand off data to another template without having to know what type of data is:

<html>

<body>
<?php echo $savant->render($context->mydata); ?>
</body>
</html>

Objects are mapped to templates, arrays are looped over, strings, ints, doubles etc are returned after they’ve passed through any escape methods you’ve assigned.

6.) data escaping

If the developer assigns methods to escape data, this happens automatically. This is handled through an ObjectProxy which handles all requests to the inner object. If you need direct/raw access to unescaped data, you can use $context->__raw(‘fieldName’);

This makes escaping easy, automatic, and avoidable if you know what you’re doing.

Teh End.

There are a few other nuances that I can share in another post, but those are the basics. Also, I want to really thank Greg Beaver who contributed many of the ideas for the latest version of Savant – including the title of this post, so thanks Greg!

So feel free to try it out and give some feedback. And so far things are shaping up nicely in the PEAR2 universe – definitely something to keep an eye on in my biased opinion.

A full example is available in the repository.

The development version of PEAR2_Templates_Savant is available through the svn repository, or installable with pyrus.

SVN:
svn checkout http://svn.php.net/repository/pear2/Templates_Savant/trunk

Browse online:

http://svn.php.net/viewvc/pear2/Templates_Savant/trunk/src/Templates/Savant/

On the (under construction) PEAR2 website:
PEAR2_Templates_Savant

Install with pyrus
php pyrus.phar /putithere install PEAR2_Templates_Savant-0.1.0

Autoloader That Installs PEAR Packages

November 4th, 2009 by bbieber No comments »

I had a thought the other night about an autoloader that could install pear packages automatically for you.

Security concerns aside, I thought this would be a fun/juvenile coding experiment, and something that could showcase how easy the pyrus api is for installing PEAR packages. So here it is, pushed out on github – http://github.com/saltybeagle/AutoloadPackage/blob/master/AutoloadPackage.php

Only 56 lines of code to have an autoloader that will install a PEAR2 package. Now if that’s not fun, I don’t know what is.

:-)

Oh, and you should really check out Pyrus, the new PEAR installer. Get it over at the pear2 website (under construction).

Blog updated.

October 25th, 2009 by admin 1 comment »

Just converted the old blog to WordPress, and now you can call me a hypocrite.