Have you ever seen the famous message on YouTube: “This video has been removed by the user.”, but what if you’re trying to grab that video via the Zend_Gdata_YouTube?

That can happen when you’re reading the feed for a channel or a user’s list of videos. In the feed everything’s OK – once the video is uploaded it appears into the feed. After that the user removes the video and visiting the link from the feed you’ll get the message above.

Actually what happens when you try to read this “video entry” within a Zend Framework’s application. There must be some way to catch this message?

Trying to Catch

The answer is pretty simple! Zend_Gdata_YouTube’s throwing an exception and it can be easily cached. Here’s some source code:

$apiKey = 'your_api_key';
$client = new Zend_Http_Client();
$gdata = new Zend_Gdata_YouTube($client, 'my-app', null, $apiKey);
try {
       $gdata->getVideoEntry($video_id);
} catch(Zend_Gdata_App_Exception $e) {
       echo $e->getMessage();
}

The task is to read the entire Gdata from a YouTube’s channel. It may sound easy, but as you may know Gdata is based on the Atom publishing protocol, and it naturally gives you only the latest few items.

Of course Zend Framework has a large set of classes dealing with Google’s Gdata services, one of them is the Zend_Gdata_YouTube.

It gives you the power to iterate/paginate over the entire set of YouTube user’s/channel’s videos. In that example let’s assume you have a protected function doing the reading of a single portion:

protected function _process(Zend_Gdata_YouTube_VideoFeed $videoFeed)
{

    /* @var $entry Zend_Gdata_YouTube_VideoEntry */
    foreach ($videoFeed as $entry) {
        /* @var $published Zend_Gdata_App_Extension_Published */
        $published = $entry->getPublished();
        $thumbnails = $entry->getVideoThumbnails();

        // set date format
        $date = new Zend_Date($published->getText());

        // array
        $tags = $entry->getVideoTags();

        $data['title'] = $entry->getVideoTitle();
        $data['description'] = $entry->getVideoDescription();
        $data['date'] = $date->get('Y-MM-d hh:mm:ss');
        $data['thumb'] = @$thumbnails[3]['url'];
        $data['id'] = $entry->getVideoId();
        $data['flash_player'] = $entry->getFlashPlayerUrl();
        $data['tags'] = implode(',', $tags) . ', ' . $entry->getVideoCategory();
        // do whatever you want with the data
    }

}

The only thing left is to iterate over the “pages” of the feed. This can be done with getNextFeed() method.

public function readRssAction()
{
    $userId = 'some_user';
    $client = new Zend_Http_Client();
    $gdata = new Zend_Gdata_YouTube($client, 'my-app', null, $this->_apiKey);
    $videoFeed = $gdata->getUserUploads($userId);

    // save the last items
    $this->_process($videoFeed);

    try {
        while ($videoFeed = $videoFeed->getNextFeed()) {
            $this->_process($videoFeed);
        }
    } catch (Zend_Gdata_App_Exception $e) {
        echo $e->getMessage();
    }
}

You’ll get an exception when there is no more feeds to process!

To combine all this into a single controller and to complete the code here’s the entire source:

class YoutubeController extends Zend_Controller_Action
{
    protected $_apiKey = 'your_api_key_goes_here';

    protected function _process(Zend_Gdata_YouTube_VideoFeed $videoFeed)
    {

        /* @var $entry Zend_Gdata_YouTube_VideoEntry */
        foreach ($videoFeed as $entry) {
            /* @var $published Zend_Gdata_App_Extension_Published */
            $published = $entry->getPublished();
            $thumbnails = $entry->getVideoThumbnails();

            // set date format
            $date = new Zend_Date($published->getText());

            // array
            $tags = $entry->getVideoTags();

            $data['title'] = $entry->getVideoTitle();
            $data['description'] = $entry->getVideoDescription();
            $data['date'] = $date->get('Y-MM-d hh:mm:ss');
            $data['thumb'] = @$thumbnails[3]['url'];
            $data['id'] = $entry->getVideoId();
            $data['flash_player'] = $entry->getFlashPlayerUrl();
            $data['tags'] = implode(',', $tags) . ', ' . $entry->getVideoCategory();
            // do whatever you want with the data
        }
    }

    public function readRssAction()
    {
        $userId = 'some_user';
        $client = new Zend_Http_Client();
        $gdata = new Zend_Gdata_YouTube($client, 'my-app', null, $this->_apiKey);
        $videoFeed = $gdata->getUserUploads($userId);

        // save the last items
        $this->_process($videoFeed);

        try {
            while ($videoFeed = $videoFeed->getNextFeed()) {
                $this->_process($videoFeed);
            }
        } catch (Zend_Gdata_App_Exception $e) {
            echo $e->getMessage();
        }
    }
}

Note: here you’ve to substitute the API key with the one you’ve for your development.

Zend Framework gives you the possibility to interact with Gdata services, which are provided by most of the Goolge services. You can find more on the docs page of Zend_Gdata. The basic principle is that you can connect a service with you API key, given by Google. What I’m about to show you is how do connect such a service.

In theory Zend_Gdata depends on Zend_Http_Client and you’ve to connect it with an instance of this class.

// 1. setup API key
$apiKey = 'your_api_key_here';

// 2. retrieve videos via GData Atom
$client = new Zend_Http_Client();
$gdata = new Zend_Gdata_YouTube(null, 'my-app', null, $apiKey);

Note that you’ve to replace your API key in the chunk above.

Now once that you’ve connected the YouTube service you can iterate through the entries from the video feed.

$videoFeed = $gdata->getUserUploads('username');
foreach ($videoFeed as $entry) {
    echo $entry->getTitle();
}

The thing is that you can modify a bit the code above. As ZF docs says if you don’t setup a Zend_Http_Client a default with default configuration, so you can omit this and simple write:

// 1. setup API key
$apiKey = 'your_api_key_here';

// 2. retrieve videos via GData Atom
$gdata = new Zend_Gdata_YouTube(null, 'my-app', null, $apiKey);

Lately most of the web developers are talking more and more about optimization. One of the practices everybody’s supporting is to use cookie free domains for static content. First of all, what’s static content. That, in breve, are all images, JavaScripts and CSS. That’s everything that’s transmitted to the client with no change from the server at all. In a typical PHP/MySQL site everything generated on the server site is considered dynamic, while every component that’s given to the client with no change is static. That’s why they don’t need cookies in the request.

That’s what Yahoo! YSlow says:

In a short example, lets say you’ve a web page with 10 background images used by its CSS file. Here’s a good practice to combine them in one or even use base64 for them, but that’s another talk. So in that scenario you’ll send all the cookies you’ve on the site with this images, but actually they don’t profit at all from this. The question is why you should send all this data with no need? Won’t you benefit from sending it with no cookies.

As it sound logical I read some articles recently describing that the benefit from putting the static content on a non-cookie domain doesn’t pays back. OK it may be strange, however every 40 ms or whatever of page load is important, aren’t they?

Setup a Cookie Free Domain

The problem is that if you’d like to setup a cookie free domain the things are becoming a bit harder. You’ve two options:

1. Move all your static content on a different domain, where no cookies are set.
2. Move your static content on a different sub domain and set all the cookies to the www subdomain. (Here’s a bit tricky).

All this indeed a bit tricky! So let me proceed with the next topic.

Benefits from CDN

A CDN or Content Delivery Network is a term become famous with the growing web. Now big sites have servers in almost every continent and perhaps country. CDN is an abstraction of all this. The good thing is that there’s supposed to be stored static content. Think about the YouTube’s video files. Another good thing is that this domains are cookie free by default. The thing is …

Why don’t You Combine Them?

You’ll benefit from both ideas. Cookie free domains with CDN. In one side the web page will benefit from the closest location of the server and the CDN and in other side all this will come with no cookies to you. That’s really nice and most of the time people thing of CDN for only storing large scale data, such as video files, but no one says you cannot put your CSS, JavaScripts and background images there!

Yes it may sound strange, but now with the upcoming HTML5 features every browser again is playing its own game. Firefox and Opera support only OGG Theora, Chrome and Safari only MP4 and what about IE .. it doesn’t support anything. Than why should we convert to mp4 with h.264 codec?

Because everybody is playing flash

And that’s again very sad but at least the flash players are playing mp4 with this encoding, which is good because this file will be playable under most of the mobiles. And if you have a large video site to support why don’t you convert to mp4 and play it with a Flash Player and give the opportunity to play mp4 on mobile.

Only one file under the sky

Thus you gain to keep only one file – playable under every device?

YouTube and FLV

Now I wonder why YouTube have both FLV and MP4 formats?

Of course if you’d like to be perfect …

Convert every video to MP4, FLV and OGG, but that means 3 files for every video?!

If someone asks you what is the javascript in modern web developer, probably you should answer it’s almost the half of the traffic of your site and it’s almost everything when dealing with user experience.

Today’s big web apps are useless without it AJAX/JS part. Think about Facebook, Google products, Twitter, Yahoo!, Youtube.

Actually they made this a standart. The times when you used to use JavaScript as a helper language just to figure out how a drop down menu will work are far way in the past. Now JavaScript is everything in a rich web sites. With no JS they will be no rich at all! Then it comes the question how to improve sites with lots of javascript. Actually one of the main problems in the web now is that JavaScript is blocking content.

Blocked by the JavaScript

What that means at all is that until the browser receives and parses the JavaScript file/s it doesn’t process anything else, it even doesn’t load any other resources. Now you can imagine how big the problem is. When it comes to large files more than 100K the user experience will be very bad!

Optimize the web? What about optimizing JavaScript!

If the problem is so big as I described above why should we doubt about where to start with the optimization process? But of course with the JavaScript and the natural question that rises is how this can be optimized at all?

Three steps

Like me, many of you may heart of some techniques that improve javascript performance. Here are some I was able to select as important:

1. minify/compress

That’s rule number one. If everything that is a JavaScript file is processed once it arrives to the client than make it smaller and make it go faster trough the wire. Actually one technique to speed up things more is to concatenated all the files you have into one single big file. Although this will not spend you some space will reduce the HTTP requests and therefore speed up the loading process. Good tools that you can use to minify javascript files are the Yahoo’s YUI Compressor, that beside that compresses CSS and Google Closure Compiler. Both are extremely useful and by the last measurements the Google’s Compiler is even better, but it’s up to you to decide which one to pick up.

2 .write fast and smart code

You can minify everything that’s JavaScript and the code may remain slow. But why is that? That’s because the JavaScript is written in a bad way. You know there are many resources in the web describing what is a bad and what is a good practice when writing JS. Even more you can measure it by yourself if you’d like to use the Firebug’s profiler. That’s a good start to avoid bad practices.

3. improve loading – lazy loading

That’s a bit more complicated. If there’s a really big javascript file after compressing and concatenating all the JS functionality remains big. How to avoid that? Simply let’s the user to see the most important functionality and than load the entire app. Some good tutorials about lazy loading again can be found online. Don’t hesitate to search about.

Beside this really basic advices I’ll continue to write in my blog about specific techniques how to improve the JavaScript as this is one of the most interesting parts of web development by me.

And if these “big players” are going that way, don’t hesitate to follow them! HTML5 is really what we as web developers were waiting for so long and even all of the problems during its standardization process it’s really cool there will be tags like video.

What YouTube is doing today, perhaps will seem normal to everyone tomorrow. However there are some questions still with no answer, as where the flash possibility to add ads into the player is going?! But we’re about to see great things from these two sites!

Just check out these two links:

Youtube HTML5

Vimeo