Alpha Release


It might not look like much, but it’s got it where it counts, kid.

Scrapcal‘ is a quick Rails project to generate images for my enormous IRL wall calendar.

Take a desk calendar, separate each month
and put it on your wall for a 6×6 foot planning calendar!
Each day is the size of a sticky note and I want to add HQ photos.


Enough is working to tag this set of features as an alpha release. The purpose of this initial release was to get familiar with Rails development again, experiment with some ideas, get a proof of concept up and running, along with the whole continuous-integration deployment pipeline.

The build, test, stage and production environments are all on the same 4GB Digital Ocean instance running Ubuntu 16.04.

Major Problems

Two major issues this release created very difficult roadblocks and made development very painful. For both problems I decided it was best to bypass them than continue working through them.

GitLab CI Bundler Issues

As the build, staging and production environments are the same machine, the original intention was to use a GitLab Runner to build the Rails app and then simply move it locally to the correct deployment directory.

This intention ultimately created some considerable frustration but challenged my understanding of how the CI stack should work.

The first error was trying to attack too many new ideas at once. Through GitLab-CI I tried configuring Docker, Capistrano, rbenv and Bundler at the same time. This was especially painful as it would take several minutes for the CI to create the build; even simply syntax errors in the configuration could drag out the process. I had to wait a long time to determine my latest mistake.

Then in vain attempt to speed up the builds (to make mistakes faster), I started using GitLab-CI caching between builds. I believe this caused more problems as Bundler was not caching or building appropriately. It was painful to troubleshoot and sandbox the problems; it was simply too many ‘new’ things at once.

Removing Capistrano

While working through this, I prematurely determined I didn’t want to use Capistrano as I would ‘only be SSHing into the same machine.” Additionally, I didn’t want to use Capistrano to trigger the deployment from my local environment to the staging server. Rather, I wanted the deployment to be triggered automatically after pushing the ‘stage’ branch to GitLab.

Building and then moving the build directory seemed like the easier path and obvious path. It created more problems.

GitLab CI failing. A lot.

I configured Bundler to install locally with the –deployment flag, and every gem installed to the local vendor/bundler directory with no issue. However, when the entire build was moved to the deployment directory, rake could not find the necessary gems.

Ultimately, I think the problem was related to rbenv binstubs, but I could never confirm that was the issue.

After moving directories from build to staging, Bundler can’t find the right gems. Note this is on a SUCCESSFUL build in CI

Reinstalling Capistrano

After more research I decided to leverage Capistrano again. I set up the deploy user on the box, along with the appropriate private keys. It seemed silly to SSH directly into the same box I’m already on, but I realized it was a better process for a number of reasons.

  1. It will just work
    1. Moving directories simply was causing too many problems.
    2. Using Capistrano will allow me to move forward
  2. I get classic Capistrano functionality by deploying from local to external environments
    1. This will take away having to depend on GitLab CI
    2. Will also give me more experience with Capistrano scripts
  3. The project is ready for separate build/deployment servers in the future.
    1. They are the same box right now, but I’ll just need to change the server creds and it should work immediately.
  4. Become a better script writer
    1. For my WordPress deployment scripts I am borrowing a lot of the Capistrano ideas, like release directories and linked shared resources.
    2. However, I can’t recreate all of Capistrano and for Rails it would be best to leverage the de facto deployment tool.
    3. Long term, I’ll learn some Capistrano idiosyncrasies, and it should make me a better Bash scripter.

Using ‘Print’ as a model

The second major problem involved writing to the database with ActiveRecord. The summary of the issue is here.

A user should be able upload many ‘Photos,’ then collect those ‘Photos’ into ‘Groups,’ and then collect those ‘Groups’ into ‘Projects.’

The ‘Group’ is a 4×6 inch printed photo with two smaller square ‘Photos’ on it. At first I was calling the ‘Group’ a ‘Print’ and for some reason I couldn’t write to the database. I narrowed down the issue, but I couldn’t find exactly what the problem was. Ultimately I think the issue was using the name ‘Print’ as the class name.

Ultimately I refactored all references of ‘Print’ to ‘Proof,’ as in a Contact Print, and everything is working as expected.

‘Prints’ is now ‘Proofs’

Alpha Release Features

For this this initial release a user can perform the bare minimum of tasks:

  1. Login and Logout
  2. Upload Photos
  3. Create a ‘Project’
  4. Generate ‘Proofs’ on the Project
  5. Download an archived zip of the Project Proofs.

All of these actions are currently very tedious as you have to perform many of them, like uploading Photos, one at a time.

Click on the images below to see the full size gifs animate

Feature 00. Users can login and logout with Devise Authentication

This was my first time working with Devise so it was the first thing I installed.

I kept it simple. No user registration for now.

Gems: Devise

Feature 01. Users can upload Images to Photos

A ‘Photo’ is a model defined with a title:string and caption:text, but neither of those are necessary.

However, a ‘Photo’ must have an ‘Image’ reference to exist. When uploaded, Carrierwave creates these sizes:

  • 150px Thumb
  • 500px Medium
  • 880px x 825px ‘Proof’ image (equivalent to 2.9375″ x 2.75″, the size of a day square on the wall calendar)

The Photo also stores the Date from when the Image was taken, based on Exif data. This is automatically set on upload, but can also be edited in the UI

Gems: Carrierwave, RMagick, Exifr

Feature 02. Users can edit and destroy photos

Feature 03. Users can create Projects

Feature 04. Users can edit and destroy Projects

Feature 05. Users can generate ‘Proofs’

This feature was the most fun to develop. It also caused the most headaches with the ‘Print’ class problem written above.

I created a special PATCH/PUT route to handle the request, with an addition form and a ‘Generate all Proofs’ button.

When the button is clicked, Rails grabs all the photos and creates pairs them up, compositing them together with RMagick.

Learning RMagick compositing was a lot of fun, and I look forward to more photo manipulation in the future functionality.

A ‘Proof’ record is created for each pair and then attached to the Project.

The Projects#show view with all the generated Proofs
Two ‘Photos’ composited with RMagick into one 4×6″ ‘Proof’ image.

Feature 06. Users can download archive

This was perhaps the biggest win of the development process.

Once all the ‘Proofs’ are generated, the User can download a zip of all the 4×6 images for that Project.

There is a custom route and controller to handle the zipping and send_file. I have to work out errors and trashing the zip after a certain length of time. Currently it just sits in the public/tmp folder indefinitely.

Gems: Rubyzip

Bonus Feature 07: Calendar View

I forgot to mention that the default view is a monthly calendar, showing all the Photos as they would appear IRL on the wall calendar.

Each empty day has a link to the ‘Add Photo’ url (though it doesn’t populate the Date from the click)

Gems: Simple Calendar

The calendar auto-populates and you can add photos on empty spaces.

Roadmap Features

For the beta, hopefully released at the end of next week, I’d like to have the set of features below. The focus will still be on initial CRUD app functionality over HTTP (no AJAX). Extra polish like CSS and JS updates will come later.

  1. Testing
    1. Implement Unit Tests for Alpha Features
    2. Implement CI for Unit Tests
  2. Authentication
    1. ‘User’ Levels
    2. New User Signups
    3. Minimum Password Validation
    4. Forgotten Password Reminder
  3. Administration
    1. ‘Admin’ Level Account
    2. /admin Screen
    3. CRUD Users
    4. Reset User Passwords
  4. Fine Tune Single CRUD Interactions
    1. If a user deletes a Photo, does that delete the image?
    2. Add new single Proofs to Projects
    3. Add pre-existing Proofs to Projects
    4. Alter the Photos used on a Proof
  5. Bulk CRUD Operations
    1. Upload Multiple Photos at Once
    2. Delete Multiple Photos at Once
    3. Add unused photos to pre-existing Projects
  6. Hashing
    1. Images in Public Folders have custom hashed filenames
  7. Image Editor
    1. Add Day Number to Photo
      1. Original should remain untouched
    2. Choose Black/White Color for Date Number

Leave a Reply

Your email address will not be published. Required fields are marked *