The Xbox 360 has been going strong with new media offereings, more games, and better titles than all the other consoles. Now they have announced a new media controller that looks to bring more solid proof that DVR functions and TV functions are destined for the set top box from Microsoft.

The new remote seen here as DVR style buttons including “Live TV” and “Guide”. It appears to also control the basic functions of a TV with TV Power, INPUT, DISP, Mute, Ch +/-, and Vol +/-.

The remote sports a nice sleek black design as well, instead of the stark white oddly shaped predecessor.

I like the new remote, and when the TV options for Xbox hit the consumer level, I will probably drop the funds to get this new remote.

Now that I have a Spotify account I wanted to run the Spotify software on my machine. Although technically they don’t support Linux yet they have a repo for Fedora available. However I found a small problem when trying to install it on FC15, it isn’t supported, sorta.

Here is the repo file provided by Spotify:

[spotify]
name=Repository for the Spotify client
baseurl=http://repository.spotify.com/fedora/releases/$releasever/$basearch
enabled=1
metadata_expire=7d
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-spotify

When you install that repo file and try to update it automatically resolves to the baseurl

http://repository.spotify.com/fedora/releases/15/x86_64

which if you try and go to in a browser returns a 404, it doesn’t exist. This is the problem.

If you go to http://repository.spotify.com/fedora/releases/ you will see there are only options for 13 and 14, no 15 (or anything before 13).

The simple fix is this:

[spotify]
name=Repository for the Spotify client
baseurl=http://repository.spotify.com/fedora/releases/14/x86_64
enabled=1
metadata_expire=7d
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-spotify

Technically it is NOT the right version, but it does run well enough under FC15 that I am not worried, and easy enough to fix when they have a valid client.

UPDATE: Spotify for Linux will only work on paid accounts, no free trial run here, and I don’t want to worry about WINE, so I guess Spotify use will still have to wait.

I have posted on FuelPHP once before, and I think it is time I share more about it and why I have chosen it as my PHP Framework of choice.

From FuelPHP.com:

Fuel is a simple, flexible, community driven PHP 5.3 web framework based on the best ideas of other frameworks with a fresh start.

How much clearer can they get?

The Geeks Behind FuelPHP

Dan Horrigan, Phil Sturgeon, Jelmer Schreuder and Harro Verton. If those names mean nothing to you, let me shed some light.

Dan Horrigan

Coding in PHP for 10+ years Dan has contributed to projects like CodeIgniter and PyroCMS, as well as PancakeApp.

Phil Sturgeon

Another great mind behind CodeIgniter. Just look at Phil’s blog, he has done it all!

Jelmer Schreuder

Look through Jelmer’s Github and you can see he is quite experienced as well. He is also super friend in the #fuelphp channel on Freenode.

Harro Verton aka WanWizard

After a long and sordid past as a mainframer he has found roots in programming and contributes a lot of support in #fuelphp as well. He has personally helped me through some of the beginning steps of using FuelPHP.

To all the geeks involved in FuelPHP, a huge thanks!

What Make Fuel Different?

Fuel is young, under a year as of this writing, but already it has seen support and contributions from 30+ developers. The maintainers are really open to anyone committing code cause they believe that since we all use it, we all deserve to support it. Or something like that. Basically if you use it and identify a bug, and you can fix it, then they will let you.

That is probably the best thing about this young framework is the amount of involvement everyone has. Being open source and hosted on GitHub anyone can get the source, and anyone can submit a pull request for changes to the code. I have personally been watching the commits in the IRC channel and I can attest that they are sincere in saying that things are getting done. And fast!

What Make Fuel Awesome?

Gleaming from other great frameworks (and languages) Fuel has been given some great tools. Like Oil.

Oil

Oil is a utility for the CLI that allows you to Generate code, Refine (run tasks, more on this later),  Package (install, update and remove packages) and Console (test code).

Tasks

Tasks are classes that can be run through the command line or set up as a cron job. They are generally used for background processes, timed tasks and maintenance tasks. Tasks can calls models and other classes just like controllers.

Because Tasks actually use the whole framework you can write scripts using the native language of FuelPHP and all things work. All the controllers, all the helpers etc are available to the user.

Lightweight

Autoloading is fun, and useful, but you don’t want to load everything everywhere. Fuel has an extensive (and configurable) configuration to allow you to only load what you want when you want.

Docs

The documentation is a ongoing project, and no where near perfect right now, but it certainly is coming along. Don’t take that to mean it isn’t helpful, cause it absolutely is! Also you can update the docs and commit the changes to the project

ORM and Active Record or just DB

ORM has been done, and done again. FuelPHP has an ORM, or you can opt for ActiveRecord, or if you don’t like either of those you can just use good old SQL. Fuel is flexible and this is a great example of how flexible they really are.

Why Not?!

If you haven’t been sold by my simple blog post on Fuel, then perhaps you need to play with the framework yourself. You can get it from http://fuelphp.com or  from GitHub.

What’s Next?

I am working on a series of blog posts showing how to do things with FuelPHP, so keep tuned for those.

Just thought I would make a note that if you are seeing weird timezones in your FuelPHP programs that you should checkout fuel/app/config/config.php around line 72

/**
 * DateTime settings
 *
 * server_gmt_offset    in seconds the server offset from gmt timestamp when time() is used
 * default_timezone        optional, if you want to change the server's default timezone
 */
'server_gmt_offset'    => 0,
 'default_timezone'    => 'America/Denver'

I have already set these to my local timezone of  ‘America/Denver’ but you can simply comment them out and the default from your php.ini will take effect.

Code Igniter is a great framework, and has some awesome documentation for a lot of what it does, but one place it lacks is in Hooks. What are hooks, how are they used etc, it is explained but not really. So I thought since I just accomplished an awesome example of when to use Hooks in a CI project, I would share it with the world.

What are Hooks?

I’m going to let the folks at Code Igniter field this one:

CodeIgniter’s Hooks feature provides a means to tap into and modify the inner workings of the framework without hacking the core files. When CodeIgniter runs it follows a specific execution process, diagramed in the Application Flow page. There may be instances, however, where you’d like to cause some action to take place at a particular stage in the execution process. For example, you might want to run a script right before your controllers get loaded, or right after, or you might want to trigger one of your own scripts in some other location.

So to clear that up, Hooks let you change the way Code Igniter works, without changing Code Igniter.

10K ft view:

So the problem I had recently was a page that loads a CSS class only when the user selects to change the theme. However it had to be done through a link and had to set the preference in the session to be stored throughout the users session.

To accomplish that I had planned to create a simple controller action called setCssTheme and pass the theme the user had selected. The only problem was I needed to send the user back to the page they had come from, and in some cases the referrer was not being set (different browsers handle things differently).

In order to solve this last problem I had decided to set in the session the last page visited on each page load. This works great in a constructor of a particular class but what if you want to do that site wide, on every single page load like I do?

Force all your site through a single controller? I think not.

Force all your controllers to have this same piece of code? I think not.

Let’s get DRY (Don’t Repeat Yourself).

The solution I decided on was using Hooks in Code Igniter to Hook the system process and set in the session the current page I am on. In order to be able to do this I have to be able to write to the session before the headers are sent to the browser, and so I had to choose the appropriate hook point. CI gives you the follow points to hook in:

• pre_system
  Called very early during system execution. Only the benchmark and hooks class have been loaded at this point. No routing or other processes have happened.
• pre_controller
  Called immediately prior to any of your controllers being called. All base classes, routing, and security checks have been done.
• post_controller_constructor
  Called immediately after your controller is instantiated, but prior to any method calls happening.
• post_controller
  Called immediately after your controller is fully executed.
• display_override
  Overrides the _display() function, used to send the finalized page to the web browser at the end of system execution. This permits you to use your own display methodology. Note that you will need to reference the CI superobject with $this->CI =& get_instance() and then the finalized data will be available by calling $this->CI->output->get_output()
• cache_override
  Enables you to call your own function instead of the _display_cache() function in the output class. This permits you to use your own cache display mechanism.
• post_system
  Called after the final rendered page is sent to the browser, at the end of system execution after the finalized data is sent to the browser

From those you can see the logic answer is to hook the post_controller so that our controller has a chance to do it’s work, and then to hack in out changes for the session, in this case add data to it.

How To:

Time to put rubber to the road, here is what I had to do to accomplish this task:

1. Enable Hooks
2. Configure Hook
3. Write Hook

Enable Hooks:

To enable the hooks you simply edit

application/config/config.php

and find the line:

$config['enable_hooks'] = false;

and change it to:

$config['enable_hooks'] = TRUE;

Configure Hook:

Now in application/config/hooks.php you need to tell the system what file path, file, controller, method, and parameters you want to run on the hook.

$hook['post_controller'] = array(
  'filepath' => 'hooks',
  'filename' => 'SessionHelper.php',
  'class' => 'SessionHelper',
  'function' => 'setCurrentPage',
  'params' => array(),
);

Here I tell CI that when the controller is done, load hooks/SessionHelper.php and fire off SessionHelper->setCurrentPage() (more or less).

Then I created the file mentioned above as follows:

class SessionHelper extends CI_Hooks {
  public $CI;

  function __construct() {
    parent::__construct();
    $this->CI = get_instance();
  }

  function setCurrentPage(){
    $this->CI->session->set_userdata('current_page', current_url());
  }

This simply loads the current_url() into the session userdata.

Now on every final page load (redirects won’t be caught if they are in the controller) the current_url is stored in the session. So I can check values and redirect back to the current page if needed.