Process vs. Procedure Recursion

2016-04-06

Just because a procedure is recursive, doesn’t mean the process that it generates is recursive. A procedure is recursive when that procedure refers to itself in order to evaluate. (defn factorial [x] (letfn [(fact-iter [product counter max-count] (if (> counter max-count) product (fact-iter (* counter product) (inc counter) max-count)) )] (fact-iter 1 1 n)) ) fact-iter, in the above code, is a recursive procedure, but the process it generates is not recursive.…

Abstraction, Scope, and Bound Variables

2016-04-06

Here’s my big take away from sicp section 1.1.8: Abstraction requires Scope and Bound Variables Procedures (or functions or methods) let us abstract our code. Abstraction is about dividing our program into identifiable tasks that can be reused in the construction of other (identifiable) tasks in our program, which can in turn be used to construct more complex identifiable tasks, etc. In order for procedures to enable us to abstract our code, parameter names of a procedure must only have meaning within body of that procedure.…

Sicp 1.1.1-1.1.7

2016-03-29

Today was my first work day at the Recurse Center. Yesterday, I found out that there’s an SICP study group. I’ve been wanting to study SICP for a while now, so naturally I joined. What follows are my thoughts and key take-aways from sections 1.1.1-1.1.7. Declarative vs. Procedural Knowledge Abelson et al. open the book with a really interesting distinction between declarative and procedural knowledge. Moreover, they suggest that the most significant achievement of computer science is that it provides a way for us to study procedural knowledge.…

Testing Package Implementation from 'the Outside'

2016-02-03

Sometimes you need to test a package’s implementation from outside of the package containing the implementation you’d like to test. This post briefly covers why this need arises and how we can meet that need. Much of the information here is already covered in Andrew Gerrand’s testing techniques talk, so if you’ve watched that, you’ll probably only think the last section of this post is interesting. Why? Like I just said, sometimes you need to test a package’s implementation from outside of the package containing the implementation you’d like to test.…

Table-driven tests with Gomock

2016-01-23

Table-driven tests are a common testing pattern for go tests. Since I recently started working with gomock, I wondered if there was a way to use table-driven tests with gomock mocks. It turns out that this is definitely possible, and that’s what this post is about. Before I show how to combine table-driven tests with gomock mocks, I briefly review how gomock and table-driven tests work and I try to show why you might want to combine table-driven tests with mocks in the first place.…

Integration Tests in Go

2016-01-22

Although Go has support for testing built in to its toolchain, certain kinds of testing can be a bit tricky. For example, it may not be immediately obvious how you would go about writing and running integration tests in go. This post contains info on how to write and run integration tests for your go code. Clarifying Terms As I’ve said before, many terms in software are vague or ambiguous. So, before I get into how to write and run integration tests, let’s make sure we’re referring to the same thing when we use the word “integration” test.…

Getting started with Gomock

2016-01-20

In my last post, I talked about why I started using gomock, a mocking library that facilitates testing in go. If you found what I said in that post at all compelling, you might have decided to give gomock a try and you might have noticed that the documentation isn’t as helpful as it could be. This post is meant to supplement the documentation. It’s a brief tutorial on how to get started with gomock. …

Should we use mocking libraries for go testing?

2016-01-14

A few weeks ago, I started learning go. Since I’m a wannabe TDD-er, I took a look at some resources on testing go code. I stumbled upon Andrew Gerrand’s excellent Testing Techniques talk in which he says this: Go eschews a lot of things, including mocks and fakes. “Alright cool,” I thought to myself. I’m down to “do as the gophers do” and eschew mocks. Later on during his talk, Andrew Gerrand mentions gomock, a mocking library, and reluctantly says [mocking libraries like gomock] are fine, but I find that on balance the hand-written fakes tend be easier to reason about and clearer to see what's going on, but I'm not an enterprise go programmer so maybe people do need that so I don't know, but that's my advice. Of course, after hearing that, I felt a little confused and unsure whether I should refrain from using mocking libraries in go. To make matters worse, I took a look at gomock and was surprised to find that its written by two engineers at Google. At that point, it seemed that the question of whether we should use a mocking library while testing go code is a bit of a contentious question, even within Google. I found the seeming contentious nature of this question pretty unhelpful and confusing when I was trying to get a handle on how to write good go code. However, it led me to do some research on the pros and cons of mocking libraries vs hand-written mocks, and in this post, I present the conclusions I came to based on my research: The apparent contentiousness about whether to use use a mocking library if probably partially due to vague terminology. If we are clear about our terms, the argument against using mocking libraries is not very compelling. …

Making a TDD-based HackerNews client for Android

2015-07-17

I’m using TDD to write a HackerNews client for Android. This post (and the ones that will likely follow it) share a little bit about some of the techniques I used to follow a TDD-based work-flow for developing this application. It also discusses the architecture that arises when Android apps are built with testability in mind from the ground up. …

Why Having Global Static References to Application Contexts is Probably not the Best Idea

2015-07-14

In my last post, I went over 6 things I wish I knew before I wrote my first Android app. One of the things I listed in that post was this: Don’t have static references to Contexts The reason I warned against this is that static references to Contexts can cause memory leaks. An astute reader pointed out that a static reference to an application Context wouldn’t cause a memory leak since the application Context is around for the lifetime the app is running anyway. I then qualified my warning by saying: Note: Technically, you can hold a static reference to an application Context without causing a memory leak, but I wouldn’t recommend that you do that either. In this post, I want to say a little more about why think having and using a static reference to an application Context is less-than-ideal. I emphasize “less-than-ideal” in the previous sentence as a way of highlighting what I’m not saying: I’m not saying that a kitten dies every time you use a static reference to an application Context. Once again, @codestandards is hilarious and relevant here: Please, for the sake of the kittens. pic.twitter.com/xaj7pNDVfH — Code Standards (@codestandards) February 24, 2015 Instead, all I’m doing in this post is offering a few points that suggest that using static references to Contexts is probably not the cleanest way of coding Android apps. …