When I was running this site through WordPress, I had a plugin that would count the number of words each of my posts contained and give me some metrics. It was a pretty slick plugin and had all sorts of visuals.
With Jekyll, I don’t have such capabilities out of the box (or even remotely close to the box) so I went hunting for a plugin. I found one, and it works, but it’s slow, and I don’t really think there’s much that can be done about it. Given the static nature of Jekyll, it’s not really easy to save persistent information somewhere like in a database without also having a plugin for the database.
The plugin brought down my build to a crawl (140s over 13s) and GitHub didn’t whitelist the plugin, so it was pretty much a non-starter.
Needless to say, I pulled it, but if you want to see the commit where I added it, go here (then the subsequent commits here and here. Here’s where I pulled it).
For the record, before this post: 92,205 words. With this post: 92,392 words.
So as you probably know by now, I converted my blog to Jekyll, yesterday, and it’s been a huge success, in my opinion. I’m motivated more than ever to start blogging more because I have the added tinker factor and using Git and GitHub to keep everything organized rocks.
But that isn’t what this story is about. Tonight’s story is about a server. A lowly VPS floating somewhere in the SFO DigitalOcean…. ocean. I’ve had this server running for many months–probably over a year now and I just don’t know it–and it’s hosted just about anything and everything I’ve tinkered with including many a failed idea.
I use this server a lot and for the most part it always responds well and isn’t sluggish. It’s hosted my former WordPress blog since January and hasn’t made but a peep about it so I’ve spent quite a bit of time thinking nothing’s amiss. I felt, though, that Jekyll shouldn’t be taking as long as it was to build my site but I couldn’t convince myself the server was overloaded.
As it Turns OutTM, I was wrong.
My baby of a server has, for the last five or so months, been filling Newrelic graphs with stuff like this:
So I’m just going to go ahead and say that’s not good. The only graph above that’s even remote decent is the Disk graph, but it’s washed over by the CPU > 80% indication so it’s also pretty much hosed.
At this point I’m honestly surprised. I’m a terrible pseudo-sysadmin and I should be fired but there’s no one to fire me and I’m the boss so whatever. If I can fix all this, I’m giving myself a raise.
I started digging. I wanted to see what’s running and who’s sucking up all the juices. I fired up top and waited a few seconds. A few things popped up: a couple instances of node and an instance of ruby.
Hmm. That doesn’t make any sense… I’m not running any node apps and jekyll is the only ruby thing I use right now… oh wait.
See, I tinkered with NodeJS apps late last spring. Ghost was a blogging tool I was considering for a while. I also tinkered with Discourse to see what it was all about. Turns OutTM, neither are suited for my needs.
I don’t really know what happened but I can only assume I forgot about them and they’ve been running all this time. I had a total of five Node instances running and Docker was running Discourse so between the two of them, I was on swap 24/7. So dirty.
This story isn’t super climactic in any way and the fix was easy: kill all the things. I also found this to be a good time to remove Node and Docker since I need neither.
I still couldn’t figure out why my disk usage was so high, though. Leave it to me to forget about a 4GB .iso I left in a folder and leave it to Discourse to fail at sending 5GB of emails through postfix over the last five months and clog up my /var/mail folder. Needless to say, after the almost-winter cleaning, I gained quite a bit of ground:
Sorry this story wasn’t more interesting. If you’re curious, my Jekyll build time was cut in half.
That’s about it. Orphaned tools and processes makes my server a dull VPS.
When the Mailbox team joined Dropbox in 2013, we shared a passion for simplifying the way people work together. And solving the email problem seemed like a strong complement to the challenges Dropbox was already tackling.
But as we deepened our focus on collaboration, we realized there’s only so much an email app can do to fundamentally fix email. We’ve come to believe that the best way for us to improve people’s productivity going forward is to streamline the workflows that generate so much email in the first place.
In other words, it was only a matter of time. I enjoyed Mailbox. When I first discovered it and received my beta invite way back when, I was instantly hooked. The concept of being able to swipe emails around and either put them off until later or never have to deal with them at all was amazing. In my opinion, the best feature about the app was probably the reminder/scheduling swipe.
Deferring an email until “the evening” or at some point in the future when I could pay more attention to it rocked. I would use this almost on a daily basis with my personal emails.
Now, I guess I’m going back to the native Mail app, an app I never left on the Mac[footnote]Mailbox for Mac never was very good.[/footnote]. I could use something like Spark or Inbox. I’m not that resistant to change.
There’s one thing that sets this event up for another one of those things that can be classified by the phrase historically speaking, and Brent Simmons puts it quite succinctly:
When deciding whether or not you can trust an app to stick around, you can’t go by whether or not it was acquired.
This is so true. I like to use Nik as an example. A software company that developed photography editing tools, it was acquired by Google in September 2012 but is still going strong as a part of the Google Nik Collection. If you’re still not sure who Nik are, have you heard of Snapseed?
I’ll pour one out for Mailbox because I have some crappy beer in the fridge, but in a week, I’ll have already moved on.
Now that I’m running my blog using Jekyll, one thing I’ve already found to be rather frustrating is the post generation process. I have a blank .md template I open, save in a new location, then edit, but that seems cumbersome, to me. What I decided to do instead is write a quick Ruby script that generated a post .md file for me based on the information I provide.
I wanted to keep it simple, and just do only what I really needed. I don’t need any fancy logic or checking. I know _posts will be there because I put post_generator.rb inside my Jekyll directory.
Here’s my code as it stands inside right now:
It’s functional. It’s not clean and could be refactored a but, but it works.
A few things that came to mind after I finished: – Use the system date if none is provided – Re-format the title with title-casing. Without ActiveSupport in Rails, I’ll have to either require it as a gem or write something by hand. I’m thinking the former. – Allow the user to write the post right there in the command line and not have to open a text editor. – Allow the user to choose which text editor to use at the prompt (perhaps with detection?)
It’s a good first draft and it serves the purpose I had in mind. Here’s the GitHub repo.
It’s taken a while for me to mentally get to this point but today I finally crossed the threshold and converted my blog into one generated by Jekyll. Essentially, every time I post or make a change, the blog is rebuilt into static files making the load on my server super light as well as saving disk space. On top of it all, I really wanted to tinker with the idea.
There were a few reasons why I finally bit the bullet and I wanted to share them in hopes that one day someone will stumble across this post and finally take the plunge like I did.
WordPress is getting kinda fat. I’ve seen fatter CMSes (anyone remember PostNuke– the year 2002 was fun.) As someone who’s getting more and more into software development and tinkering with code in general, WordPress is a beast I don’t want to tackle, to be honest.
I really only need a couple features. And one of those is a blog. It’s pretty easy to do that with just about anything and with the level of potential complexity[footnote]Not always a bad thing, mind you.[/footnote] that WordPress can introduce.
Comments, psh.. I can’t think of a time when I really wanted to have comments on blog posts. I only did it on WordPress because I honestly felt like I should. Now that I’m in complete control and this blog serves more of a purpose of me saying things and people consuming that information, comments sections aren’t really necessary. If you want to comment on something, send me an email.
I feel more developer-y. I don’t know if not using WordPress is a requirement for this one but it just feels right. I really enjoyed the setup process and learned a lot about the whole thing. Granted I have a bit of experience with Ruby, already, which really helped in troubleshooting.
So with all that being said, here it is. Every time I update, I push the new files to both a GitHub repo and my server at the same time so I have redundancy and it’s an easy way to show off what i’m doing to make this site interesting using a popular static site generator.
Over the next couple weeks, I’ll be sure to share any unique experiences I had and what I learned from them so stay tuned!