# Changelog: Blog 3.5

Notice something new? Read through how I approached improving the design of the blog, embraced the whitespace, and trimmed dependencies away.

## Haskell & CI

Setting up Travis CI to automatically build your Haskell projects using Docker. Read more

## Trying out Gentoo

My experiences with the sourced-based Linux distro. Read more

Eduardo Trujillo

For the past few years, I’ve given this blog a fresh coat of paint every few months, even if I don’t post any new content. Sometimes it’s a major redesign or refactor, involving switching the underlying language or framework. I’ve gone from PHP, to a Node.js server, and back to basics, a static site. Other times, the changes are more subtle and in the background.

As time has allowed in the past few weeks, I’ve been working on modernizing the blog’s project. However, it’s not a departure from using Hakyll, in fact it’s the opposite. My two main goals this round were to improve the visual appearance of the site and to make the code itself easier to build and deploy.

Improving the site’s appearance wasn’t something I planned throughly. After all, I’m a programmer first, designer second. I decided to go with an iterative approach. This worked well with my schedule because I have limited time to work on side projects, and I don’t necessarily work on the same project every time.

Each iteration began with me looking at the current design and layout, and asking myself questions like “What can I make better?”, “What am I trying to achieve?”, and “How do I optimize the site for that?”. This was an interesting mental exercise because these are not things I always think about.

Next, I would make a few changes to the layout or styles, and play with them for a while. If I felt that it was an overall improvement, the change stayed, otherwise I rolled it back and tried something else.

Now, I realize I’m probably describing what is a generic iterative design process. What’s interesting to me is being able to spend time on it, given that my past redesigns were mostly driven by a change in the stack powering the site. This goes back to my decision to keep things simple and making my blog statically generated.

On the engineering side of things, my sole goal was to keep simplifying. There were also iterations, but different questions were asked (“Can I get rid of that?”). I basically looked at all the “moving pieces” and dependencies of the project used to generate and serve the blog, and tried to figure out what could be removed.

One big dependency of the project was Node.js. Even though the site is generated by Hakyll, I still needed a way to compile my SCSS files, along with a package manager to obtain dependencies like Foundation or Font Awesome. On top of that, the project was a bit stuck in the past. Dependencies were pulled by Bower rather than NPM, and it was using Gulp rather than Webpack.

I first tried to migrate to Webpack, but later decided that it wasn’t helping much. I still relied on Node. As I kept looking, I found two packages on Hackage regarding building Sass/SCSS projects using just Haskell by using libsass: hsass provided a Haskell API on to of these bindings, and hakyll-sass showed how to use this in a Hakyll context.

I added hsass as a dependency and used a similar approach as hakyll-sass without importing another dependency. A simple SCSS compiler for Hakyll can be defined in just a few lines:

sassCompiler :: SassOptions -> Compiler (Item String)
sassCompiler options = getResourceBody >>= compileSass options
where
compileSass :: SassOptions -> Item String -> Compiler (Item String)
compileSass options item = join $unsafeCompiler$ do
result <- compileFile (toFilePath $itemIdentifier item) options case result of Left sassError -> errorMessage sassError >>= fail Right result_ -> pure$ makeItem result_

On top of that, I also took a minimalistic approach with dependencies. I dropped most external resources, such as Google Analytics, Typekit, and MathJax, and replaced them with resources served from site itself. This greatly simplifies CSP policies, reduces the number of requests a browser has to do to read this blog, and is privacy-friendly.

Tracking is just gone, and I don’t plan to add it back, unless the needs of the site change. Right now, it’s just overkill for this blog. Typekit was replaced with Inter UI, a gorgeous open source font. MathJax is now self-hosted rather than pulled using a CDN. Foundation and Font-Awesome were already self-hosted.

Dependency management through NPM was replaced with shallow Git Submodules. Rather than cloning the entire repository, Git fetches the repository at the specific version/commit needed.

Finally, you may have noticed that the sidebar is gone. I tought about it and came to the conclusion that I don’t use my Twitter that actively anymore. Now, there is nothing to steal focus from the core of the blog, the content.

With the sidebar gone, I still wanted a place to highlight content, and place links to other sections of the blog. The home page now has a “leaderboard” component. It’s an experiment. Over time, it may stay or leave. We’ll see.

Anyhow, I still haven’t talked about how all this is deployed. I hope I can get to it on a future post.

Eduardo Trujillo

Phabulous is a server written in Go capable of receiving event notifications from Phabricator, a suite of developer tools and forward them to a Slack community, while also providing additional functionality through a bot interface.

The project started while I was working at Seller Labs and Phabricator was their repository hosting tool. We mainly wanted to have better integration with Slack, just like GitHub and Bitbucket had.

Over time, Seller Labs migrated to GitHub and other tools, so development on Phabulous slowed down a bit since I wasn’t using it on a daily basis any more.

However, this does not mean the project is dead, I’ve quietly been finding some spare time to work on improving Phabulous, and it has received a few contributions through pull requests.

I recently landed a large refactor of the project which should make future contribution and extensions easier. I’ve reorganized how the code is structured to make better use of Go interfaces.

In a perfect world, I would have enough time to write an extensive test suite for the project, but given my limited time, I’ve only been able to cover certain simple part of the project. The transition to interfaces has allowed me to improve the coverage of the project since dependencies can now be easily mocked.

Another side effect that came naturally from this transition was the increased modularity of the code. Want to implement a connector for a different chat protocol? Or do you want to add a new command? Just implement the interfaces.

While still technically in beta, I’m happy to say that Phabulous has reached v3.0.0. With this new release, you can expect the following new features:

• Experimental support for IRC: The bot is now able to connect and work over IRC networks. Functionality is almost on-par with what is available on Slack.
• Modules: Commands and functionality are now split into modules. You can enable/disable them in the configuration file, as well as implementing your own modules when forking the project.
• Improved integration between Slack and Phabricator: Phabricator added a new authentication provider that allows you to sign in with your Slack account. Phabulous makes use of this new integration with a new extension. This extension allows the bot to lookup Slack account IDs over the Conduit API, which means the bot can properly mention users on the chat by using their Slack username rather than their Phabricator username.
• Summon improvements: The summon command can now expand project members if a project is assigned as a reviewer of a revision. Additionally, the lookup algorithm has been optimized to perform less requests on the Conduit API.
• Many other small fixes and improvements.

You can get the latest version of the bot by using Docker or by downloading the latest release on GitHub.

Eduardo Trujillo

If you have a Linux laptop or desktop with a solid-state drive, and happen to have disk encryption enabled through a LUKS/LVM combo, getting TRIM support enabled isn’t a very straightforward process. It has to be enabled on every IO layer.

In their blog post, How to properly activate TRIM for your SSD on Linux: fstrim, lvm and dm-crypt, Carlos Lopez gives a brief introduction on what TRIM is, and explains why it is beneficial to enable it. The article also describes the steps needed to enable this functionality on each IO layer (dm-crypt, LVM, and the filesystem).

I followed most of this guide for one my own systems, and while I followed their advice and avoided enabling the discard flag on the filesystem, I never set up a cron job for running the trim operation periodically. So I found myself manually executing fstrim every now and then by hand.

This quickly became slightly repetitive, so I began looking into setting up the automation part. The guide above had an example setup using cron. However, I never set up a cron daemon on my system. So I wondered if it was possible to achieve the same result using systemd.

After reading some documentation on systemd unit files, I learned that is possible to setup timers for your service units, which effectively achieves the same result as a cron daemon.

Below I’m including a fstrim service and timer. The service mainly specifies which command to run and the timer defines how often it should be executed. Note that the service unit does not have a WantedBy option and its Type is oneshot. This means it won’t be automatically executed, and that it is intended to be a one off command, not a daemon. The timer does have a WantedBy option, which will result on it being started at boot.

I can check the status of the timer by using systemctl list-times and also run the operation on demands by starting the service unit: systemctl start fstrim. The logs are stored on the journal, which can be queried with journalctl -u fstrim.

##### /etc/systemd/system/fstrim.service

This is the service file. Here you can customize how fstrim is invoked. I use the a and v options, which tell fstrim to automatically run on every drive and print verbose output. Additionally, this assumes fstrim is installed at /sbin/fstrim.

[Unit]
Description=Run fstrim on all drives

[Service]
Type=oneshot
ExecStart=/sbin/fstrim -av
User=root
##### /etc/systemd/system/fstrim.timer

In this configuration, the fstrim command is executed by root 15 minutes after booting the machine and weekly afterwards.

[Unit] Description=Run fstrim on boot and weekly afterwards

[Timer]
OnBootSec=15min
OnUnitActiveSec=1w

[Install]
WantedBy=timers.target

…or you can find more in the archives.