James Smith • loopj.com

What is WeGot.tv?

I’ve been working on a web app in my spare time for a while called wegot.tv, which is intended to help people track their TV viewing online. I recently joined the team at Heyzap and my focus has shifted away from wegot.tv, so I’m looking for someone to pick up the reigns and take it forward!

You can see the current state of the the site at:
http://beta.wegot.tv

Here’s my user profile, with the TV shows I like and which episodes I’ve recently watched:
http://beta.wegot.tv/users/loopj

The Grand Vision

I designed wegot.tv for people who want to get more out of their tv viewing experience. I typically watch TV that’s streamed, downloaded or purchased rather than broadcast, and tracking which episode of my shows I last watched was becoming difficult and annoying, so that’s how wegot.tv started. You can select a bunch of your favourite shows, add them to your profile, and then mark each episode as watched as you viewed them. I also wanted to know when the next episode of my favourite shows would be available to download, so I built in a customised TV schedule.

My plan was to use the collected data about viewing preferences to recommend new tv shows to users, provide streamed episodes of their favourite shows right in the site (from hulu, bbc iplayer, etc) and to provide links to iTunes, Amazon etc to purchase episodes.

There are tons of possibilities and opportunities in this space, and given more time I would have loved to build them all!

How Can You Help?

I’m looking for someone who has a similar vision, and a passion for TV, who would love to take this project on and grow it. If you want to make this into a business that would be awesome, but even as a hobby it would be great to see something I started blossom into a popular site. I’m sure there’s at least one person out there apart from me who would find this useful!

I’d transfer ownership of the project (code, domains, art etc).

Tech Details

I built the site using the django framework, TV show data is fetched (with permission) from a great site called TheTVDB, I’m using a MySQL database, and various python scripts for scraping and data collection. I own wegot.tv and wegottv.com. All of the project code is in a subversion repository.

I’m Interested, What Now?

I really want to find someone who will take this project somewhere, as it would be a shame to see this work and idea go to waste. If you think this is you, get in touch.

Hit the comments below and tell me a little about yourself and your vision for the site if you were to take it over, leave a way to contact you and I’ll be in touch!

Alternatively, send an email to wegottv at loopj.com.

Introduction

I’ve recently started work on a Rails project after working on many Django apps in the past couple of years and I’d like to share my experiences and gripes from my transition. Rather than attempting to analyze all the pros and cons of each framework, I’m going to try to focus on the transition pain points.

Python vs. Ruby (Perl’s Ugly Sister)

Python and Ruby are quite similar languages and I’m not going to compare them in any serious depth. Both have their relative merits and I find both languages easy to work in. The one complaint I have about Ruby is that it borrows far too much from Perl. I’ve done a fair bit of scripting in Perl, and most people agree with me that Perl scripts of any substantial size quickly become very difficult to maintain.

Ruby is a great language but it tries to provide similar syntax and constructs to Perl, while duct taping all of Ruby’s own powerful features on too. This makes the Ruby syntax look like someone emptied all the symbols from the keyboard into a shotgun and shot them into your face.

Another irritating habit Ruby borrowed from Perl is having multiple ways of doing the same thing when simple having one way would be fine.

Say what you will about Python’s whitespace rules, but Python code is easy to read and consistent, and generally there is a single correct way of doing things.

As I mentioned earlier though, I do like Ruby, and one of the awesome features is Ruby’s blocks. Blocks are basically Ruby’s way of implementing closures and they are extremely flexible and powerful. In Python, to do something similar you’d use lambdas or list comprehensions.

Views Versus Templates

In the Rails world, the layer which generates the final markup sent to the browser is called the View layer. In a Rails View, you can chuck as much rails code as you like in amongst your markup.

Some of the early sites I worked on many years ago were written in PHP, which had the same idea. Rails views and PHP both allow the developer to mix markup and code together in the same file. When making PHP sites, you quickly learn that this is a terrible idea and quickly becomes a maintenance nightmare. One of the best things I ever did in my PHP days was to start using a PHP templating library, such as Smarty.

By restricting the template layer to simple constructs, like Smarty and Django both do, the developer is forced to keep business logic and complex constructs separate from the markup, which makes maintaining and changing the markup in future a piece of cake.

When it comes to markup reuse, the two frameworks are quite evenly matched. Django has template inheritance, which I think is a very elegant solution to the age old problem of sharing common markup, whereas Rails solves this problem using “Layouts”. Both frameworks also support template inclusion and “partials”.

Multiple Apps in a Project

When developing web projects, there are many situations where you need to have 2 very different applications which may need to access some of the same data. In the django world, you create a project and a project may contain multiple applications. Application B can use the ORM classes defined in application A’s model layer if it so chooses.

In rails, there is no such distinction between project and application. If you want to share model layer objects between code, your best bet is to have all the code in the same application. If you wish to logically seperate your applications, you can do so by creating 2 seperate rails projects, but it is not easy (or recommended) to share the models between the 2 projects. Another option is to have a controller per logical application, but this quickly leads to huge amounts of code in each controller.

URL Routing

In Django, you design the URLs for your application using regular expressions, a skill in every programmer’s toolbox (or at least it should be). In Rails you do these mappings using Ruby. Anyone who knows how to write regular expressions can instantly write url matching/capture expressions in Django.

Schema Migration

One thing Rails used to be much better at than Django was database schema migration. This is a feature built into Rails, but Django developers used to have to write manual schema migration scripts to transition their databases. These days though, there are numerous choices for easy schema migration for Django projects, my favourite being South. This is an area where Django really had to play catch-up though, and the various stable projects which have emerged to supporting migration are indicative of the maturity of Django as a whole.

Conclusion

Django and Rails both have their strong points and are similar in many ways, but certain fundamental philosophies differ, especially the Convention vs Configuration side. They are both great frameworks, and transition issues aside I look forward to working more with Rails in the future. Let me know what you think in the comments section below!