Sometimes you need a place to chat about stuff, and that's okay, because we're a community. This board is meant just for that, to talk about everything and even your kitchen sink (if you feel so inclined).
1 post • Page 1 of 1
I've always been a big fan of TV and over the years have followed a lot of TV shows. One of my favorite times of the year is May when the networks announce all the new shows and I can go through the descriptions and trailers and figure out what I do and don't want to check out come fall. Last year, an awesome service opened up called Fav.tv that was a way to "follow" shows and get a schedule of new episodes for those shows. In addition, Fav.tv had all sorts of social features to share on Facebook or Twitter or comment on the show/episode page. It really was a pretty solid service that I used constantly to keep up with my shows.
It all came crashing down when TVGuide stumbled across the service though. They viewed Fav.tv as a direct competitor and instead of making their services better, they simply went out and bought Fav.tv. Instead of keeping such an awesome service running under the TVGuide banner, they shuttered the whole thing and told Fav.tv users to go use their Watchlist feature. I was bummed to see Fav.tv go, but I figured TVGuide just re-branded it to Watchlist. They didn't. In fact, the TVGuide Watchlist feature was complete garbage when I checked it out. Not only did it have about a tenth of the features of Fav.tv, but it had an ugly interface that looked like something out of 2004.
I shut down my Watchlist and left incredibly frustrated at what had happened. It only took a few weeks for me to decide that I needed to build my own web app for tracking the TV shows I watch. Obviously I didn't need the social features since it was just for me, but the basic concept wouldn't really be that difficult, especially if I could get access to the TVRage API with show and episode information. Within a few days, I had a list of requirements for such a system and I decided it was time to branch out and build it.
First and foremost, I wanted something I could run locally that wouldn't rely on an Internet connection. Doing so would ensure speed above all else. There's nothing more frustrating than using a web app and having it load and load and load. I wanted something that I could get in, do what I needed to do, and get out. Second, I wanted to take the opportunity to use some unfamiliar technologies and tools to give me the opportunity to learn.
To start, I requested access to the TVRage API and was approved within a couple of days. I went through the steps of requesting additional permissions so I could access episode summaries as well and within a couple of weeks, had full access to the API.
When it came down to feature, it was pretty simple: follow a show, see when new episodes are airing, and maintain a queue of episodes I still need to watch. After that, everything else was icing on the cake. With a minimal list of features, I dove in.
Next up was setting up the database. Instead of just opening up the database and manually creating it though, I decided to dive in to the world of migrations and learn how the hell to actually use them. Turns out, they're pretty amazing, so much so that my foray into migrations for this project ended up convincing me that Nova 3 needed to use migrations. That alone made this project worth the effort. Simply put, migrations are a way to stand up (and tear down) database structure and data. By running a simple command from the command line, the database and all my data was set up and ready to go. (Nova 3 doesn't require the command line since Fuel offers a programmatic way to do migrations.)
With a database structure in place, now I needed data. I've used APIs before, but never anything terribly in-depth. The TVRage API is actually pretty straightforward, so being able to parse through the data was relatively easy. I used Fuel's tasks feature (PHP classes run from the command line) to go out to the API and pull back information and episodes about a given show. (A second task was written so that I could update show and episode information on a regular basis.) This was by the far the biggest pain point in the process since I wasn't familiar with the API and how it was returning data. After a handful of failed attempts, I was finally able to dump the data I wanted into a local MySQL database and now had a full set of data to play with and build out the rest of the system with.
I wasn't terribly worried about design, so I just stuck with Bootstrap's out-of-the-box styles. It did what I needed. Within a few days, I had the main pages in place and working (relatively) well. The pages I created were:
- The main page that showed me which of my shows were airing new episodes tonight.
- A page that showed me all of the shows I was following as well as when they were airing a new episode ("tonight", "tomorrow", or the number of days).
- A page that showed me all of the shows I was following as well as controls to remove the show or sync the episodes up just for that show (the sync feature was never finished in version 1).
- A page that sent a request out to the TVRage API to search for a show and show the results plus a button to add the show to my list of followed shows (or if the show was already in my list of shows, remove it).
- A page that showed me my queue, the episodes I hadn't watched yet, with a button to mark an episode as watched and remove it from the list.
There were a few more little things I wanted to do with it, but I didn't have the motivation to work on them at the time, so I just sort of started using the web app like I had Fav.tv and never looked back. I was proud of the fact that I'd done what I set out to do: build a web app to track my favorite TV shows and show me when new episodes were airing. Besides for a few bugs, version 1.0 was finished.
Honestly, I never had any intention of building a second version of the app, but the Twitterverse had other plans. I'd started to hear about a cool PHP framework called Laravel that had come on the scene about the same time as Fuel. I took a look at their site and documentation and was pretty impressed with some of the features they offered. With Nova 3 being built off of Fuel, I really wanted to find something where I could play around with Laravel and a second version of my TV tracking web app seemed like the natural place to experiment. Version 2.0 was born.
On the whole, I've been very impressed with Laravel. It's fast ... in some cases, twice as fast as Fuel. (Of course, running a web app locally is going to be really fast anyway, but still, the benchmarks were impressive.) On top of that, there was a lot of feature equality between Fuel and Laravel, but enough differences to pique my curiosity.
One of Laravel's biggest features is their routing system. In fact, version 2 of my web app doesn't use a single controller, opting instead to move all the controller functionality into routes. (Granted it isn't as organized as using controllers, but if you're looking to get something up and running quick or are using it for a relatively small system, it's fantastic.) Since this was all about pushing the boundaries of what I knew, I went with routes over controllers and utilized a lot of Laravel's built-in features (Eloquent ORM, Blade templating system, etc.) so I'd have the opportunity to understand this new framework a little more.
Fuel's built-in ORM is absolutely fantastic; it's very easy to use and incredibly powerful. I was pleasantly surprised to see that there are some remarkable similarities between Eloquent (Laravel's ORM) and Fuel's ORM. Porting my 1.0 models over was a breeze in fact; a couple find-and-replace operations and my models were ready to go. I'll give Fuel's ORM this though: relationships are much more powerful than in Eloquent. Admittedly, I was disappointed that I didn't have more control over the relationships between my models in Eloquent. In Fuel's ORM, you can specify the from model, from key, to model, to key, and whether to cascade delete and/or save ... in Eloquent, you have far less control. It wasn't a dealbreaker though since my models were pretty simple for this app.
Next up were the old controllers. Since I wanted to stretch my legs with Laravel's routing, I started by just jamming my controller code into the routes. Amazingly, very little needed to be changed to get things functional, but that wasn't the goal. I wanted to make sure I was doing things in the best way possible, so I dug in to the code and cleaned up a lot of stuff and offloaded some of the heavy lifting out of the routes and back in to the models (fat models, thin controllers). Another one of Laravel's amazing features is their RESTful routes (and controllers). Using routing, I was able to separate out GET requests (standard page requests) from POST requests to further separate functionality. It's kind of an amazing little feature that I'm already missing when I go to Fuel.
With the bulk of the app ported, I turned my attention to adding new features, fixing bugs, and cleaning things up.
- All of the connections to the TVRage API were moved into a single class, adhering to a much more DRY (Don't Repeat Yourself) approach. No more hunting through code for examples of how to connect and pull information from the API.
- Expanded the main page to display new episodes from today and tomorrow. This ended up providing a much better glance at what's going on in TV land for my shows. Additionally, the main page gained a few buttons for show information (new page), episode summary, and being able to mark a show as watched in the event I watch it live instead of watching it online later.
- One of the bugs that bothered me was the fact that if a show had multiple episodes on in one night, my app would only show the last episode airing and would display it in the show's normal time slot, even though it most likely had a different time that it aired. Again utilizing the TVRage API, the app is smart enough to know when a show has multiple episodes on and displays them in the right time slots.
- Created a new show information page that displays the show summary, when the show airs plus the network, and an episode guide for the entire series.
- The Queue gained episode summaries to make it easier to figure out what episode I watched if I was several episode back.
- A new update task was built to run several times a week so that show and episode information updates are constantly updated without any manual intervention.
- The show info page got a button to sync episodes for the show in the event the update task didn't run corrently (which given the TVRage API happens more often than I'd like).
- Overhauled the design of the app to not rely on Bootstrap's default styles. They're good styles, but can be a little bland and I wanted something to mix things up a little bit.
- Experimented with icon fonts for all of the icons in the system. I started out serving up icons from pictos.cc, which was awesome, but the IcoMoon icon font has become my go-to font. The best part is that you can store the font files locally at no extra cost, which for my purposes, was even better. While this doesn't sit on a server on the web, if it ever did, I'd want it to look as awesome on my retina display iPad as possible. Using icon fonts ensures that I wouldn't have to do extra work for graphics since its a font and is scaled appropriately for the display. As a result of this project, I've been able to move the Anodyne sites over to use icon fonts and Nova 3 will make heavy use of icon fonts as well.
- PSR-1 compliance.
- Changed all date handling to be done with the awesome Carbon date library.
This will never sit on a live web server. This will never be a service I offer for anyone to sign up for. This will never be something I release code for or anything like that. Really, this is just a playground for me to use with new tools in a real app that I use on a regular basis. The only way to learn new tools and technologies is to use them. I'd encourage people who are interested in learning PHP or Fuel or Laravel or jQuery or Bootstrap or any other type of tool/language to do something like this: pick something and build it. You'll be amazed how quickly you'll learn the tools and get more comfortable with things.
Remember that if you have projects you're working on that you want to share here, feel free to do so! If you have questions about the tools that you know people here have used, feel free to ask questions.
1 post • Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest