In a few articles (yes, I need to create a tag functionality, I know it), I have written about upgrades to the blog itself that I wanted to make. To summarize, they were:

  • Custom image inclusion
  • Better markdown processing
  • Better layout

In this article, I compared two image uploading gems, Paperclip and Carrierwave, and I was surprised that I preferred Carrierwave. I integrated it into the development blog and even tested the integration as one should do when one is trying to learn to develop properly.

In this article, I went over how a lack of good research led me to choose Redcarpet over Kramdown, when Kramdown would have been fine. Kramdown is now the gem used to process the markdown in my articles. (Comments are stripped as a whole, for now, until I integrate users, and get commenters)

I realize the layout of the blog isn’t ideal, but UI/UX isn’t my strong suit, but one thing that has bothered me for a while is the way the blockquote command was displaying natively. I didn’t think I could apply classes with markdown using Kramdown (yeah, yeah, I get it, I didn’t fully investigate again and missed some things)

I’m still in a bit of a funk regarding what project to focus on, working on one for a day, and then another, though I think I may have found some motivation today but that’s for the next article. What this usually means is that I dabble here and there, or focus on something new. For instance, I’ve been looking into the d3 library on my lunches as I’ll need it for displaying information from other projects later. A few days ago, I got a bee in my bonnet regarding the way the blog was displaying sample code blocks, and in doing so solved another issue, which is often the way, isn’t it?

Rouge isn’t always better.

The thing about mature blogs with code, and code editors (programs we use to write code), is that each language often accentuates different aspects differently. Up until now, all my code blocks would look like this, with all red text, and, while that at least indicates that it is supposed to be code, it is not ideal and for longer bits of code (blocks), it gets sort of monotonous and doesn’t really look all that much like code should. Also, it looks the same regardless of the code language it is meant to represent, but like most problems that come up, there is usually an open source solution. The solution here was something I have known about for a while, but, as usual, was hesitant to try. The solution is integration of one of what is referred to as code highlighters.

What are code highlighters, you may be asking. Well, code highlighters are gems (add-ons remember) that you can use to combine with markdown to do exactly what they say. They highlight code. They format it. However, this highlighting and formatting is specific to languages. For instance, ruby code looks like this once you get your code highlighter working

def simple_math(x, y)
   puts x + y

SQL (The language of databases) looks like this though:

SELECT fname, lname FROM customers

Now doesn’t that look better than the boring old monotone red from earlier in the article? Of course it does. So, with the bee buzzing louder, I decided it was time to integrate a code highlighter into my nascent blog.

Doing research on the Kramdown web site, the documentation mentioned two code processors, Rouge and Coderay. For reasons, I can’t truly remember now, I chose to try and integrate Rouge.

I followed the instructions for integrating Rouge with Kramdown. I followed various tutorials and SO answers and could not get it done. I cleaned out code and re-entered it, I tried using spaces, not using spaces, but nothing could get it work. Maybe I was missing something, maybe the version of Rails (version 4 still) isn’t compatible any more, I don’t know, but it was very frustrating.

Finally, after about 2 hours, I figured it couldn’t hurt to try Coderay instead. I followed the simple steps of adding the Coderay gem to my application, and, honestly, that was it. It worked right away. Using the development server built-in to the rails app I entered a few samples that would require the markdown to work with Coderay and it displayed perfectly. I didn’t test it, but honestly, I’m not sure how to test it even if I was going to. If you are reading this and have a suggestion, please put it in the comments.

So that was great, I had my code highlighter working, but what about that pesky blockquote issue?

Fixing blockquotes

As I said before, I don’t like how blockquotes are displayed natively by markdown. Something about the format of it bothered me, and i wanted to fix it, and previously I thought I couldn’t, but that turns out to be wrong. In my research on the above mentioned Kramdown documentation, I found that there is a way to add custom classes (and other attributes) within markdown using Kramdown, which, it turns out, was pretty important, since the integration of Coderay somehow made the default blockquote command (the > sign before text) no longer work. So, though it probably took me a little while than it would take others, I was able to write a custom class, extending the basic blockquote formatting (thanks SCSS) and tweaking it to look like I want it to. So now,

A blockquote will be formatted like this

I think it looks better, but now I know how to add custom classes to all my text and thus I can really work on making my articles look less boring going forward, but that means focusing on the UI/UX ideas and coming up with some custom classes to work with. It also means though that any blockquotes in older articles currently don’t work. In fact:

Many articles published before this one now need formatting adjustment and I will do it over time, but I can’t do it all at once so if you don’t see the word reformatted next to the title of older articles, it might look a little weird and off-putting. I’m getting to it I promise.

So, I can highlight my classes, I can apply custom classes and cleaned up my blockquotes, which is all great, but what about the pictures John?

Heroku doesn’t like local image storage

As I wrote, I have created an image uploading functionality for my blog using Carrierwave. Now there are two primary ways to store your images and uploads these days. You can do it locally, (for non coders, it’s like the equivalent of putting it on your hard drive) or you can use cloud remote storage (again, for non coders, putting it on dropbox is remote storage). If you are going to use remote storage for your image uploads, there are additional tools, functionalities, and services needed. Be it AWS or Google Cloud or setting up your own droplet, the learning curve for this seems a bit steeper than I think I can handle right now.

Thus, I did not set up remote image storage functionality when I integrated Carrierwave into the blog, because I didn’t think I would need it right away. It turns out that this means that even though I built the image upload and access functionality, I can’t use it right now.

I use Heroku to host this web site. It’s called a Platform as a Service (PaaS, similar to SaaS that more people may have heard of). What that means to me is that to set up this web site for hosting, Heroku did (and does when I update it) a lot of the work automatically. I could set it up myself, but that’s more work and learning new things (linux, server set up, environmental variables and a bunch of new gems) that I don’t feel ready to learn at this time, especially when I’m still working on getting one of my current projects to a point where I feel it’s robust enough to consider deploying. Therefore, when I want to add new code and database structure content to my app, I write one command on my command line and Heroku does the rest.

It turns out however, that Herokus does have some limitations with all the automation it provides. One of those limitations is that you can not upload and store images remotely on your part of Heroku. Stack Overflow has a great explanation (the first answer) as to why this happens. I don’t fully understand the answer but I understand that it means, any time I send a revision or new functionality for the blog to Heroku, all my uploaded images are going to get erased, and any links to them in articles will be broken, which is a bummer.

Now, there are a variety of possible solutions, I could use a cloud based image hoster (AWS or Google seem like the best prices, but price comparing them is harder than figuring out your cell phone bill), or I could take the plunge with Digital Ocean (sorry for the unfortunate pun), and finally learn how to deploy my own server. For my traffic load and image load, Digital Ocean would probably be cheaper, but I’m not sure I’m ready to do that (plus I have to figure out how to transfer content from one place to the other). Digital Ocean will come into play one way or another later, and learning how to use AWS or Google Cloud would not only help me with my own projects, but add another tool to my toolbox to make me look better to those hiring. Either way, that’s a future problem to deal with, so for now, even though the functionality is there, you probably won’t see a lot of images on blog posts in the near future, though, some quick research revealed that dropbox may be an intermediate solution in the future, but I have to look into that later.

So, that’s it for now. Though they might not show up immediately, changes have been made to the blog, and as usual, those changes have just opened up new paths that need attention and that attention will be paid in the future, I promise.

Thanks for reading.