MetaBates.com

You're Benchmarking the Wrong Thing

mark+blog@markbates.com (Mark Bates) — Fri, 03 Mar 2017 09:25:02 -0500

You’re Benchmarking the Wrong Thing

The Go community loves benchmarks. It is obsessed with them. If you look at the bottom of most README’s for Go projects you will find a section labeled «Benchmarks». Everyone wants to prove how much faster their package, library, framework, etc… is from everyone elses. When looking at these benchmarks, the most important one is always missing, but we’ll get to that in a minute.

First, a quick aside to say that I believe certain benchmarks are important. For example, if I’m trying to improve a section of code have isolated benchmarks for that section of code is important so I know if I’ve made any improvements, or if I have regressed. These types of benchmarks are incredibly important. These are not the benchmarks I’m talking about in this post. This post is all about those comparison benchmarks against other projects that project maintainers are obsessed with.

Go is an incredibly fast language, let’s be honest, we already know that. For 98% of the projects out there Go is «fast enough» as is, yet, project maintainers feel a deeply embedded need to tweak every last bit of performance out of their code, but they’re doing it at a cost, that most of them aren’t aware of. That cost is the «missing» benchmark I spoke of earlier.

Recently I was having a conversation with a friend of mine. He was lamenting the fact that his Go package wasn’t seeing the uptick in usage he thought it would. He couldn’t understand why. He kept repeating that his was the «fastest» one out there. «Just look at the benchmarks», he said. He was right, his is the fastest package in that category out there, but you know what, after reviewing the package it became very clear to me what the problem was. I knew why his project wasn’t «selling». It was unusable. He sacrificed usuability for benchmarks. There, my friends, is the problem. That is the missing benchmark, usability.

An unusable project, no matter how fast it is, is, well, unusable. When writing code, you should always, always, always, optimize for usuability, clarity, and maintainability above all else. Those objectives are often at odds with satisfying the benchmark gods. When I design a package, library, tool, framework, etc… I start with psuedo-code. I want to understand how it will be used. If my psuedo-code is too complex I delete it and try a different approach. I keep going until I find a pattern and design that is pleasant to use, and offers the features I need from the package, then I start coding.

I know I don’t write the fastest code out there. I’m fine with that. I accept that. Don’t get me wrong, I don’t want to write slow code, no one does. Using those isolated benchmarks I can target segments of my code that are slow and improve them, but I do that after I have good solid public API that people will want to use.

The next time you sit down and start to write a new project, first consider the end user and what is important to them. Is speed the most important thing? Perhaps, if you’re writing something like a database. Or, is usuability the most important thing? If you’re unsure, err on the side of usuability. If no one is using your project, what is the point of it being the fastest out there? If it’s usuable, then people will use it, and then, you know what? Those same people will start contributing to it to make it better and faster!

Now Building With Hugo

mark+blog@markbates.com (Mark Bates) — Thu, 09 Jun 2016 16:20:56 -0400

Recently a good friend of mine, Steve Francia, released a new version of his static site generator, Hugo. So I thought I would give it a spin to see if it’s any better than my old platform, Jekyll.

The big reason that I was interested in Hugo, wasn’t just because I’m friends with Steve, but rather speed. Jekyll had always been easy to use, but it was pretty slow. Like really slow. I also had the occasional issue with it not properly building after I would save a file. It wasn’t that Jekyll was bad, but there was definitely room for improvement.

I had tried previously to switch over to Hugo, but there wasn’t a good way to import from Jekyll and I had a) no intentions of manually converting all my previous posts and b) losing all of that content and starting over again.

I spent some time with Steve a few weeks ago, and he told me that the latest version of Hugo had built-in support for importing Jekyll, and that I didn’t have to rely on hacking third party scripts to get the job done.

After running the importer all of my posts were there, and they only needed a wee bit of tweaking to make them look good with Hugo. Then I was off trying to find a good theme for the site, preferably something similar to what I had. That was easy enough, a few tweaks to a «bootstrap» theme and I was set.

Overall I’ve been happy with Hugo, now that I have it set up. I just hit save and Hugo rebuilt my entire site in 234ms. That’s pretty darn fast! Especially compared with the speeds I was getting with Jekyll. Oh, and did I mention that it also reloaded the site in my browser for me so I can see it getting updated everytime I hit save? Yeah, pretty nice.

For now, I’m sold on Hugo. Does that mean I will blog more? Who knows? I do know that it certainly couldn’t hurt. :)

Handling HTTP Request Errors in GO

mark+blog@markbates.com (Mark Bates) — Thu, 15 Oct 2015 00:00:00 +0000

I’d like to take a quick moment and discuss handling HTTP request errors in Go. I often see people write code that they believe to be handling errors when making HTTP requests, but they’re not actually handling any errors the application you’re making requests to might be returning.

Let’s take the following piece of code:

package main

import (
  "fmt"
  "log"
  "net/http"
)

func main() {
  http.HandleFunc("/boom", func(res http.ResponseWriter, req *http.Request) {
    res.WriteHeader(500)
    res.Write([]byte("Boom!"))
  })
  go http.ListenAndServe(":9000", nil)

  res, err := http.Get("http://127.0.0.1:9000/boom")
  if err != nil {
    log.Fatal(err)
  }
  fmt.Printf("res.StatusCode: %d\n", res.StatusCode)
}

Admittedly this is a pretty simple piece of code, not much happening. We are starting up a server, then we make a request to that server. This is all well and good, until we get to the following piece of code:

if err != nil {
  log.Fatal(err)
}
fmt.Printf("res.StatusCode: %d\n", res.StatusCode)

That second of code is doing the «error» checking of the request. If we run this code we’ll see the following output:

res.StatusCode: 500

Wait, if our response status code was 500, which is an error code, why didn’t our error handling work? The application should have logged the error and quit. The reason for this can be found in the Go documentation.

An error is returned if there were too many redirects or if there was an HTTP protocol error. A non-2xx response doesn’t cause an error.

I added the emphasis on that last sentence myself, because it highlights why our error checking code didn’t work. The http package does not return an error if the status is a non-2xx code. We have to check for that manually ourselves.

Let’s rework the error handling portion of our example, this time let’s check the status and handle a non-200 response:

res, err := http.Get("http://127.0.0.1:9000/boom")
if err != nil {
  log.Fatal(err)
}
fmt.Printf("res.StatusCode: %d\n", res.StatusCode)
if res.StatusCode != 200 {
  b, _ := ioutil.ReadAll(res.Body)
  log.Fatal(string(b))
}

Now if we were to run this code you can see we now see the error printed out the screen and the application quits as we expect it to. We are now handling the responses from the application properly.

Beware of this trap when you’re making HTTP requests in your Go apps. I see this mistake made all the time. It’s an easy mistake to make. But now you you know, and knowing, as they say, is half the battle!

One Final Note

Despite using it in my example, there are very few times when you should actually use ioutil.ReadAll. It is highly inefficient and reads everything into memory. I only used it here because it simplified my code example and I knew what it would be reading. Please seriously think twice about using ioutil.ReadAll. (There Bill Kennedy, happy?)

MetaCasts.tv Acquired by O'Reilly Media

mark+blog@markbates.com (Mark Bates) — Mon, 01 Jun 2015 00:00:00 +0000

For the past two and half years I have prided myself on bringing MetaCasts.tv subscribers high quality, educational screencasts on a variety of subjects, from Ruby to JavaScript to Go. In that time I have produced almost 37 hours of video. It has been a remarkably fun ride, but that ride has now come to an end.

When I announced that MetaCasts.tv would be shutting down there was a lot of speculation as to why, but at the time I was unable to provide any specifics behind it. Well, now I can. I’m happy to announce that O’Reilly Media, Inc. has acquired MetaCasts.tv. Over the coming months I will work closely with the great team over at O’Reilly to make all of the MetaCasts content available on their properties.

While I will not be joining the O’Reilly team, I will, however, be producing new content with them from time to time in the future.

I am very excited about the opportunity to see these screencasts get in the hands of a lot of developers, to help them grow and learn, and I can’t think of a better partner to do that with than O’Reilly.

Thank you all, again, for your great support over the past two and a half years. It’s been wonderful!

@markbates

So Long, and Thanks For All The Fish

mark+blog@markbates.com (Mark Bates) — Thu, 07 May 2015 00:00:00 +0000

On January 1st, 2013 I announced MetaCasts.tv a weekly screencast site that would focus on Ruby, JavaScript, and any other technologies I thought fun, exciting, and interesting. The response was great. I couldn’t believe how well received it was. In July of 2014 I announced that MetaCasts.tv would be focused entirely on Go. It was a scary move, but it paid off. The change was welcomed with an overwhelming positive response.

Now, nearly a year after making the switch to Go, and almost two and a half years since starting MetaCasts.tv I have made the decision that, as much as I love MetaCasts, I must let it go. It was not an easy decision to make, but it is the right one.

In the coming weeks I will be announcing plans for the future of MetaCasts, and yes, there is a future! You don’t think I would just close up shop and go away, did you?

What does all of this mean for current MetaCasts subscribers? Well, as of May 11th, 2015, all active subscribers have been issued a pro-rated refund on their last subscription payment. That goes for both monthly and yearly subscribers. MetaCasts.tv will remain up and available until at least June 1st, which means if you were an active subscriber as of May 11th, 2015, you will be able to still watch, and download, all 37 hours worth of content.

In closing you can expect another post from me in a few weeks with further details about the future of MetaCasts.tv and it’s content. I would also like to thank each and everyone of you for your support over the past two and a half years. It was such an amazing experience.

Thank you.

What is HappinessConf and Why is it Important?

mark+blog@markbates.com (Mark Bates) — Sat, 07 Feb 2015 00:00:00 +0000

What is HappinessConf?

HappinessConf is a two day, single track conference, to help promote developer happiness. That’s the single line pitch for the conference, but there’s more to it than that.

To fully understand why I, along with Scott Feinberg, am organizing a conference such as this we have to jump back to the Summer of 2014.

The History Part

Over the last few years I’ve been flying around the world speaking at many different conferences, all with their on style and slant on what a conference should be. I learned a lot during that those trips, but one thing in particular really stuck out

Conferences can get very repetitive. The same topics, the same speakers, etc… One can only take hearing the same talk so many times before you want to rage flip the coffee stand in the hallway.

In May of 2014 I spoke at Devs Love Bacon in London, England. What a great conference! It was almost all «soft» talks! But they weren’t just any ordinary set of soft talks, they were about things that developers love! I watched one talk that was about the differences in different types of Whiskey, including a tasting session! I watched another talk about power lifting! What?? It was great. Bacon really stuck with me as one of the most interesting conferences I have ever attended.

Fast-forward a few months and it was announced that the Wicked Good Ruby conference, meant to be held in my home town of Boston, was going to be canceled. There would be no conferences in Boston in 2014. I was disappointed by this, but understood completely why the organizers canceled it.

Shortly after the cancellation of Wicked Good, I was having a drink with Scott Feinberg (here’s his take on HappinessConf) who suggested we organize a conference in Boston to replace Wicked Good. I flat out refused. I told him that I think there are too many Ruby conferences already, and that if the organizers of Wicked Good couldn’t make it work, we couldn’t either.

I then told Scott that the only type of conference I would help organize would be one similar to Devs Love Bacon. HappinessConf was born.

So Exactly What Does «HappinessConf» Mean?

Scott and I want to organize a conference where developers, regardless of their programming language of choice, level of experience, etc… could come together and help improve each other’s happiness.

We want talks that cover tools, languages, practices, fun side projects, weird hacks, office setups, anything that makes you, as a developer, happy, and that can help make another developer happy.

We picked a cool venue, the Somerville Theater in Somerville, MA. We’re getting cool sponsors (if you’re interested in sponsoring, please let us know). We’re going to show an old movie, have free beer, and a bunch of other fun surprises.

It’s going to be the place to be for 2 days, we’ll make sure of that.

Why is it Important?

You only get one life and it should be the best one you can make it. You should be happy. It’s that simple. Your job shouldn’t be torture. It should be something that makes you excited to get out of bed in the morning. Something you have to pry yourself away from at the end of the day.

As developers we should help each other achieve those goals. To do that we just need to talk and share.

Together we can make all of our lives better.

The CFP is open until March 1st, so hurry up and get your talk submitted. Help make your fellow developers happier!

CFP - https://www.papercall.io/happiness-conf

Early bird tickets are now on sale, but they’re selling fast, so I would recommend getting them quick.

Tickets - http://tickets.happinessconf.com

I hope to see you all at the Somerville Theater in April, it’s just going to be so much damn fun!

Goth: Multi Provider Authentication for Go

mark+blog@markbates.com (Mark Bates) — Wed, 15 Oct 2014 00:00:00 +0000

In The Beginning…

In Ruby there is a great gem called, OmniAuth. When I write Ruby applications, this is one of the first gems I install. I use it almost exclusively for all of my authentication needs for my Ruby applications. It very easily allows for authentication through third party services, such as Twitter, Facebook, etc… and it does this in a very nice, clean, and uniformed interface. It doesn’t try to be all things to all people. It doesn’t let you make regular like posting a message to Facebook, or getting a list of tweets from Twitter. Instead it simply handles authentication, and that’s it.

Recently I started working on both an app for myself, and an app for a client of mine, both of these applications required logging in through Twitter and/or Facebook. Naturally I started looking at existing Go packages that would provide me this functionality and, hopefully, do it in an idiomatic, simple, and expandable way. Unfortunately, I couldn’t find that package, and trust me I looked. Hard.

The only package to come anywhere close to my dreams was gomniauth. Gomniauth, at first glanced, appeared to pay homage to OmniAuth. I was excited. This was just what I was looking, at least that is, until I discovered that it didn’t support Twitter. No worries, I thought, I’ll fork it, add Twitter support and everyone will be happy.

Unfortunately adding Twitter support to gomniauth was not as easy as it would seem. This is as much the fault of Twitter as it is the gomniauth package maintainers. Twitter’s auth support is ancient. It supports OAuth 1.1, and not the more modern OAuth2. Gomniauth, however, is pretty much hard coded to only support OAuth2.

What’s a person to do? I really needed Twitter support, as well as the ability to add other non-OAuth2 authentication methods. I also didn’t feel like writing a new package, I’m not a fan of «not invented here», but looking at what it would take to refactor gomniauth, not to mention break every application that uses it, I wasn’t really left with a choice.

And There’s Goth…

And that was how Goth was born. Goth, and it’s sub-package, Gothic, aim to be the OmniAuth of the Go world. Truly simple, clean, and easy multi-provider authentication. The first two providers implemented are Twitter and Facebook, proving that it can indeed handle both OAuth and OAuth2 providers.

Goth asks providers to implement a couple of simple interfaces and that’s it. By implementing the Provider and Session interfaces a new provider can easily be plugged in.

I’m hoping that the community helps out and builds implementations for their favorite authentication providers.

Example

func main() {
  goth.UseProviders(
    twitter.New(os.Getenv("TWITTER_KEY"), os.Getenv("TWITTER_SECRET"), "http://localhost:3000/auth/twitter/callback"),
    facebook.New(os.Getenv("FACEBOOK_KEY"), os.Getenv("FACEBOOK_SECRET"), "http://localhost:3000/auth/facebook/callback"),
  )

  p := pat.New()
  p.Get("/auth/{provider}/callback", func(res http.ResponseWriter, req *http.Request) {
    user, err := gothic.CompleteUserAuth(res, req)
    if err != nil {
      fmt.Fprintln(res, err)
      return
    }
    t, _ := template.New("foo").Parse(userTemplate)
    t.Execute(res, user)
  })
}

package main

import (
  "fmt"
  "html/template"
  "net/http"
  "os"

  "github.com/gorilla/pat"
  "github.com/markbates/goth"
  "github.com/markbates/goth/gothic"
  "github.com/markbates/goth/providers/facebook"
  "github.com/markbates/goth/providers/twitter"
)

func main() {
  goth.UseProviders(
    twitter.New(os.Getenv("TWITTER_KEY"), os.Getenv("TWITTER_SECRET"), "http://localhost:3000/auth/twitter/callback"),
    facebook.New(os.Getenv("FACEBOOK_KEY"), os.Getenv("FACEBOOK_SECRET"), "http://localhost:3000/auth/facebook/callback"),
  )

  p := pat.New()
  p.Get("/auth/{provider}/callback", func(res http.ResponseWriter, req *http.Request) {
    user, err := gothic.CompleteUserAuth(res, req)
    if err != nil {
      fmt.Fprintln(res, err)
      return
    }
    t, _ := template.New("foo").Parse(userTemplate)
    t.Execute(res, user)
  })

  p.Get("/auth/{provider}", gothic.BeginAuthHandler)
  p.Get("/", func(res http.ResponseWriter, req *http.Request) {
    t, _ := template.New("foo").Parse(indexTemplate)
    t.Execute(res, nil)
  })
  http.ListenAndServe(":3000", p)
}

var indexTemplate = `
<p><a href="/auth/twitter">Log in with Twitter</a></p>
<p><a href="/auth/facebook">Log in with Facebook</a></p>
`

var userTemplate = `
<p>Name: {{.Name}}</p>
<p>Email: {{.Email}}</p>
<p>NickName: {{.NickName}}</p>
<p>Location: {{.Location}}</p>
<p>AvatarURL: {{.AvatarURL}} <img src="{{.AvatarURL}}"></p>
<p>Description: {{.Description}}</p>
<p>UserID: {{.UserID}}</p>
<p>AccessToken: {{.AccessToken}}</p>
`

MetaCasts.tv/GothamGo Winner

mark+blog@markbates.com (Mark Bates) — Thu, 09 Oct 2014 00:00:00 +0000

Congratulations to Sean Powell, @seanpowell, who won last month’s contest to win a free ticket to the GothamGo conference in New York City in November, courtesy of MetaCasts.tv.

I’m really excited that MetaCasts is sponsoring this great conference, and I’m even more excited that I was able to help someone like Sean, a supporter of MetaCasts, get to go to the conference. If you haven’t already purchased your ticket for the conference, you should hurry up, it’s going to be great!

If you are going to be there, find me, come say hi, and don’t forget to ask me for a MetaCasts sticker!

100th Episode | A Free Ticket to GothamGo!

mark+blog@markbates.com (Mark Bates) — Mon, 01 Sep 2014 00:00:00 +0000

Win a Free Ticket to GothamGO!

Today I released the 100th episode of MetaCasts! To help celebrate that I want to give one lucky subscriber a free ticket to the GothamGo conference in New York City on November 15th.

On October 1st I will choose a winner from the active MetaCasts subscribers with a yearly plan.

Current subscribers: If you’re already a yearly subscriber, congrats, you don’t have to do anything to enter. If you’re a monthly subscriber, just upgrade to a yearly plan and you’ll be entered.

Everyone else: For those of you who aren’t subscribers, what are you waiting for? Register as a yearly subscriber between now and the end of September to be entered to win.

Pro-tip: Yearly team subscriptions get more entries in the contest. For example, if you have a yearly team plan for 5 members then you have 5 chances to win. Pretty simple. :)

Good luck to everyone, and if I haven’t said it lately, thank you again for all of your support!

This week’s (100th) episode: Bundling Assets

Subscribe to MetaCasts.tv!

MetaCasts Golang Future

mark+blog@markbates.com (Mark Bates) — Tue, 08 Jul 2014 00:00:00 +0000

In January of 2013 I launched MetaCasts.tv with the idea that I would generate a new screencast each week on whatever technology excited me that week. I wanted MetaCasts to be a place where developers could come and learn about topics related to their current needs, as well as technologies they might not have thought to try, or have even heard about.

During the past year and a half two things happened that have made me question this philosophy, and the overall direction of MetaCasts. The first is feedback from subscribers. The biggest complaint/criticism I’ve received is that the topics are too varied. One week it’s Ruby, the next week it’s JavaScript, the week after that Go, etc… People are unsure about what they’re subscribing to. I can understand this. If you don’t care about, say, Backbone, why should you have to sit through five weeks of it to get to the topics you enjoy? I got it. Message received.

The second change that has happened in the last year has been my discovering and falling in love with Go. I think Go is just the bee’s knees. Because of this I’m finding it very hard to generate screencasts on topics such as Ruby or Ruby on Rails when all I want to do is talk about Go.

With these two thoughts in my mind, one being the need to focus MetaCasts, and the other being my desire to spend more time with Go I have decided to stop generating Ruby screencasts on MetaCasts.

This was not an easy decision to make. I know I’m going to lose some/a lot of subscribers because of this. I’m OK with that. Ruby is great, it’s a wonderful language, and I continue to use it every day, but I have to follow my heart, and by following my heart I’ll be able to make better and more interesting screencasts, and after all, that is what this is all about.

I will still be covering JavaScript topics, although they will be more focused as well. For example, I will no longer be making any more videos about frameworks such as Ember.js or Backbone.js, but I will continue to generate videos on Angular.js, as I think it is a great companion for Go (and any other back-end technology).

I hope that people understand why I’ve decided to make these changes. I will continue to keep all previously recorded videos, regardless of topic, available to subscribers, nothing is changing there. The only change is going forward all videos will be about Go or JavaScript (as it relates to Go).

Thank you to all my current, past, and present subscribers, and I hope everyone will come along for the ride! It’s going to be a blast!

The War on Testing

mark+blog@markbates.com (Mark Bates) — Wed, 28 May 2014 00:00:00 +0000

Apologies for the slightly inflammatory title, but I’m beginning to get worried about the Ruby community, and sadly my worries are stemming from an area that first made me fall in love with Ruby, testing.

By now you are probably familiar with the whole «TDD is Dead» saga that stemmed from a keynote that DHH recently gave at RailsConf. I’m not going to bother recapping that, do a Google search and you’ll find out all about it. I’m not even here to weigh in on the matter.

I’m here to discuss an even more trouble matter, the removal of a testing framework from the Ruby standard library in 2.2. The ticket that removed test-unit and MiniTest from Ruby 2.2 can be found at https://bugs.ruby-lang.org/issues/9711#note-12.

The reasons behind removing these tools from the standard library is that it is difficult to maintain them inside the standard library, and that if people want to use them they can just install them as gems. This sounds fine, in theory, but is deeply troubling for a few reasons.

When I tweeted about this the other day I got several responses. Here are a couple that caught my eye:

In regards to the later tweet I would encourage the author of the tweet to consult the Rails documentation on how to turn off automatic test generation. These tweets are concerning because they share the same shortsightedness. These tweets are analogous to saying, «Well, I use HashWithIndifferenceAccess so I don’t care if they remove Hash from the standard library». This idea that because you use Rspec and not test-unit or MiniTest that this change does not somehow affect you is wrong. This affects the entire Ruby community.

When I first got introduced to Ruby back in 2005 I was blown away by how testing was a first class citizen in Ruby, and of course Rails. Testing was, and I hope still is, a core tenant of the Ruby community. By removing a testing framework from the standard library we are telling newcomers, as well as though who wish Ruby ill that we don’t value testing.

Imagine for a second that you are checking out a new language. You scan through their standard library and find no testing framework. What would you think? I would be taken back. I would assume that there some tool I can probably download somewhere that would allow me to write tests in the language, but I honestly wouldn’t get that far. I might just turn the page on that language because they clearly don’t value testing.

Previously when a newcomer came to Ruby they could install the standard library and start learning the language right away, that included the ability to write tests for the applications they were writing. Now when a newbie comes to Ruby they have to know to also install RubyGems, then to also install a testing library, of course they’ll then have to do some research on what RubyGems are and what testing frameworks there are out there, but once they get through all of that then they’ll be able to start learning the language, well… at least until they run into some sort of weird bundler issue, or RubyGems.org is down, but newcomers will just be able to figure all of that out, right?

Now I know I’ve got a reputation as being a big MiniTest supporter, and I am, for lots of very good reasons, but this goes beyond that. This gets to the core of who we are as a community and how we want to be perceived by others, and how we want to welcome those who are interested in Ruby.

Do we really want to be the language that doesn’t ship with a testing framework as part of our standard library? Do we really want to be like Java???

How I Cut the (Cable) Cord

mark+blog@markbates.com (Mark Bates) — Sun, 11 May 2014 00:00:00 +0000

Having recently moved I used the opportunity to do something I had been thinking about doing for quite sometime, cancel my cable subscription.

This was not an easy decision to make, as I am a TV addict in every sense of the word. My previous cable package was the ultimate, super deluxe package. I had quite literally all the channels that my provider would give me. Did I need all these channels, of course not! I had them for fear that I would miss out on something.

Using the move I re-assessed my TV viewing needs to decide what it was I really needed.

My Previous Setup

My previous cable, plus internet bill was $225 a month. That means that over two years, the length of a «contract» with Verizon, I would spend $5,400. That’s a lot of cash! I had two DVRs, for a total of 4 tuners. I also had a «standard» box on a third TV that would let me watch recorded shows from the two DVRs.

In addition to standard cable I also had a Netflix account, $8/month, as well as a Hulu Plus account, another $8 a month. That means my true monthly spend was actually $241, and my two year spend was $5,784.

I think I just threw up a little bit in my throat typing those numbers. Wow. When I first saw those numbers I knew there was space to save.

My Cable-free Setup

When planning out my cable-free setup, I wanted to still be able to watch TV on all the TVs in my house. I knew that I wanted to watch most of my shows on the major networks, NBC, CBS, ABC, FOX, etc… Sports is not something I ever watch, so I was less concerned about that, however my wife does watch Premier League Soccer, so that was a requirement.

My stop was to purchase a digital antenna. I opted for the Winegard FL5500A FlatWave Amplified Antenna. It was $59.99 on Amazon, had great reviews, and was quite stylish. This would get me FREE access to those major networks, all for a small upfront hardware cost.

The next question became, how to record the shows I wanted to watch on those channels. For that I purchased a TiVo Roamio DVR. For $175.91 I was able to get a 4-tuner DVR that worked with my digital antenna. There is a service fee of $14.99 that comes along with it, however.

I also grabbed two TiVo Mini boxes, $79.99, which allow you to stream recorded shows from the main DVR to another TV. It also allows you to stream live TV, from the HD antenna, to other TVs. This meant I only needed one antenna in the house to get live TV to the other TVs in the house! Win! There is, however, a $5.99/month fee for each of the TiVo Minis.

What About Non-Antenna Shows? (HBO, AMC, etc…)

Of course, this solution only gets me about 90% of the way to fulfilling my TV watching needs. Even with the major networks, Hulu Plus, and Netflix, I’m still short shows that appear on channels such as HBO, AMC, etc… These shows can be purchased from iTunes, and in some cases, if you’re lucky, you can use a friend or relatives cable login. This works for HBO GO, or NBC Sports (in the case of my wife’s soccer requirements).

Final Tally

To make all of this work, I did need to retain an internet connection. I had a choice in connection speeds, 75/35 Mbps for $55/month or 150/75 Mbps for $100/month. I went with the faster connection. Why? For a lot of reasons, most which have to do with my job as a software developer.

With the final numbers in, let’s take a look at what my new monthly, and two year costs are. I am now paying $142.97 a month versus $241/month previous. That’s a $100 savings each month!! I could’ve cut that by another $45/month had I gone with the lower plan.

My new two year spend is $3,431.28 vs. $5,784 for a difference of $2,352.72!!

Now I did have to spend $315.89 in hardware to achieve these savings. When you look at the math, however, I will pay off that hardware in just a little over three months. After that it’s pure savings. That extra $100/month is also plenty of money to cover the couple of TV shows that I might want to buy season passes for on iTunes.

Final Thoughts

Overall I’m incredibly happy with my choice to cut the cable cord. I don’t feel as though I’m losing anything from my life, I still get to watch all of the programming I want, but I get to save $100/month (or more if I lower my internet plan) while doing it.

If you’re on the fence about cutting the cord yourself, I say go for it. It’s a cheap investment to get setup with, and you can always go back to Cable, if it doesn’t work out for you.

MetaCasts.tv Episode Stats

mark+blog@markbates.com (Mark Bates) — Fri, 28 Mar 2014 00:00:00 +0000

When I first started MetaCasts.tv in January of 2013 I set out to create a unique screen cast series. I wanted a series that didn’t focus on just one topic, just Ruby, just JavaScript, etc… instead I wanted something that would challenge my subscribers, as well as myself. I wanted to talk about all sorts of technologies. I knew that some weeks the topic at hand might be incredibly relevant to viewers, and that other weeks it wouldn’t be. My hope was, and still is, that the weeks were the topic isn’t «relevant» that viewers will learn something new that they wouldn’t have otherwise.

I love to grow and learn about topics outside of my daily comfort zone, so I’ve made MetaCasts.tv a venue for that. There are some episodes where I know the topic intimately, and there are others where I sat down, studied the topic, wrote lots of code, and presented my findings. All of it an educational experience as much for me, as my viewers.

Out of curiosity I thought I would take a quick look some numbers related to MetaCasts.tv and the topics that I’ve been covering there for just over the past year, and I thought I would share them with you. Personally, I found these numbers to be incredibly interesting. I was, for example very surprised to find out what language (programming, not spoken) was most prominently featured in the episodes.

Total Hours of Video: 22:19:42

As of this post I have produced over 22 hours of video! I couldn’t believe it. I’m super happy with that number. That means as a subscriber you could fly from Boston to Sydney and still have episodes left over to watch!

Average Video Length: 00:17:23

The average length of a MetaCasts episode is just over 17 minutes. That means over your morning cup of coffee or breakfast you can watch a whole episode and impress your friends at work with your depth of knowledge.

It’s All About JavaScript (CoffeeScript)

Looking at how much time I’ve spent covering different languages it would appear the clear winner is JavaScript/CoffeeScript, with Ruby in second place.

Language	Total # of Hours
CoffeeScript	13:05:26
Ruby	06:37:19
Go	01:00:56
Bash	00:43:07
JavaScript	00:26:20
SQL	00:14:30
Other	00:12:04

These numbers are determined by the «primary language» of the video. For example a video about Ember.js would be listed as CoffeeScript, or JavaScript, even though the back-end might have been written using Ruby.

Most Purchased Video

The most purchased video on MetaCasts.tv is not surprising considering most subscribers are also Ruby on Rails developers; Ember.js Pts 1 - 5 [UPDATED]. Ember is an incredibly hot topic these days, especially amongst Rails developers, and whole of people have turned to MetaCasts.tv to help them learn about it, and I’m honored to have helped them.

Just for completeness the second most purchased video on MetaCasts.tv is Angular.js (revised) Pts 1 - 4.

People can’t get enough of JavaScript frameworks, and neither can I. I love playing with them, and I love presenting my findings, sometimes good, sometimes bad, to subscribers.

Most Watched Video

The most watched video on MetaCasts.tv was from February of 2013, in which I covered the recently released Ruby 2.0.0-rc2.

Final Thoughts

Well, those are just a few of the fun numbers from over the past year or so. Looking at those numbers the ideal subscriber is a Ruby developer who wants to level up their JavaScript/CoffeeScript skills, as well as their Ruby, and along the way perhaps learn a bit about Go, SQL, Bash, and other fun stuff.

I really couldn’t be happier with how things are going with MetaCasts.tv. I’ve received amazing support from the community, subscribers, friends, and so many great people. So I guess as long as you’re willing to come along for the ride with me, I’ll be happy to keep generating new episodes for you.

Announcing Conquering the Command Line - A Free Online Book

mark+blog@markbates.com (Mark Bates) — Tue, 07 Jan 2014 00:00:00 +0000

I’m really happy today to announce my newest book, and screencasts, «Conquering the Command Line». This is a book I’ve been wanting as a developer since I first begin my career in the late 90s. Let me explain a little bit about my background to help you understand why I’ve always wanted this book.

My background, that is to say my degree, is in music. That’s right, music, not computer science. Because of my unorthodox path into programming I was never taught how to really get the most out of the command line that I spend most of my day working in. Over the years I’ve picked up tips and tricks from my fellow developers, screencasts, and from scouring the web.

What I really wish I had, back when I was first starting out, was a book that help me understand the most useful commands, and within that the most useful flags and options, to help boost my productivity when in the command line. That’s what this book is all about. Increasing your productivity when using the command line, which as developers, is where we spend most of our day.

«Learn to master and conquer the most valuable and useful command line tools for Unix and Linux based systems. In this book you will find not only the most useful command line tools you need to know, but also the most helpful options and flags for those tools. Conquering the Command Line isn’t just a rehash of the MAN page for these tools, but rather human-readable walk-through of these tools to make you instantly more productive in your daily development life.»

I’m really excited by this book, and I hope you are too. It takes a lot of people to help make a book possible. I would like to thank Michael Hartl (and the rest of the gang at Softcover.io), Pat Shaughnessy, Pete Brown, Michael Denomy, Johnny Bourisquot, and Dan Pickett for all of their help making this book as good as it is.

If reading isn’t your thing there are nearly 5 hours of videos also available that include, not only the content from the book, but also exclusive content not found anywhere else.

Read Conquering the Command Line online for free!

Team Subscriptions for MetaCasts.tv

mark+blog@markbates.com (Mark Bates) — Tue, 10 Dec 2013 00:00:00 +0000

On January 1st of this year I announced a weekly screencast site called, MetaCasts.tv, and I have been thrilled with the response it has received over the past year.

In it’s first year I’ve released over 60 videos (17+ hours) on Ruby, Rails, Go, JavaScript, Node, Redis, iOS, and so much more, and next year I plan on releasing even more great videos on those topics, as well as new ones.

The response I’ve received for MetaCasts has been overwhelming positive. I get stopped at conferences by subscribers (from around the world) who just want to tell me how much they enjoy my videos. I get emails, tweets, and more thanking me for helping shed some light on an issue someone was having or for introducing them to a new topic.

Today I’m happy to announce that team support has been added to MetaCasts making it easier for companies and organizations to easily help their members level up their development skills.

Team subscriptions are simple and easy to use. Simply create a new team subscription and enter the GitHub usernames of the users you want to have access to MetaCasts. That’s it. When they login, using their GitHub username, they’ll have full access to all of the MetaCasts episodes.

Pricing for team subscriptions depends on the amount of team members on the subscription. Team subscriptions, like single user subscriptions, come in both monthly and yearly plans, with yearly plans offering a significant discount.

I’m really happy with team subscriptions, as people have been asking for them for a while now. Learning, and growing, as a developer is incredibly important, so I encourage team leaders, managers, etc… to help their teams out and sign up today!

MetaBates.com

You're Benchmarking the Wrong Thing

You’re Benchmarking the Wrong Thing

Now Building With Hugo

Handling HTTP Request Errors in GO

One Final Note

MetaCasts.tv Acquired by O'Reilly Media

@markbates

So Long, and Thanks For All The Fish

Thank you.

What is HappinessConf and Why is it Important?

What is HappinessConf?

The History Part

So Exactly What Does «HappinessConf» Mean?

Why is it Important?

Goth: Multi Provider Authentication for Go

In The Beginning…

And There’s Goth…

Example

Links

MetaCasts.tv/GothamGo Winner

100th Episode | A Free Ticket to GothamGo!

Win a Free Ticket to GothamGO!

MetaCasts Golang Future

The War on Testing

How I Cut the (Cable) Cord

My Previous Setup

My Cable-free Setup

What About Non-Antenna Shows? (HBO, AMC, etc…)

Final Tally

Final Thoughts

MetaCasts.tv Episode Stats

Total Hours of Video: 22:19:42

Average Video Length: 00:17:23

It’s All About JavaScript (CoffeeScript)

Most Purchased Video

Most Watched Video

Final Thoughts

Announcing Conquering the Command Line - A Free Online Book

If reading isn’t your thing there are nearly 5 hours of videos also available that include, not only the content from the book, but also exclusive content not found anywhere else.

Team Subscriptions for MetaCasts.tv

Sign up - MetaCasts.tv