The task all web developers actively avoid... form validation! Whether you're implementing it on the client or server, it somehow always manages to be a painful experience. Though I can't make the pain go away, I can make it sting a little less by using this as an opportunity to demonstrate how you can use the builder pattern to construct your own powerful form validation tools. If you've spent any amount of time doing web development in Go and working with third party libraries, you've probably encountered the builder pattern already. For a classless language like Go, you can apply the builder pattern to ease constructing and initializing complex types.

One of the many pleasures of being a developer is that we're able to solve problems–no matter how obscure–through code. We can automate day-to-day tasks that might drive others mad. Our solutions may range from something as small as a bash script, to as elaborate as an entire application. I think nearly every developer is guilty of automation. One common task in this category of coding is screen scraping–the act of obtaining data from the web by parsing raw data, typically markup. Follow along as we build the skeleton for a simple screen scrape CLI in Go capable of notifying you whenever new content appears on your favorite web comics.

Authentication as we know it leaves a lot to be desired on the web. We've come to rely on our browsers and third party applications to manage our ever mounting collection of identities. Standards such as OAuth help us consolidate these credentials–but in many ways they serve more as a form of misdirection. Do you really understand the implications of the permissions you're granting when walking the painful OAuth dance? Are you sharing too much? Very few authentication options leave you with that warm and tingly sense of security. However, there's been some intriguing projects recently that aim to do away with the authentication headache–or at least the password portion of it. In this post we'll explore how to implement a passwordless authentication flow using Go to make your next web project's authentication process slightly less unpleasant for everyone.

A new year is here, and it's time for that annual post. A lot happened in 2014 for me, and I suspect this year will be equally busy. I'll take a quick look back at my 2014 goals for the blog, and touch on whats to come.

I've recently taken a liking to Go, and after an evening cruising through the Go Tour and various best practice docs, I wanted to put my knowledge to the test. Since web development is where I'm most at home, I decided to seek out a web framework. One of the first to catch my eye was Revel, which aims to be the "batteries included" web framework for Go. Being a fan of Python (the batteries included language), this felt unusually welcoming. In noticing that Revel has websocket support out of the box, I imagined this could provide an opportunity to do something interesting. However, anyone whose worked with raw websocket messaging knows it can get messy fast. In order to do anything substantial you'll find yourself re-creating similar features found in Socketio–which conveniently enough is made available via the go-socketio project. The final part of this puzzle is the focus of this month's brief blog post: combining revel and socketio into the same project, without running separate servers.