02 January 2017
The more time I spend developing applications, especially as the number of projects increases, the more I find a shared subset of functionality shared among all of them. Thankfully, using base applications as templates and gems I’ve been able to keep master versions of my shared code. They fall into a few categories:
- Admin Features
- User Features
- Admin Portal
- Invite Only Sign In
- Release Notes/Admin Changelog
- Messaging/notifications to admins
Non-registered User Features
- Markdown renderable posts (blog, articles etc)
- Static (or rarely changed), top-level pages
Registered User Features
- Code Health
- Tree structures (usually part of the categories)
- Dynamic Sitemap
- RSS Feed
As I mentioned above, templates and gems are immensely helpful for getting all this up and running, but customizing and configuring all those things for dozens of apps gets tiresome. There have been multiple conversations with myself arguing pros/cons of spinning up my own fuller featured template (which looks more and more like a real CMS every few weeks) vs the existence of many CMSs. Not to mention the lumbering presence of WordPress. Which, as much as I hate working with it, does have almost every imaginable plugin.
You may ask, “What’s the point of this post?”. The point is this: To lay my thoughts out in the open. I’ve found that often, that’s the quickest way to reach a resolution on what should be done with the limited time resources offered us. Most likely in the upcoming months I’ll either discover a nearly perfect CMS solution, or end up creating my own so that future projects can be spun up even quicker, providing a better value to everyone.
19 December 2016
Even though we’re all capable of building a commenting system from scratch, sometimes public comments for an app are fine and even encouraged (such as enhancing visibility from other sites). I recently added comments to a client’s app and we decided on using Disqus, since it can be dropped in quickly, and all the commented on pages will be public. I’ve written this since the existing Disqus how to’s for Rails which showed up on a google search were outdated; Disqus has since changed their universal js snippet.
The Boilerplate JS
When you want to install Disqus, you register on their site, and they give you a code snippet to insert on every page which you want comments. For this example, we’ve got an
Article model, and when viewing each article, want to display comments.
# app/views/articles/show.html.slim # non relevant erb here = render 'disqus'
At which point we’d insert the vanilla Disqus JS into a partial:
From here, all that’s needed is modifying
disqus_config as follows:
this.shortname = "application_name"; this.page.url = "<%= url_for(host: ENV['APPLICATION_HOST']) %>"; this.page.identifier = 'article-<%= @article.id %>'; this.page.title = '<%= @article.title %>';
At which point, Disqus will load up comments for your page. Easy enough!
The one customization I made to the recommended config is
this.page.identifier. I scoped that to articles, rather than just inserting the article ID, so that in the future if other models needs comments they can be easily separated from the article comments.
Why Disqus Than Roll Your Own?
As I mentioned, there were no privacy concerns going into this (ie, all pages are public facing anyways), plus this will offload maintenance for both comment functionality and administration. This has enabled us to spend more time on items like addressing page load speeds, Elasticsearch enhancements and functionality which is unique to their business. It saves them money, and allows me to work on much more engaging projects, which is a win for everyone.
10 December 2016
When should you work? How often should breaks be scheduled? How about food, water, workouts? What sort of things alter your mood or mindset throughout the day which can alter your quality and output? What follows are some things to think on as you approach the work week. Focus on these items and be productive over the next week.
10 December 2016
Part 2 is here with a few enhancements I use in my day to day development, researching and code audits for Ruby and Rails. Check out the first part as well; there’s always more to learn.
09 December 2016
In a few previous articles, ( Solr on Rails, Efficiently Run and Maintain Your Rails Application, Running Rails Apps Simultaneously During Development) I’ve recommended using Foreman to run your Rails applications in order to maintain the best development and production parity. However, it would appear that out of habit, I’ve been wrong on this for the last year, as Heroku has replaced Foreman in the toolbelt with Heroku Local).
So, still keep your Procfiles the same, but launch them with
heroku local -fProcfile.dev rather than
foreman start -fProcfile.dev.
One noticeable improvement is that Heroku Local is more verbose about your .env file on boot, which is fantastic.
I’ve had a few days that started out poorly because of a typo in my
.env that snuck in and completely killed a few hours hunting down invisible bugs that didn’t exist. As a side note, when that happens, step back after a few minutes, take a breather and down an espresso. You’ll come back much clearer.
I noticed this deviance in my current behavior when I was about to sit down and write an article on the importance of knowing and abiding by the 12 Factors. Instead, I found a few seconds in that my own Factor X had slipped. Best to publicly remedy it in case anyone else read it in past articles of mine.