Jose Diaz-Gonzalez

“I’ve got a lot of problems with you people”

A while back ¹, I stole built a simple image upload tool for our marketing team. The reason I built this was simple; I wanted to stop the marketing team from uploading large file assets to the main repository ², thereby bloating repository size. Plus they get their assets out as soon as they need them, instead of waiting for some silly dev to press the deploy button. It’s worked well enough, but has lately shown it’s age:

• Thumbnails are processed in a web request, slowing down large file uploads. We should always process any files in the background, to avoid slowing down the user’s interaction with the site.
• Thumbnails are created regardless of the file type. Uploading a large gif? Yeah that won’t work.
• Images are uploaded through rails. Since we store assets on S3, we can just as easily upload direct to S3 in javascript.
• I never built in any categorization, tagging, or user functionality. There isn’t any way for the marketing team to know who uploaded what file, nor for what purpose.
• A “file” can actually be several different assets. For instance, we frequently resize assets manually - on the client-side at the moment - for use in different media, like ads, email, or on-site ads. Having several different “uploads” made it slightly difficult to see which one someone should use for a specific purpose.
• It doesn’t have an API, meaning other teams that might want to use it to store information - such as the Android team - can’t easily write an integration like, say, CloudApp ³ but just for our internal tool.
• The site is built on an older version of rails ⁴, which I have no desire nor intention to upgrade. We also don’t really have a dedicated Rails developer, so it’s not like I can just toss the app at someone else. We do, however, have two CakePHP Core developers on staff, so at worst I can just tell Andy it’s his problem now.

Let’s try and get past this

So I’m building this new app and decided I needed a good base:

• Must have all my favorite plugins - Crud, Crud View, Upload, etc. - enabled by default.
• Should handle error tracking and logging in a sane way.
• Must be able to handle being deployed to heroku by default.
• Needs support for some method of background queueing.
• Should be open source ⁵.

Thankfully, we can use composer to customize our application skeleton. This will enable me to scaffold out my application more more quickly than I would be able to if I used the base cakephp/app composer project template.

Here is my first pass, josegonzalez/app. It’s based upon the original cakephp/app project template, with many of my requirements fulfilled. Ideally everything would be done now, but that won’t ever be the case:

• Still need to add a custom config/functions.php for utility functions I tend to use such as diebug().
• I don’t yet have a contextual logger in place. I’m considering switching to monolog and having all logging go to stdout when using the built-in cake server shell, but I’m not quite sure yet.
• I can’t yet seed an environment in dotenv, so heroku support isn’t quite complete, but I’m working on it.
• There are quite a few plugins that would be useful to have - such as muffin/footprint - but they aren’t there yet. I’ll add them as I see general use across my application.

Side note: I wrote way too many blog posts. Do you see the internal linkage up there? Incredible.

What’s next?

Now that I have a firm base for my application, I’ll need to start actually building the thing. I’m hoping there isn’t too much work, but these things tend to take forever, so we’ll see. Since I have a pretty small set of requirements, actually writing the code should be a straightforward process, but hopefully I can do this in a readable, re-usable way.

Be sure to follow along via twitter on @savant. If you’d like to subscribe to this blog, you may follow the rss feed here. Also, all posts in the series will be conveniently linked on the sidebar of every post in the Media Manager series. Until next post, meow!

---