Firstly, there is barely any movie selection as of right now. But this really is not that much of a problem, because the whole thing is still in beta stadium and movies can be added very easily later on once the platform is mature enough. It is also slow, but that too is forgivable in a beta version of the app.

In my eyes the major mistake they did was - the UI. You’re expected to browse the catalogue and make selections from your TV using your remote. White at the first glance it does not seem that bad of an idea - it really does not work out. Imagine a catalogue of lets say 50.000 titles, you’re looking for something - the remote control however does not have a full keyboard, so the developers opted for an on-screen keyboard. One where a keyboard is shown on screen and you’re expected to move around with arrow keys and select letters one by one. Of course, it is pretty much the only solution when your input device is a TV remote. But it also is seriously cumbersome. Then combine that kind of UI with navigating back and forth inside search results. And once you make a selection and “rent” the movie you have to start over beginning. But I want to have much more than that. I want to bookmark search results, I want to see recommendations from my friends, I want to see newly added movies in my RSS reader and I really can’t do any of that. By now it should be obvious what I’m aiming at here.

The biggest mistake is that the authors of that particular app built their own walled off garden for themselves. A completely new application, inside a seriously limited environment (TV + remote), an enviroment, that was never designed for jobs like this. All UI and UI elements have to be invented again there are no comfortable ways to control the UI and precisely because of that this thing will never work out well.

They are not the first ones either, there are numerous examples throughout the history. Why, again, do people keep making the same mistake over and over again?

Let me describe the ideal (or at least 100x times better) VOD solution. It would be a web application, the whole catalogue should be browseable online, I could read reviews inside both the catalogue and external sites, create favourites lists, get updates on new titles through an RSS reader and really to all those fun things that are possible inside the web application.

Then, after making the choice of what I want to see, I could pay for it right away. With my credit card or bank transfer (the latter works really well here in Estonia, it’s virtually instant and very secure) and only the last step of the VOD application should be inside my TV - the one where I can see my currently “rented” movies and view them. Everything else should be built as a web application. The web app could also be linked to an online DVD store, so for example if I happen to really like a particular movie or show I could order it on DVD with just a few clicks. The possibilites are endless.

And yet people choose the path of walling themselves off from the world wide web.

• Java developers always go to eat together, in pairs, hand in hand, well organized (synchronized)
• PHP devs go at random times, some of them run, some walk, some take the elevator. (loose coding style)
• DB devs choose someone, who will then go to kitchen and fetch the food for everyone (also known as proxy)
• Delphi devs get the plate, put it in the center of kitchen, then get a fork and then walk between the food containers and plate, until plate is filled (drag ‘n drop)
• C devs kill their own animals and eat them raw (low-level)
• C++ devs prepare their food from prefabricated components in microwave oven (not that low-level)
• Frontend (HTML) devs decorate their food with cucumbers, tomatoes and generally everything else in the fridge and then play around with it until the food is cold
• Python devs always take the stairs (mandatory stepping) (from Jaagup Irve)
• Perl devs bring their own food to the work and eat it alone in the corner, while everybody else is giving them weird glances (You call THAT food? eewwwww) (syntax)

Here is the solution I came up with it:

Upside: it scans the directory structure recursively and the code is quite clean, besides maybe the pathinfo call to filter out filenames with specific extension.

Downside: it’s slow. In real life grep or some other tool is used for task like this.

Still, the code shows the power of SPL File- & DirectoryIterators nicely.

Desired result

e.g. group data by both payment method and currency.
My solution

Downside - data is accessed by numberic key, which is generally not a good thing to do. This however is just a proof of concept, in real life you probably have names for your columns.

Can you write a shorter and more elegant solution?

1. // the following code returns all lines of source.txt that contain the string Aerosmith.
2. // Feel free to extend it for your own uses
3. class FileGrep extends FilterIterator
4. {
5.     private $needle;
6.  
7.     public function __construct($file, $needle) {
8.         parent::__construct(new SplFileObject($file));
9.         $this->needle = $needle;
10.     }
11.  
12.     public function accept()
13.     {
14.         if (strpos($this->current(),$this->needle) !== false) {
15.             return true;
16.         }
17.     }
18.  
19. }
20.  
21. foreach(new FileGrep('source.txt','Aerosmith') as $line) {
22.     print $line;
23. }

1. < ?php
2. /*
3.     Goal:
4.       * Take a GPX (which is XML) file
5.       * Extract interesting records from it
6.       * Calculate the arithmetic average of latitudes and longitutes
7.      
8.     I won't tell you why exactly I needed this, just that it is part of a game
9.     called geocaching
10.  
11.     —
12.    
13.     Class is called collector, because I am _collecting_ only the records
14.     I'm interested in
15.  
16.     Example record:
17.         <wpt lat="59.4658317566" lon="24.8649997711">
18.             <name>< ![CDATA[Gtehnokratt]]></name>
19.             <url>< ![CDATA[http://www.geopeitus.ee/?p=350&c=2]]></url>
20.        
21.    
22.     Actually there is more data, but I'm only interested in lat and lon attributes
23.     and name and url elements.
24.  
25.     Records do not have any id-s, only the url has the unique identifier at the end.
26. */
27.  
28. class Collector extends FilterIterator
29. {
30.     /**
31.      * I only care about records with id's that are listed here
32.      */
33.     private $ids = array(187, 513, 537, 542, 544, 563, 605, 715, 717, 748);
34.  
35.     /**
36.      * Set up the FilterIterator by passing our SimpleXMLIterator to it
37.      */
38.     public function __construct(Iterator $it) {
39.         parent::__construct($it);
40.     }
41.  
42.     /**
43.      * Part of FilterIterator implementation, called for each record,
44.      * responsible for the decision whether the current element is needed
45.      * or not
46.      */
47.     public function accept() {
48.         $id = $this->get_id_from_url($this->current()->url);
49.         if (in_array($id,$this->ids)) {
50.             return true;
51.         }
52.         return false;
53.     }
54.      /**
55.      * Extracts record ID from string
56.      */
57.     private function get_id_from_url($url)
58.     {
59.         // http://www.geopeitus.ee/?p=350&c=514
60.         preg_match('/&c=(\d+)$/',$url,$matches);
61.         return $matches[1];
62.     }
63. }
64.  
65. /*
66.     SimpleXMLIterator is one of the standard SPL iterators, which makes it possible
67.     to use other standard iterators when parsing XML
68.  
69.     Second argument of simplexml_load_file is a class name and as result the XML
70.     in-memory representation becomes instance of that class. Seems awkward, but
71.     really useful
72. */
73. $it = simplexml_load_file('geopeitusee.gpx','SimpleXMLIterator');
74.  
75. $lat_sum = $lon_sum = $count = 0.0;
76.  
77. // so, all the data goes in, but only the elements I'm interested in, come out
78. foreach(new Collector($it) as $element) {
79.     // access subnodes with $element->name
80.     // access attributes with array notation
81.     printf("taking %s, lat=%f, lon = %f\n", $element->name,$element['lat'],$element['lon']);
82.  
83.     // typecasting is needed to get correct results from SimpleXML, otherwise you would
84.     // get integers
85.     $lat_sum += (float)$element['lat'];
86.     $lon_sum += (float)$element['lon'];
87.     $count++;
88. }
89.  
90. // finally do the math
91. printf("Average: cnt=%d lat=%s, lon=%s\n", $count, ($lat_sum / $count), $lon_sum / $count);