Posts tagged 'learning'

Five days of Advent of Gode

published on December 06, 2017.

A week or so ago, Luka mentioned this Advent of Code thing. I’ve been doing coding challenges and examples before, but never have I tried the AoC (this is the third year it’s running).

Advent of Code is a series of programming puzzles, where you get 2 puzzles a day for 25 days.

Given that I have started to learn golang again, I figured might as well learn more about it by joining this years challenge.

I keep a repository with my solutions to these puzzles and try to take notes for every day and now I want to look back at the first 5 days.

I started of the first day with just a mess of a code, just pushing for the first solution that gets the correct answer. On the second day I realised I won’t be learning much like this, so I decided to bring some order to the chaos: organised the code a bit nicer (even though it’s a far cry from good), added tests, and generally tried to get to a point where it’s easier to get started with a day’s challenge.

The AoC puzzles are relatively easy so far. Day 3 was the only day so far where I had problems wrapping my head around the problem. I’ve managed to figure out the solution for the first puzzle, but for the second puzzle I “cheated” and used the OEIS. shrug

As for golang… I don’t know enough of it to say if I like it or not. I mean, I do like it, sort of, but for these 5 days the most I did was toying around with strings and integers and slices and maps. That’s hardly enough time and usage to pass judgment on it.

On golang

I like how it fails to build if there’s an unused variable laying around, but then again I tend to save often, so I write:

for k, v := range slc {

Hit save and the IDE underlines that entire for line. What, why?! Hover over the line to see what the problem is… Oh, k and v are unused. Well, d-uh, I’m not done yet. But I still have to double check because the bug might be real, for example if I want to range over an integer the IDE will again underline the entire line.

For some reason I’m really bad at naming things in golang, quite often the variable and function names are just bad. I’m trying my best to follow the golang styles, but… I don’t know. I’m not sold on the whole “short rather than long” thing.

I keep mixing assignment = and assignment & declaration :=. But I’ll learn it, eventually.

I like everything about the types, even though I don’t understand everything about them, yet. Maps, for example, are not ordered even though I tried to use them as such once.

On slices

Except slices. Slices are weird. Well, were weird until I understood how golang treats and works with them.

I read four different articles to get to the point where I know what a slice is, only to get a succinct explanation of “slices are mutable views of an array”. For me, that one sentence explains it better than the four articles.

Here’s an example:

package main

import (

func main() {
	x := []int{1, 2, 3, 4, 5}
	a := make([]int, 0)
	b := make([]int, len(x))

	y := x
	copy(a, x)
	copy(b, x)


	fmt.Println(x) // [2 3 4 5 6]
	fmt.Println(y) // [2 3 4 5 6]
	fmt.Println(a) // []
	fmt.Println(b) // [1 2 3 4 5]

func F(z []int) {
	for k, _ := range z {

Notice how both x and y are the same, even though we only modify x within the F() function, without even returning anything from that function. What happens is that the array on which the slice is built gets modified, which in turns modifies the slice(s) as well. Another thing worth remembering is to only append to a slice with the append() function.

On testing

I learned how to write tests. I guess there’s more to learn about them, but so far I’m doing OK. I’m writing a lot of repetitive things like this to get data providers:

for _, tt := range footests {
    r := Foo(

    if r != tt.out {
        t.Errorf("Got %d for %s, expected %d", r,, tt.out)

Even if there’s no shorter/better way to handle data providers in golang tests, I’ll just create some snippets and be done with all the copy/pasting.

I like that VS Code allows to run and debug a single test function. That’s really helpful. It shows small “run test” and “debug test” links above every test method. Click and off we go!

On packages

I haven’t yet learned how to properly work with my own packages, how to organize code and name packages to import one into the other, but I didn’t really had the need for it.

What I did learn, is that I can’t name a function like an existing package. For example, I wrote my own little function called sort, which made it impossible to import the sort package from the standard library.

All in all, I’m making good progress with both the AoC puzzles and with golang. I believe this will give me a good foundation for further learning and improving. There’s still a long road before me, but I feel I’m on the right track.

Happy hackin’!

Reading from standard input with Go

published on October 30, 2017.

Last year I started learning Go, then I stopped, and now I don’t remember anything what I learned.

Going to try it a bit different this time, by writing down what I do, learn, experiment.

As I don’t have a specific thing I want to build with Go, I’m just going to do simple scripts and examples, to get to know Go’s language specification and built-ins as much as possible.

Hopefully, there won’t be too much mistakes in my code samples. I’ve set up a golearn repository just for this, so feel free to create issues/PRs telling me where I went wrong.

Setting up the Go environment

I installed Go to the location that the official docs recommend — /usr/local, and I created the “Go workspace” in ~/projects/gocode and then I put my code under ~/projects/gocode/src/

I do find it kinda weird that everything lives in one “workspace”. But, whatever.

As for the editor, I’m using Visual Studio Code with the Go plugin.

I first tried using the vim-go plugin, but I couldn’t make it work in a custom runtimepath. I didn’t want to brick the Vim setup I have for my day-to-day work, so that’s why I tried a custom location.

Next I tried the Gogland from JetBrains, but when I ran it, my laptop sounded like a jet when the fans kicked off, so… yeah.

Then I tried Visual Studio Code, installed the Go plugin and I was pleasantly surprised when the editor figured out I was missing some Go programs like gofmt, golint, etc., and offered me to install them all. Great user experience for newcomers to Go.

About those docs…

After printing out the required “Hello, world!” to the terminal, I set out to figure out how to read in stuff from the standard input.

I would really love to say I figured it out all on my own how to do it, just by reading the official documentation, but I couldn’t. Maybe I don’t know how to use Go’s docs, maybe I’m spoiled by PHP’s excellent documentation, but after an hour or so flipping through the docs, I ended up Googling the solution.

From the documentation, I couldn’t figure out does the solution lie within the io, or the bufio package. Maybe both? I’ll have to tinker with them some more to understand the difference between the two.

From all the answers I found on the internet about this, I went with what seems the simplest way of reading from standard input: using a bufio.Scanner. Again, I’ll have to poke more around this, to see all the different ways I can accomplish this and compare the solutions.

The first “program”

The goal is to read whatever the user types in to standard input, line by line.

First, I have a slice of strings. Not an array, but a slice. I believe the main difference is that an array has a set size, while a slice’s size can change during execution.

// Inputs holds the inputs read in from stdin
type Inputs []string

I’m not yet 100% sure does this create a new type “Inputs” which is composed of a slice of strings, or is it just a slice of strings named “Inputs”? I think it’s the former, because I can use it as a return type-hint in a function.

Then in the main() I get a new scanner for the standard input:

scanner := bufio.NewScanner(os.Stdin)

It returns a pointer to the Scanner, so I pass it as such to my ReadInput function:

is := ReadInput(*scanner)

The ReadInput function takes a scanner of bufio.Scanner type and returns Inputs:

func ReadInput(scanner bufio.Scanner) Inputs

I declare two variables, one to hold the string read in from stdin, the other to “collect” all the input strings:

	var t string
	var i Inputs

Then I create an endless for loop, from which I break out when the user enters a new line only. In this loop the Scanner scans the stdin, and gets the text from it. If the text entered is not empty, I append it to the Inputs, as it is a slice of strings:

	for true {
		fmt.Print("Add a new todo [empty to stop reading]: ")
		t = scanner.Text()

		if err := scanner.Err(); err != nil {
			fmt.Println("Error reading from input: ", err)

		// scanner.Text() strips new lines
		// so in case of just a new line
		// it's actually an empty string
		if t == "" {

		i = append(i, t)

and finally I return the Inputs from the ReadInput function:

    return i

Back in main I do a “sanity” check by printing out the number of lines read in, and printing them out one by one:

	fmt.Printf("Got %d inputs from stdin:\n", len(is))

	for _, v := range is {

When executed, it looks something like this:

$ go run readstdin.go 
Hello, world!
Add a new todo [empty to stop reading]: Learn go
Add a new todo [empty to stop reading]: Write blog posts
Add a new todo [empty to stop reading]: 
Got 2 inputs from stdin:
Learn go
Write blog posts

The entire file is available here.

With this I learned a bit about Go’s types, creating functions, using the for loop, pointers, slices vs. arrays, and, of course, reading stuff from the standard input.

Happy hackin’!

P.S.: It feels good to have a beginners mind, again, about something.

Things I learned in the past four years

published on December 30, 2016.

Since yesterday was my last day on a project after four years and two months, I decided to take a look back on those four years and write down some of the things I learned.

Things I learned about being a better listener, a better communicator, a better team mate, a better programmer.

Leave your ego at the door

This is probably one of the hardest and most important lessons I learned. I’m happy that I learned it early into the project.

Ego gets into the way of the actual programming. There is no place for it. People get defensive about their code, become deaf to advice, don’t take criticism well. This slows down the
development process, makes communicating difficult, if not impossible.

Criticism of my code is not criticism of me. If I submit a pull request and the reviewer deems the code not fit for inclusion into the project, there is nothing to get upset about. The
code needs improvement. If I know how, I’ll improve it, if not, I’ll ask for help how. It is much better and efficient than getting all protective about the code.

Don’t play the blame game

Joe wrote an excellent piece on the blame game more than 3 years ago.

Removing the blame from the entire process is liberating. When dealing with a problem, don’t focus on trying to find the person, or persons, responsible for the issue at hand, but try
to understand what caused the problem, what is the best and fastest way to solve it, and how to prevent it from happening again in the future.

I know I was lucky to be working on a project where this blame game was not being played and that there are a lot of teams and companies where there’s a ton of office politics and
everyone wants to survive… But that stuff really isn’t helping any one. If possible, at least try to not play it within your team, with your closest coworkers.

Take responsibility

Admitting to a mistake is hard. It’s scary.

Admitting first to myself that I’m not infallible, that mistakes happen makes taking responsibility a lot easier. And it becomes easier over time.

I believe that people tend to react positively to sincerity. Being honest and upfront that I made a mistake, saying sorry, goes a long way. Yes, the mistake might have repercussions,
but I’m an adult and I stand by what I did.

Taking responsibility is the professional thing to do.

It’s OK to say I don’t know

I don’t know.

I’ve said it a lot. I’m still here, still alive, the world didn’t come to an end. No one punished me for it. The only thing that happened is that I learned new things I didn’t know
before. And guess what? Learning new things is part of the job.

Saying “I don’t know, can you show me please?” is perfectly fine. If we ask for help, we will get it. People like helping.

Knowing the business domain is important

We, programmers, are a smart bunch of people. We solve problems for a living. Without knowing what is the actual problem the business is trying to solve and just waiting for others to
give us a solution which we need to translate into code, takes away the problem solving for which we initially signed up for. The business will also miss out on properly utilizing the
experience we gained so far.

Understanding the core domain makes it possible to give ideas, work together with other people (not necessarily programmers) to come up with better solutions. Everyone will benefit
from this. The business gains by having yet another smart person helping out, and you by learning new things.

Not everything we learn need to be exclusively about code.

Ask why?

This goes hand in hand with knowing the business domain.

Keep asking why. Why is some new feature being implemented, why do they need it? If you are joining a project that is being developed for some time, ask why were some things done in a
certain way. It will both make learning the business domain easier and faster and it will also help with getting to know the codebase.

Asking why shows the business owners that you care, and caring about the same things as they do will only be helpful during the project’s lifetime. They will provide help and
explanations much easier.

Onto new adventures

Working on this huge project for this long is something I’m truly grateful for. Not everyone gets an opportunity like this, especially this early in their professional career.

I learned a lot from my friend, partner and mentor, Srdjan, as well as from Luka who joined our small team recently.

I’m certain the new year will bring us exciting new challenges. If you have, or know of a project where the three of us could help out, let us know.

The Code4Hire team is here to help.

Learning English

published on March 29, 2013.

Most of my knowledge of the English language is self-taught. I had English classes in elementary school, but that was more or less singing "London bridge is falling down" and reciting a list of irregular verbs. I also had a semester of English in college, but that again consisted of reciting a list of irregular verbs (true, this time the list was longer) and reading and translating engineering texts. Good for learning how to read a technical manual, but not so much when it comes to having a conversation with other people. Other than that, it's all from computers, music, films, books.

My mom has an old dictionary that I used to read when I was a kid. I remember spending hours upon hours flipping through the pages, learning words, trying to figure out how to pronounce them. Guess I was a nerd already when I was only seven years old.

In the past few months Swizec was quite persistent with his nagging of how terrible my English is, especially when it comes down to the grammar, so I decided to do something about it.

I started taking private English classes.

I had my first hour and a half long lesson yesterday evening. I enjoyed it very much, had a lot of fun and already learned a thing or two (at least I think I did). I am taking the classes from an English teacher who also happens to be my friend. But, don't let the friendship fool you! She's not afraid off bashing me when I make a mistake: "Hold on Robert! That sentence doesn't make any sense!" (or something along those lines). And I think it is actually a good thing that we know each other from before as it is much easier to just start a random discussion and not just go through the textbook examples. All in all, very enjoyable classes and I know I will learn a lot from them.

And to show that I am really serious about this, I started another blog dedicated to writing called Magic of Writing. And yes, I am aware that that sounds something like a five year old would come up with, but then again writing is magical. There's not much there yet, but I already have a few ideas in my head that will hopefully find their way onto paper.

Let's learn Astronomy!

published on September 29, 2012.

I've graduated from Subotica Tech back in 2009., and earned a BsC in electrical engineering, or some such. Even though I had the opportunity to continue my academic studies, I decided that I had enough of schools for a while, and that I should start working. Turns out, that was a pretty smart move from my side, as I ended up working for two years with an awesome team, and later on started my own company, which is now over a year old! Yey!

But, recently I started thinking about going back to school again. Not for a new diploma, or to be able to get a better job, but for the knowledge itself. My brain craves Science. Mathematics. Formulae. My mind needs a new challenge. Sure, I could learn a new programming language, I hear Haskell would give me quite a challenge, but at this point, that just wouldn't be... It.

Introduction to Astronomy

A few weeks back Vranac sent me a link to Coursera's Course Catalog. I browsed through it, made a note about a couple of interesting ones, and left it at that. Until yesterday, when Andries brought up the subject of gaining new knowledge. For some odd reason, that made me do a step forward.

Thus, I singed up for the Introduction to Astronomy course. Why Astronomy? Because it should have a fair share of math and physics which will, hopefully, prove more than enough for my science hunger. Plus, learning things about planets and stars and galaxies cannot be anything else but fun! Maybe I even learn to recognize a constellation or two in the night skies.

I don't really know what to expect from the course itself, but it should be a good starting point as any. The description says it's a difficult course, lasts for 9 weeks, and has three hours of video lectures per week with additional homework and quizes. Guess it'll be interesting, we'll see.

Happy learnin'!

P.S.: I forgot to mention that these courses on Coursera are on-line, and free!

Robert Basic

Robert Basic

Software developer making web applications better.

Let's work together!

I would like to help you make your web application better.

Robert Basic © 2008 — 2020
Get the feed