It's been a while since my last post, so I thought I would write about a pattern that I've come to like for handling errors in HTTP Handlers in Go. I've always enjoyed the simplicity of writing web services in Go. You create your http.HandlerFuncs, add them to your router or server, and you're done. There's no magic. With this simplicity however also comes with some downsides. One thing I've never liked is how you are forced to handle errors in your http.

Make it work, make it right, make it fast. – Kent Beck Yesterday I decided to do some profiling of my open source Go project, Flipt, to try and find some low-hanging fruit that I could optimize to give some quick performance wins. This process allowed me to find some unexpected issues in a popular open source project that I was using for routing and middleware in my application.

Note: There will be no obvious Wu-Tang Clan song references in this post. Except for this one. In my previous post: https://markphelps.me/2019/09/migrating-from-travis-to-github-actions/ I described my journey migrating my open source Go project, Flipt, to GitHub Actions from Travis. While this has turned out great, one thing that I did find missing using Actions was the ability to use a dependency cache to speed up builds. Travis has had this ability for awhile now and I previously took advantage of it when I used to run my builds for Flipt on Travis.

Over the weekend I decided to move my CI pipeline from TravisCI to GitHub Actions for my open source Go project, Flipt. I wanted to replace my existing CI as well as automate a manual release process and to try an do it all with the new GitHub Actions. Full Disclosure: I work for GitHub but not on the Actions team. I wanted to setup Actions in my open source project without getting any help from the Actions team or anyone at GitHub.

It's been almost 2 years since I've posted any content on this blog. One of the reasons for my hiatus is that I've been spending a lot of my extra energy on finishing my side project, Flipt, which I can best describe as a ‘self contained feature flag solution’. This post however is not really about Flipt, at least not directly. This post is about how it took me almost 3 years from inception to feel like I was ready to launch Flipt out into the world.

Let's imagine you are building an API client in Go to make it easier for people to interact with your public REST API. Everything is going great. You've got authentication, pagination and awesome error handling in place. One thing that's still unresolved though is how do you test it? Your client exists to make HTTP requests and then unmarshal that response data (presumably JSON) into objects that make it easy for your consumers to work with.

_This post is about a library and command I created called optional with the help of go generate. The code is here: https://github.com/markphelps/optional if you want to follow along._ I've been coding in Go for some time now, and one thing I miss from my Java days is the ability to express an option type. An option type (from the Java docs) is: A container object which may or may not contain a non-null value.

Recently I've been working on a Slack bot project in Go using the wonderful nlopes/slack client. While nlopes makes it easy to post and consume messages to and from Slack, either via the Web API or Real Time API, I found myself struggling when trying to maintain conversation state between users and the bot. Any good Slack bot is able to listen to and respond to messages given some cue or trigger.

This is the 5th and final post of my series on writing a ray/path tracer in Go. Check out the previous parts 1, 2, 3 and 4. I'm roughly following the e-book Ray Tracing in One Weekend, but translating all of the code into Go. All of the code for this post can be found on my Github. Last time we added metal and matte materials, giving us the ability to render the following image:

This is part 4 of my series on writing a ray/path tracer in Go. Check out parts 1, 2 and 3. I'm roughly following the e-book Ray Tracing in One Weekend, but translating all of the code into Go. All of the code for this post can be found on my Github. Last time we added the ability to shade our sphere and added anti-aliasing to make everything look better.

This is part 3 of my series on writing a ray/path tracer in Go. Checkout parts 1 and 2. I'm roughly following the e-book Ray Tracing in One Weekend, but translating all of the code into Go. All of the code for this post can be found on my Github. Last time I covered the basics of creating rays, spheres and calculating if a ray intersects a given sphere. In order to visualize our sphere, last time we colored a pixel red if a ray intersected it and some shade between blue and white if it did not.

This is part 2 of my journey to try and write a ray/path tracer in Go. Checkout part 1 here. I'm roughly following the e-book Ray Tracing in One Weekend, but translating all of the code into Go. In the previous post we covered how a path tracer works and got an image to display on the screen by blending red, green and blue into a cool looking gradient. This time around we'll draw a sphere instead, but by actually sending rays into the scene and marking the pixels where they hit the object.

I've been wanting to learn Go for awhile now. I bought a book, read several blogs and tutorials, but I still didn't feel like I was really getting anywhere with the language. A few weeks ago I went with my a few of my co-workers to the Triangle Golang meetup hosted by my friend Brett, and met some great people. One of the guys demoed an amazing project he had worked on, building a ray tracer in Go.