This is a continuation from Part 1. You should probably read the previous post before reading this one. All of the disclaimers and warnings at the beginning of Part 1 apply here.
Go ahead and jump to Step 1 via the following:
$ git reset --hard step-1
In the previous step we laid out the data types that the
BasicBot struct would need to function properly. Now, we’ll lay out the behavior for the bot. To do that we’ll start by filling out the
Read on! “Building a Twitch.tv Chat Bot with Go – Part 2”
For those that are unfamiliar, Twitch.tv is a live-streaming platform for all things creative and related to games. Not necessarily just video games. Content creators play board games, roll-play games (e.g. Dungeons & Dragons), and everything in between. On this platform, streamers are able to interact with a live chat room just for their channel (with a delay).
To facilitate the streamer and chat interaction, Twitch uses a variant of IRC, and provides documentation for their implementation on their Twitch Developers page. This allows developers to create chat bots that can moderate chat rooms, interact with chatters, and automate certain tasks for streamers. There are several well known ones, with many features, but the chat bot built in this walkthrough won’t be as complex.
Read on! “Building a Twitch.tv Chat Bot with Go – Part 1”
I ran into a situation with a project where I needed to build two separate programs to work together. The first being a server, and the second being an on-going client-facing process. The server is designed to kick off any number of instances of the on-going process. Before having written any code to have the server run the on-going processes as children, I had intended the child processes to be independent of the server. That is, if the server went down, the child processes would still function. They would store requests in a queue and periodically attempt to reconnect to the server. Once the connection was re-established, everything would go back to normal. It turned out that Unix processes don’t quite work like I had expected.
In reality, when a process spawns another process, it is called a “child”; the original is called the “parent”. As long as the parent process has not exited, the child will continue to run. If for some reason the parent goes down, so does the child. That is, unless the child is considered “detached”. A child process is detached when it no longer has a parent (I believe that technically, parent-less children are owned by an
init process). Thus, you can have a parent process spawn a detached child and immediately exit, which will leave the child process all alone.
Read on! “Detaching Unix Child Processes with Go”
html/template package. Since the
html/template package provides support for calling functions assigned to data passed to the
template.Template.Execute() function, templates can fire off the localization process themselves. Once you have a template setup to utilize the localize package, it’s a fire and forget situation. The best kind, in my opinion.
One of my projects involves a lot of console output, and to make it readable, I added some color. Cyan for important messages, red for errors, and yellow for normal (everything is fine) logs.
The short of it is: I wanted to do the same somewhere else, so I published it.
If you’re a Go developer and want some quick and easy functions to color things, check it out.
Here’s the GitHub repo if you want to see the README. Or, you can just
go get github.com/foresthoffman/rgblog and use it right away.
Read on! “Go formatting with rgblog”