Writing A Ray Tracer in Go - Part 3

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. »

3 Git Productivity Hacks

Most Ruby developers use Git for their version control system of choice. Git is a wonderful tool that can save you countless hours of lost productivity and makes collaborating with others a cinch. Git’s distributed nature also allows devs to work anywhere with or without an internet connection without fear of losing work. With all of the power that Git provides also comes some complexity. Newcomers to Git may find it’s syntax somewhat unintuitive and clunky at first. »

Writing A Ray Tracer in Go - Part 2

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. »

Writing a Ray Tracer in Go

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. »

Scripts to Rule Them All

Problem Recently at work we have started to redo our Continuous Integration pipeline by relying more heavily on Docker, docker-compose and Jenkins. Previously we had a mashup of custom scripts and while we still used Docker and Jenkins, there was no standardized process when it came to setting up a new codebase for CI. This worked OK when there was only a handful of codebases, but as we are making the move towards more and more microservices, each project requiring it’s own custom setup for CI simply does not scale. »