DEV Community: hzoltan

What is an idempotent function?

hzoltan — Sat, 14 Aug 2021 16:40:39 +0000

An idempotent function in computing is a function that you call more than once with the same input parameters, it will have no additional effect.

It comes from mathematics which looks like this:

f(f(x)) = f(x)

Let's let's check an example in Go!



package main

import (
    "fmt"
    "strings"
)

func main() {
    definition := "iDeMpoTeNt"

    fmt.Println(strings.ToUpper(definition)) // f(x)
    fmt.Println(definition)
    fmt.Println(strings.ToUpper(strings.ToUpper(definition))) // f(f(x))
}



// Output:
IDEMPOTENT
iDeMpoTeNt
IDEMPOTENT

by calling strings.ToUpper() on definition variable at first, it will make it uppercase. But calling it again with "definition" makes no other additional effects, therefore it is idempotent.

You can try it yourself on the Go Playground!

Update: Why idempotency is useful?

Special thanks to Casper in the comment for sharing a great 15 min long podcast from Eric Normand about idempotence and why it is useful. I think he had an example rich explanation, and it's best for you to listen to his words!

Go: Provide automated tested examples for your documentation!

hzoltan — Fri, 13 Aug 2021 07:02:40 +0000

TL;DR:

You can provide example usage of your code which will be tested with go test -v. Imagine you have this really cool function:

// YourFunction will return "good output" no matter what.
func YourFunction(someInput string) string {
    return "good output"
}

Add a function in your package's _test.go file:

func ExampleYourFunction() {
    result := YourFunction("some input")
    fmt.Println(result)
    // Output: wrong output
}

Notice the Example* prefix of the function name. Now if you run go test -v it should break, because the output is wrong!

$ go test -v

=== RUN   ExampleYourFunction
--- FAIL: ExampleYourFunction (0.00s)
got:
good output
want:
wrong output
FAIL
exit status 1
FAIL    example        0.978s

Now change it to "good output":

func ExampleYourFunction() {
    result := YourFunction("some input")
    fmt.Println(result)
    // Output: good output
}

Now run it again:

$ go test -v       
=== RUN   ExampleYourFunction
--- PASS: ExampleYourFunction (0.00s)
PASS
ok      integers        0.366s

Yey!

Detailed explanation

You can provide examples for your code which will be tested, you can see it with go test -v.

Create a new directory integers

$ mkdir integers

Init our new go module (not required)

$ go mod init integers

Create a new file integers.go and put this function inside which we will test (I recommend you to type it instead of copy just for the sake of exercising your muscle memory)

package integers

// Multiply takes two integers and returns their product
func Multiply(x, y int) int {
    return x * y
}

Examples are living along with the automated tests in the _test file, create a new integers_test.go file and type your example for the function:

package integers

import (
    "fmt"
)

func ExampleMultiply() {
    product := Multiply(3, 3)
    fmt.Println(product)
    // Output: 8
}

You may already noticed but the // Output: 8 is not the result this function will return, this is exactly what we wanted: to have something that breaks. Let's check it ourselves:

$ go test -v
=== RUN   ExampleMultiply
--- FAIL: ExampleMultiply (0.00s)
got:
9
want:
8
FAIL
exit status 1
FAIL    integers        0.878s

We intentionally implemented it in a way to actually see it fail, but normally after a refactor you simply run your tests and go test will take care about the examples you provided. Now let's correct our mistake!

Fix the output and run your tests again:

func ExampleMultiply() {
    product := Multiply(3, 3)
    fmt.Println(product)
    // Output: 9
}

$ go test -v
=== RUN   ExampleMultiply
--- PASS: ExampleMultiply (0.00s)
PASS
ok      integers        0.880s

Now let's see how does this look in the documentation. Run godoc to see it troubleshooting:

$ godoc -http :8000

Now navigate to the documentation: http://localhost:8000/pkg/integers/

Amazing! Right? You have an example which is also a test, and even if you intentionally implement API breaking changes (which we obviously try to avoid) than you will see that you have to change your documentation.

I hope you enjoyed it! Here are the sources:

I learned this from the Learn go with tests book, I highly recommend to read it!
If you are interested in more detailed examples, check The Go Blog: Testable Examples in Go

Troubleshooting

In Go 1.14+ godoc is no longer included, you may have to install it directly:

$ go get golang.org/x/tools/cmd/godoc

Solution to html/template: "your-template.tmpl" is undefined

hzoltan — Thu, 05 Aug 2021 23:43:34 +0000

TL;DR

First I thought when I execute a template I'm using relative filepath, but I was wrong because it actually using template name, which is the base file name (without the directory).

Longer explanation

While following the awesome Golang wiki page assignment, I had hard time with putting the template files into a subdirectory and make them work.

If you are here, you might have some of the following directory:

├── IAmNew.txt
├── TestPage.txt
├── go.mod
├── tmpl
│   ├── page-edit.html
│   └── page-view.html
└── wiki.go

And you have something similar code to this:

var templates = template.Must(template.ParseGlob("./tmpl/*.html"))

or maybe you used the ParseFiles and have a list of files instead:

var templates = template.Must(template.ParseGlob("tmpl/page-view.html", "tmpl/page-edit.html"))

⚠️ Wrong way of executing templates

err := templates.ExecuteTemplate(w, "tmpl/"+tmpl+".html", p)

✅ I removed the directory prefix and it worked

err := templates.ExecuteTemplate(w, tmpl+".html", p)

Explanation from the documentation itself

ParseFiles creates a new Template and parses the template definitions from the named files. The returned template's name will have the (base) name and (parsed) contents of the first file. There must be at least one file.
If an error occurs, parsing stops and the returned *Template is nil.

Also another possible reason could be

When parsing multiple files with the same name in different directories, the last one mentioned will be the one that results. For instance, ParseFiles("a/foo", "b/foo") stores "b/foo" as the template named "foo", while "a/foo" is unavailable.

Check if go package installed + "uninstall go package"

hzoltan — Thu, 29 Jul 2021 23:06:41 +0000

In a directory where there is a go.mod file, you can discover the install path:

$ go list -f '{{.Target}}'

I don't come up with this, just found it at https://golang.org/doc/tutorial/compile-install .

One liner:

$ go list -f '{{.Target}}' | if xargs ls -la &> /dev/null ; then echo "Installed"; else echo "Not installed"; fi
// Outputs "Installed" or "Not installed"

Remove it:

$ go clean -i

hola mundo

hzoltan — Mon, 26 Jul 2021 13:02:08 +0000

just like every starting posts: I'm really excited to start my first developer journal!

Well I'm here to keep track of the stuff I found or eventually will find interesting.