I generate some PDF outputs from a couple of scripts I have running. The fonts looked bad but I chalked it up to some font rendering issue on Linux because of a missing package. Well, turns out I was half right, specifically on the former.
Duck Duck Go quickly took me to a wkhtmltopdf bug report on the issue , which led to a comment with a fix, which led to a Debian wiki article with a conf file for getting Cairo into shape. The supplied fonts.conf on the wiki page worked like a charm on CentOS.
The last few weekends have been pretty busy with respect to updates on this site. As a consequence, this is the first of several posts that I want to get out the door.
It started when I was looking up some CSS on w3schools.com and noticed their jQuery tutorial. Probably just out of curiosity to see what kinds of things the tutorial walked through, I headed on over to it and was greeted by my good friends DOM lookup and CSS selector. I had no idea this is was jQuery was all about! Well, I probably did way back in the day, but back in the day I didn’t know how to really use CSS selectors. I had played around with, and got utterly frustrated with XPath years ago which probably led me astray.
So with this in hand I started to — like I do with every other cool new trick I learn — add it to my site.
First task: usability. At times I’ve felt like my site loaded too quickly. I would click on a link and the page would load so fast that I wouldn’t know the new page had loaded. To combat this usability edge case, I added a slight fade-in delay when the page loads.
Next up: content loading. I’ve long wanted to dynamically load content into a page. But since I moved from PHP solutions to a static site generator, I’ve resorted to cronjobs to download and insert new data. That’s not ideal and gets to be a pain to manage, though using git certainly helped lessen the pain. But with jQuery, I could now load in some data feeds as they changed on the filesystem.
for file in *.ogg
ogg123 -d wav -f - "$file" | lame -h -m s -b 192 - "$(basename "$file" .ogg).mp3"
When you inherit a script, cut it in half, make it more readable, and cut processing time down from hours to 3 minutes and 14 seconds; all done while pairing.
My last blog post on this was nearly two years ago. Funny how things can fall off the radar and then months or years later suddenly become a stick in one’s craw.
Anywho, I finally sat down and figured out why Tipue would choke when I would add the contents of a blog post to the search data (titles and tags worked fine). I narrowed down the culprit by process of elimination with a select post’s content, and then played around with Twig filters until I got what I needed.
The solution? Remove line breaks and back slashes. These are the two items in my one or more blog posts that were breaking the JSON formatting of searchdata.json. I’ve updated my original post to reflect this addition.
Well, “on a budget” only if you’re already using Confluence.
I recently took on a team of my own at work and wanted to implement a Kanban board for us to organize around. I heard the FLOSS Weekly episode a couple weeks back which featured the devs from Taiga.io. I took a look at this and even signed up for a fee hosted account to demo it. Very nice software, but it occurred to me that there’s a task macro in Confluence that I’ve used on occasion in the past. So I created a new page in our private space, inserted some columns with task macros; one for Backlog, one for In Progress, and one for Done. It’s not fancy by any means, and is certainly not scalable beyond the few of us, but it’s getting the job done for now and only took a few minutes and no additional $$$ to setup i.e. no budget approval.
It’s likely that there’s similar solutions in other CMS systems. If you think something up, let me know.
Years ago, I read Joe Maller’s web focused git workflow article. I thought it very interesting, and was actually my catalyst to start playing around with Git. And while the wonderful world of Git started to open to me, I never actually implemented it for my blog. I tried a few things at the time, but it felt far more clunky that useful.
Fast forward a bit and I’ve now been using Git as a standard part of my toolset at work for a couple of years now. Nothing too fancy, but I feel much more comfortable with the general workflow of multiple branches, automating actions with hooks, multiple clones, remotes, etc. So, once I got my — seemingly annual — clean-up-my-site bug this year, one of the things I implemented was something similar to what Joe had outlined.
Not only has this workflow simplified the deploy process for me, especially as I have multiple devices on which I hack my site, but it saved me from near “disaster” last weekend. I was mucking around on my server (why oh why do I still do that?) and
rmed my production web root rather than a temp copy I had in
/tmp/. But, no biggie. In just a matter of seconds I had my site back online with a simple
git clone and build. There were a few things I hadn’t included in my repo, most notably the little magnifying glass image in my search button; easy enough to replace. A nice lesson learned on a non-critical system.
And on that note, happy Backup Awareness Month!
So I’ve been obsessing with my site design over the last few weeks. It started with some big changes at first, followed by a seemingly non-stop stream of little tweaks (including some that will get committed with this post). One thing that’s irked me for awhile was that when clicking between most of my pages and my contact page, the width alignment of the content would change due the the absence of a scrollbar. At first, I played around with some CSS to remove the scrollbars from all pages. I only use a MacBook Pro or my phone, so I’m always scrolling the page with a page grab rather than a scrollbar grab. However, removing the scrollbar would likely cause usability issues for those who instead prefer to use their mouse to grab the scrollbar. Further, I couldn’t find an elegant cross-browser solution.
overflow-y:hidden worked in most browsers, but it made the page unscrollable with the mouse wheel in Firefox. So, I went the other route and forced a scrollbar on all pages, whether there was a need for one or not. Now all pages size the same which means there’s no longer that jumpy resize problem with going to the contact page, or any other minimal page.
After playing around with my bash prompt for a bit, I’ve settled on the below. For me, it’s a nice mix of bling and useability enhancements
export PS1="\n\[\e[0;33m\]\d \t\[\e[m\] \[\e[0;36m\]\u \h \w\[\e[0m\]\n\\$ "
export PS1="\n\[\e[0;33m\]\d \t\[\e[m\] \[\e[0;36m\]\u \[\e[0m\]\[\e[0;35m\]\h \[\e[m\]\[\e[0;36m\]\w\[\e[0m\]\n\\$ "