Separate out App::IdiotBox::* DB objects and put create/update
validation logic in them.

Introducing a very barebones admin UI for managing buckets. I would
avoid using the delete action on active buckets for now as it does not
clean up videos/announcements or files on disk

Allow creating of new buckets by using the importer

Don't import files if they don't have the supportted format extension,
plus some tests for video_files_from_dir()

use Moo like the rest of the code.

Add in Data::Perl::Collection::Set from DBIx-Data-Store-old so we can run tests.

"Temporary" fix so import works again. DBIx/Data/Store/CRUD.pm no longer seems to handle inserts with special accessors

fix typo in SQL statement definition

switch FilterBuilder to short form

switch to Moo accessors in IdiotBox.pm

update for new Web::Simple

snapshot of the live db for testing

drop Method::Signatures::Simple

move to new DBIxDS code

support m4v as well as flv

clear up wording on custom HTML

make home link point to / rather than the FQDN

make bucket listing show author

fix ../ link back to bucket on video page

presenting perl skin

add importing support to idiotbox

video url handling

wrapper script for using @other_checkouts (edit to taste)

port to new zoom api

commit changes before switch to new zoom API

sort of works with store

apparently vaguely working store code

working bucket and video renders

front page rendering appears to work (given git zoom, dbixds and web-simple, anyway)

Iniitial IdiotBox.pm and script/idiotbox

Basic dispatch is in for the first bits - front page, bucket and video pages.

Not sure whether I'll try and make IdiotBox itself a Moose class or not yet.

Blocking out the structure for rendering and writing a quick bit of code to
generate a layout zoom; this is just a sketch though since Zoom will need some
updating before I can try and run it.

Rename front-page.html to front_page.html

I'm trying to maintain consistency of everything through the code, so a
show_front_page method calls render_html with a template name of front_page
and then uses a template called front_page.html. I have vague hopes that I
may be able to type less this way later, but am refusing to modify stuff as
yet since I'll only end up committing premature generalisation by accident.

Skeleton HTML files for static view interface

My intention is to use the id="main-content" as a merge point - layout.html
will be applied to the per-page HTML files.

The announcement thing is a bit clumsily worded because I really want to
avoid having to handle quant/pluralisation for the first pass - that would
raise all sorts of fascinating questions wrt using i18n stuff for _quant and
similar, and, well, blow that for a game of soliders.

Mark explained what was required for the FLV player, but (1) since I try and
avoid knowing anything about flash I had no idea what he was talking about,
(2) the first deployment will probably be on dreamhost who have their own
player and so while that's going to be all we support to begin with I'd like
to make it reasonably easy for somebody to write support for something else.

I consider this a good excuse to completely ignore it for the moment.

Fix up foreign key from videos to announcements

All videos should be attached to an announcement from the same bucket,
so make the schema enforce that. One could probably argue that this means
that bucket_slug doesn't need to exist in the videos table but in my
opinion one would be dead wrong :) - the bucket is an integral part of the
video so while it's sort of duplication, it isn't denormalisation.

Add example data

Tragically, I'm on an airplane so the examples are all my talks since I can
remember what those are called (and mdk's, since he's sat next to me ...).

SQL DDL for buckets, announcements and videos

Folded the announcement_videos table into videos since in our initial model
a video cannot exist without an announcement; we can always re-introduce
the table later if that changes