This one’s a two-fer—comprising interesting features rolling out with Rails 4.1. Though it’s a relatively minor release, there are some great details rolling through the pipeline. These guys do a great job detailing the release, so without further ado:
To that end, I’ve been focused on incorporating BackboneJS into two types of my applications: a single-page, simple flash card application, and a more robust application.
The flash card application overview is extremely simple: to create as much of a one-page application as possible. I’m planning out multiple flash cards that have questions and answers, all belonging to a set. Rails will be used primarily as an API for the whole app, existing pretty much only to help with data validation. There are plans to integrate a spaced repetition algorithm down the road, but for now I’m only interested in getting the MVP up.
The other application is … undisclosed … at this point in time, but I’m interested in applying backbone principles to the user interface much like Fitocracy has done. They have a very slick interface that feels very snappy and responsive, and after looking under the hood it appears much of that is achieved with Backbone.
Coming up on 11 weeks now, I’ve decided to attempt to increase my Github contributions. I’ve stuck to contributing at least once a day for the last 80 days, but if we’re being completely honest, a handful of those contributions were README amendments due to my not being in town. Time to refocus and make sure the contributions are meaningful, instead of just another light green square!
In my role as a developer, I’m often asked to provide analytics on current product offerings; daily, weekly, monthly, and even hourly reports that better show what kind of audience the company is attracting and maintaining. Which is all well and good—analytics can support a decision to pivot to another product offering, or drop support for an outdated and underrepresented subset of users. But I’ve noticed that some companies get so caught up in analytics, so enamoured with measuring success, that they forget why they’re in business in the first place—to provide a service to people.
I’m still here! What, after 9 weeks of weekly progress updates, did you think I was just going to stop?
This week has been a bit daunting, to say the least. I’ve decided to start moving from simple CRUD apps with limited models into a more complex app with user-controlled nested forms and complex data relationships. Because of the complexity of the app itself, I’m relying as much as possible on gems to allow me to focus on development of the architecture of the app itself. Gems such as Devise for handling user authentication and CanCanCan (a continuation of the Ryan Bates’s now-defunct CanCan gem) for easily handling authorization are great.
This app has been good for me for a couple of reasons, but I think the most important benefit to tackling a large problem is the planning it’s forced me to do. With this project, it’s not possible to add a couple of scaffolds and call it a day. I’m anticipating this app to start off pretty complex, and only grow as time goes on, so it’s important to plan models and structure from the onset. Some people use white boards to help plan their models, while others might use notecards; I’m using the latter. In addition to helping me to visualize the overall app structure, the notecards can serve as milestones of sorts—as a feature is completely implemented and tested, I can check it off the list. I find it to be a nice way to document progress and prevent scope creep in my own projects.
In the intro, I briefly mentioned user-controlled nested forms in my app. This was perhaps the hardest thing to wrap my brain around. For this feature, the Railscasts website has been great. There are railscasts dedicated to dynamic form storage via hashes in a database column, as well as ones focused on using hstore as a storage strategy (NoSQL structure within a single database column). It’s relatively early in the app’s development, but having a resource as well-documented as Railscasts makes me feel confident I’ll be able to figure out what’s needed without too much stumbling around.
In addition to everything covered in the previous three paragraphs, I’m continuing to refine my simpler app (the URL shortener). I’m designing and refining the UX, reconfiguring parts of the app to interact via Ajax so generating a short URL is a more pleasant / seemingly quicker experience.
Whew! That was a lot to go over. Luckily we’re finished—until next week!
No rest for the driven.
I recently picked up The RSpec book from The Pragmatic Bookshelf. I’m excited to jump into it; being a “wild west” developer for so many years, I’ve found it difficult to switch from a “shoot first, test later” approach. Even after following tutorials for days, I can’t seem to wrap my head around writing my own tests without referencing other apps. Which is fine… but I’d like to understand what exactly I should be testing instead of following a “put the puzzle pieces together” approach. So far, the book is very enlightening. It’s written by the author of RSpec himself, with contributions from the developer that wrote Cucumber, and proves to be enlightening stuff.
If you didn’t read yesterday’s post, my first app is live-ish! Check it out here: http://psst.fm. Note that it is completely bare bones; the main thing with hosting this app was testing out how to publish an app via Heroku and overcoming any troubles that brought. Long term goals for this app include hosting a fully functioning URL shortener with user authentication and pretty graphs for hosted link analytics. Even longer term, I plan on including an API and potential WordPress plugin to replace the JetPack plugin I’m currently using to share links across social networking sites.
This post is alternatively titled, “Why I will always hate Flash,” and details some issues I had with adding a Flash file to my asset pipeline in production.
My first non-tutorial Rails app is live! Well, technically live… Which is the best kind, if you ask me. There’s still a ton to do before it’s completely ready for production, but I’d like to touch on a hiccup I encountered when deploying the app to Heroku.
One important part of the URL shortener I’m creating is the ability to automatically copy the URL generated to the user’s clipboard. After researching the matter a bit, I decided on the same method GitHub uses for their site—ZeroClipboard. I wanted to do things cleanly, so I added a flash folder to the asset pipeline. I then made sure to add the
flash folder to my asset path:
config.assets.paths << Rails.root.join('app', 'assets', 'flash')
After following the simple example on their GitHub’s README, I got ZeroClipboard working flawlessly on my local server.
All good, right? Then came Heroku.
I knew I’d have to configure a bit more to get static assets served with Heroku; their documentation says as much. I took care to add the
rails_12factor gem into my Gemfile to make sure all assets were added, but no dice; the ZeroClipboard flash file couldn’t be found when the app started.
To troubleshoot, I fired up the Heroku bash console with
heroku run bash. I listed all public assets with
ls public/assets and … saw ZeroClipboard! Okay, the file was there, time to troubleshoot further.
Next, I fired up the Heroku rails console via
heroku run rails console. Within the production Rails console, I tried to list the helper path for ZeroClipboard:
puts helper.asset_path("ZeroClipboard.swf"). That one gave me nil, so I knew it was an issue within Rails itself and not just a missing asset.
Finally, I headed to StackOverflow to see if others had found similar issues. I found a thread where a person had problems with Heroku serving images. Among the solutions, the OP found that a combination of adding the gem
rails_12factor (I’d already added it), and making sure
config.assets.compile was set to true in production. Such an easy solution, but this proved to be the thing that made loading my Flash file load on Heroku.
Hopes that helps anybody in a similar situation!
Short “Road to Rails” update today.
This might be the longest I’ve ever stuck to a New Year’s resolution. A documented 58 days as of today. I think I pinpointed the secret to sticking with them though: you have to actually enjoy doing them! To be honest, working on Ruby on Rails has been an extremely pleasant experience; the community is great (in my experience, the MINSWAN concept is still in full effect), the language is expressive, and there are tons of resources available if you get hung up on something. I’m almost finished with my first Rails project of a URL shortener. I’ve implemented the URL generation, I’ve added simple analytics to see browser information, time, etc., and I’ll be adding user authentication and authorization next. After that I’ll clean up the front-end some, focusing on making a pleasant user experience, then we “ship”!
When I first started learning back-end web development, I didn’t really have clear projects that sprung to mind. My idea was, “I’ll pick up the skills necessary to create a social network since social networks are a thing that is popular now.” Now that I’ve been at it for a solid two months, that viewpoint has evolved into “AUTOMATE ALL THE THINGS!” Every day presents challenges that make me further realize just how pragmatic learning a language is, even if you don’t plan on “building the next Facebook”. From watermarking images to parsing a CSV and generating reports based on the data, there are tons of reasons why picking up a language would benefit your workflow in most any job.