Archive for the 'Blablabla' category

Free the Geek interview

published on January 12, 2018.

Last year (feels weird to say “last year”, when it was less than a month ago) Matthew asked me if I’d be willing to appear as a guest on his Free the Geek podcast. To have a short chat about running my own software consultancy, freelancing, public speaking, and whatever else pops up.

Matthew is a great host, I have no idea why I was so nervous while chatting. Maybe because he also interviewed people like Matthew, and Matthew, and Chris, and Chris, all programmers that I learned and keep learning a lot from?

*wipes sweat off brow*

In the end I’m really happy that I did this, if nothing else, because now I’m even more determined to improve my public speaking skills, to talk more at local meetups, to submit to more conferences.

Anyway, have a listen to our chat, and make sure to subscribe to the podcast, I’m sure Matthew will have more great guests we can all learn from in the future.

Happy hackin’!

Tags: about, interview, podcast.
Categories: Blablabla.

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 (
	"fmt"
)

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)

	F(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 {
		z[k]++
	}
}

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(tt.in)

    if r != tt.out {
        t.Errorf("Got %d for %s, expected %d", r, tt.in, 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’!

I think I understand bounded contexts

published on October 24, 2017.

Earlier this year I started reading the DDD book by Eric Evans. Together with the Eventsourcery videos from Shawn McCool, the first three chapters of the book were… easy to understand, even.

Lots of “A-ha!” and “Oh!” moments, followed by “That makes perfect sense.” statements, and a couple of excited “I knew that!”-ones.

Then I got to the chapter with the bounded contexts. I read the first few pages, thought about them… Then read them again, and thought some more. Then I put the book back on the shelf for a few months.

Last night I read it again, and then…

Click!

A bounded context is a point of view.

A bounded context defines how a section of a business sees, thinks, talks about a subject that is important to that section of the business. And we represent that business subject with a model.

That same business subject can be present in different sections of a business, but every section views it differently. To some extent, at least.

That is the reason why the context of a model is important — we need to know how to model a subject for that specific business section.

And we need to put boundaries on those models — we must prevent the mixing of, what might seem same, models between these contexts.

A book is a book, right?

Depends on who you ask.

If you ask a publisher, a book has a title, a writer, a cost, a price, and a category.

If you ask a seller, a book has a title, a writer, a cost, a price, and a category.

They talk about the same things, right?

For a publisher a book has a working title, and a published title. For a seller a book has a title.

For a publisher a book has a writer, who needs to be payed. For a seller a book has a writer, which is just a name on the front cover of the book.

For a publisher the cost of a book includes the cost of the writer, the editor, the designer, the printing, the binding. For a seller the cost of a book includes the buying price, maybe some discounts from the publisher on the quantity purchased, the paychecks of the store clerks, bills for running the store, taxes…

For a publisher the price includes the producing cost plus the profit they want to make. For a seller the price includes the buying cost plus the profit they want to make, and maybe some discounts they want to give to buyers.

For a publisher the category can be fiction and non-fiction books. For a seller the category can be epic fantasy, sci-fi, horror, thriller, programming, design, recipe books…

See where am I going with this?

Depending on the point of view, depending on the context, the same book can mean two different things for two different business sections in the business of selling books. Even if at first we might think there is no difference, once we start talking to the business people, these differences will pop-up.

We should also respect the boundaries between these two contexts, so that we always know about what cost or what price we are talking about.

Otherwise, the seller would quickly run out of business if they’d sell books at the publisher’s price.

This is just a model

Of course, there is more to bounded contexts, models, DDD, etc., than what I wrote here.

More to read, more to learn, more to think, more to write.

Happy hackin’!

Bug triage, the paperwork of open source

published on May 24, 2017.

Everyone loves contributing patches to open source projects, adding new features. Some even like to write documentation.

Probably the least talked about way of contributing to open source is triaging issues (I have no data to back this statement, so I might be wrong!).

I do believe however that it can be the biggest help to project maintainers, because with issue triage out of the way, they are left dealing with the “bigger” problems of the project, such as fixing difficult bugs and implementing new features.

Ideally, a good issue report will include the version numbers of the affected projects, a good description of what the user tried to do, what did they experience, expected and actual results, any logs or stacktraces, and even the smallest possible test case that reproduces the issue being reported.

I say ideally, but that’s not always the case. Sometimes the report has a lot less details, does not include version numbers, or any other information that would help identifying the underlying cause of the issue. In those cases someone needs to go through the reported issues and ask for more information.

It’s paperwork

Issue triage boils down to going through the list of open issues for a project and making sure that the reports include as much as possible useful information. If the reporter hasn’t provided everything needed, we should ask them for more details.

If the initial report includes just enough information to start investigating, we could that as well. Start digging into the codebase and try to figure out what’s going on. If the project has automated tests, we can use them to get a better picture of the issue, and maybe even provide a failing test case to the maintainers. Fun fact: this is how I started with unit tests and test driven development - by submitting failing test cases to projects.

When we deem that we have enough information, we can try to reproduce the issue, and confirm or deny its validity.

Some issues are not really issues, but a case of misconfigured library, or documentation not being read fully. In those cases the solution is not to leave a “RTFM” comment and close it. Asking if they read pages X or Y, is a much better approach. It might be that the documentation is not detailed or clear enough, so we need to update our docs.

Sometimes it’s the lack of documentation that is the real issue.

Once we have enough information, we can leave a comment for the maintainers saying that we managed, or not, to reproduce the bug. From there the maintainers can take over and deal with the issue as they see fit. Or we could attempt at writing a patch and fixing it.

Bug? Feature? Support?

Users will open all kinds of reports. There will be issue reports, there will be feature requests, and there will be questions asking for support.

Deciding on which is which is also a part of issue triage. Label them accordingly, so maintainers and contributors will have an easier time filtering them out.

If you are familiar with how the software works, you might provide an answer to a question and help the user, again taking of the load from the maintainers.

No experience required

One of the best things for me about issue triage is that we don’t need to have experience with the project, let alone be experts in using it. Most of this is communicating with others, asking for more feedback, and making sure that the persons who can decide on the reports can do so with least effort required. Of course, having experience does help, but that’s the way with everything in life, I guess.

Besides, this is also a great opportunity to learn more about the project and the ecosystem around it.

While the work is not grandiose, it will help in getting better at communication skills, it will help the project to move forward just a little bit faster, and it is a great way to contribute to open source projects.

Happy hackin’!

P.S.: Sometimes if you wait long enough, the reporter won’t even remember what the issues was, and they’ll just close the issue.

Everybody knows that

published on May 08, 2017.

Back in December last year, Matthew Turland published a blog post asking “Why aren’t you speaking?

It made me think.

What I realised is that I always havehad this feeling that everybody already knows what I know.

Is that part of an impostor syndrome?

I don’t know. I really don’t feel like an impostor. I know what I know, I’m perfectly fine accepting that I don’t know everything… but then there’s this feeling that everybody else knows what I know. It’s a strange feeling, I’m not even sure if I can explain it properly.

This also led me to realise why I don’t blog more often. I like blogging. I like writing. I don’t consider myself being a good writer, but with English being my third language, mostly self-taught, I think I do quite alright.

It’s the same thing as with me not speaking at a conference or a user group — everybody knows that.

After doing some more thinking on this subject, there’s only one logical result — it is not possible for everyone to know what I already know. It’s just not possible.

I have learned, and still am learning from other people, by either reading their blogs, or hearing them talk, or looking at their answers on StackOverflow, or digging through their code on GitHub… Surely there are others out there that can learn a thing or two from me.

I also “agreed” with myself that not every blog post needs to be an essay, that it’s OK to publish a couple of short paragraphs, quickly writing down the things going around in my mind.

With those thoughts, with that kind of a mindset, I set out to start blogging again. Since December, since Matthew’s post, I blogged 20 times. I don’t think I have written so many posts in the past 4 years.

Oh, and I gave a talk at two different occasions as well.

Thanks Matthew.

Tags: about, blog, blogging.
Categories: Blablabla.
Robert Basic

Robert Basic

Software engineer, consultant, open source contributor.

Let's work together!

If you require outsourcing or consulting help on your projects, I'm available!

Robert Basic © 2008 — 2018
Get the feed