VADOSWARE

tl;dr If you/your team aren’t on to the wonders of CI yet, you should check it out. A nice easy way to get started is with Gitlab, which is self-hostable and has a free tier @ Gitlab.com. There is a lot of cool stuff you can do automatically with CI, all you need is some scripting chops and some patience to figure out what works and what doesn’t. It’s no secret that I’m a huge fan of Gitlab – they don’t pay me (this isn’t “sponsored” content), I’m just a rabid fan.

tldr; Lots of trial and error with Xorg, and some BIOS setting finangling and I got my computer to use both the onboard GFX and discrete graphics card to output video. Skip to the end for the boiled down list of steps and links that helped along the way. Around the house, I still haven’t solved the problem of very easily moving video streams from one display to another – meaning I still have HDMI wires running around my house.

tl;dr - Scroll to the bottom for the fix, if you’re having the problem, thanks to Garett L Ward for submitting the fix to me over email! This is a bit of a repost (since I’ve aleady gone into the fix in an update to the previous post), but I wanted to say it again for anyone who might find this on the internet. If you’re struggling with an issue similar to the one described in one of my previous posts regarding docker0 losing it’s IPV4 address all the time, here’s a quick recap of how I got it fixed, big thanks to Garrett for figuring this out and emailing me:

UPDATE (02/10/2018) Don’t use HSTringTemplate… Use Ginger. You probably know Jinja2 templates already, the template structure if familiar, more robust, and the documentation is way better. It’s pretty common for applications to have to send out emails, and applications in Haskell are no different. In most large applications I’ve worked on, this often means taking a template (with copy approved by management/UX designers/whatever), injecting it with data, and sending it to the user.

I recently ran into a bit of trouble using JSPM from the Gitlab CI build for one of my projects – in particular, I’ve started separating my shared frontend UI code (projects like vue-component-library, a small collection of homegrown, badly designed UI components), and reusing across projects. One of the big issues I ran into was trying to run jspm build on projects that used some of the shared libraries, that were hosted on Gitlab and not Github.

Over the last month or two, I’ve had some unexpected/weird problems building my Haskell projects on Linux – all of a sudden the project would fail to compile fairly innocuous requirements (that had up until that time compiled just fine) and I was very confused. It turns out a change to how the ` Thanks to some users on Github (mkoloberdin offered the workaround and pera noted the commit that likely caused the issue), figured out a fix that seems more permanent.

tl;dr - I added some caching to an app I’m writing in Haskell using Servant. The implementation is pretty naive, but I’ve seen some speedups (as one would expect from skipping a database access), and am glad I was able to build such a simple solution in a language as expressive as haskell. Skip to the end TLDR section to see all the code laid out! FAIR WARNING - this will is NOT an interesting article about caching algorithms or a quirk in GHC or optimization strategies.

tl/dr; I added continuous delivery to my Haskell project (after working through adding CI). The setup is somewhat convoluted, but that’s more due to personal organizational preference. This posts rambles A LOT so feel forward to skip to the end, and check out the config files that made it happen. Here lie my notes from taking my infrastructure for a Haskell-powered application I’ve been working on from Continous Integration (CI) all the way to Continous Delivery (CD).

tl;dr I set up CI on my haskell project, it’s pretty easy if you keep calm and use Gitlab’s CI settings. I hit a few bumps in the road along the way, but you can skip to the end for the completed .gitlab-ci.yml Proselytizing for CI/CD While I don’t think many people need an explanation as to why CI is a good idea, here’s why I’m going for it. As far as I see it, good software engineering as it relates to operations is like a ladder, and here is a non-exhaustive list of rungs, with sophistication/goodness of engineering increasing as I go along:

tl;dr - I switched from ployst/docker-letsencrypt which I considered less complicated than jetstack/kube-lego initially. Turns out jetstack/kube-lego is pretty simple and *just works* which is amazing, props to the team over at jetstack and as always the kubernetes team, for making this more intelligent automation possible. You could honestly just read the jetstack/kube-lego guide, it’s real good. If you wanna see my path through it, keep reading. Up until now I’ve been using ployst/docker-letsencrypt, and it’s been working fine, however I’ve longed for a solution that didn’t require me to manually kubectl exec scripts, and kube-lego is that tool.