<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Golang on Tux-Sudo</title><link>https://blog.tux-sudo.com/tags/golang/</link><description>Recent content in Golang on Tux-Sudo</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 23 Dec 2019 05:32:57 +0000</lastBuildDate><atom:link href="https://blog.tux-sudo.com/tags/golang/index.xml" rel="self" type="application/rss+xml"/><item><title>Go: Useful Development Workflows</title><link>https://blog.tux-sudo.com/posts/golang-github-actions/</link><pubDate>Mon, 23 Dec 2019 05:32:57 +0000</pubDate><guid>https://blog.tux-sudo.com/posts/golang-github-actions/</guid><description>&lt;p&gt;Code Coverage, Static Code Analysis, Tests, Releases? What else? Probably a few more things, but you get the point. These are all things that are expected to be part of a modern day development workflow. While this is becoming the norm in companies, a lot of pet open-source projects still skimp on these things. And frankly, I did too. I wasn&amp;rsquo;t going to bother hosting my own Jenkins behemoth just so my soon-to-be abandoned project could run a few builds. But with practically everything available as a SaaS (and in most cases, free for open source projects), I had no excuse anymore.
Travis/Circle/GitlabCI/AzurePipelines etc. were already quite common and with GitHub&amp;rsquo;s entry into the fray, there really is no reason not to have atleast a simple CI workflow on your project.&lt;/p&gt;</description></item><item><title>ARM Your Golang Containers</title><link>https://blog.tux-sudo.com/posts/armyourcontainers/</link><pubDate>Mon, 19 Mar 2018 11:52:57 +0530</pubDate><guid>https://blog.tux-sudo.com/posts/armyourcontainers/</guid><description>&lt;p&gt;So then, here is the deal. I write tiny microservices that may or may not serve any purpose. Despite how meaningless they might be, I give them the perfect operations treatment.&lt;/p&gt;</description></item><item><title>Caddy! Team 443 FTW</title><link>https://blog.tux-sudo.com/posts/caddy-autohttps/</link><pubDate>Mon, 19 Feb 2018 11:01:54 +0530</pubDate><guid>https://blog.tux-sudo.com/posts/caddy-autohttps/</guid><description>&lt;p&gt;This one is a gamechanger. It really is.&lt;/p&gt;
&lt;p&gt;On a recent Golang obsessed Github browsing spree, I read the following project description: &amp;ldquo;Fast, cross-platform HTTP/2 web server with automatic HTTPS&amp;rdquo;. I&amp;rsquo;ve read that before, and more often than not ended up disappointing myself and resorting to hacks like [this] (&lt;a href="https://blog.tux-sudo.com/posts/letsencrypt-nginx-docker/"&gt;https://blog.tux-sudo.com/posts/letsencrypt-nginx-docker/&lt;/a&gt;) to create an automatic TLS system for my websites. There are other ways, but almost all of them were semi-automatic in the long run (yay cron!). I decided to try out [Caddy] (&lt;a href="https://caddyserver.com/)"&gt;https://caddyserver.com/)&lt;/a&gt;.&lt;/p&gt;</description></item></channel></rss>