One year at the helm of Vim

One year ago I started using an old text editor called Vim. I’m happy to say that I’m still sticking with it. I’m now very comfortable with VIM and more empowered translate Ideas into working solutions.

In this year I’ve become accustomed to working the terminal, embracing the VIM way while realizing that that coding is just one part of the challenge.

Continue reading “One year at the helm of Vim”

When are you proficient in a programming language?

Learning a programming language gives you the opportunity to explore other problem domains alongside new approaches to addressing familiar problems.

I write this as I was looking for the answer to exactly this question. There were many opinions that had me confused, some from ancient rockstar ninjas who command CPUS at will and others from earnest people who are also seeking.

Why would one ask such a question in the first place? It seems like the actual issue is 2 fold. For me it is firstly; when can this go on my resume. Secondly and probably more specific to me: when to move on to the next language or skill. When can I check off my to-do list and say that I know a programming language?

After looking at many other ideas, In my opinion: You are proficient in a language when you are able to read, understand and debug code along with deploying to production.

If you can read, write and execute you are well on your way and I would consider this profecient. Beyond this, optionally, persue mastery. Though in order to keep a language on your resume, make sure to continually read, understand and debug.

Link to other opinions: https://softwareengineering.stackexchange.com/questions/154862/at-what-point-can-i-say-ive-learned-a-language

Why I’m learning a new Programming Language called Go

For the past few years, I got stuck in a rut, a good one. My sole focus was not the technology I used. but rather the thought processes behind why and how I write code. I write in PHP and I mainly focus on the WordPress CMS. This pays the bills and helps me take care of my family but, while focusing on thought processes, I didn’t realise that learning a new language can have the same effect, helping me think differently about similar problems.

So why Go (#golang)? This one I stumbled upon by accident. A colleague of mine, Akeda, automated one of our workflows. Before this, we had a weird process involving multiple tools and steps. His script made life just a little easier. I thought one could improve it just a little bit more, but in oreder to do this I had to go digging into Go source code.

After hacking on this project and getting it “mostly working” I decided to dig a bit deeper into Go. I found out immediately that it was created by a few very smart people at Google. It is open source and has a very strong community. More specifically, Docker, the tool I use all the time, was written in Go(mind blown gif goes here).

With Go you to create systems software. I know my way around PHP and this is great, but there are a few things an interpreted language simply can’t do. This presented me with another opportunity to learn.

Go is written in Go! Yep, that means you can eventually read and contribute to any bugs in the language itself, if that’s something you’re interested in. I think it’s great that one only needs to learn on language to get involved with an entire commuinity.

Learning GO is free, no need to buy expensive books. Do the tour, then work through How to write go code and then read Effective Go. After this, you can start using the language. If you are new to programming you may need more help.

With Go, most of the tooling forms part of the language. The following things are already included: code documentation generation, testing, dependencies etc. In most languages I know these are third party tools. They may not work exactly how you want them to, but they work and they remove the burden of having to choose between third-party options. Though third-party options are available, the idea is that everything you need to be productive should be part of the language.

New languages force us to think differently about the same problems, as per this stack overflow answer:

It’s not about the next “new thing”. It’s about thinking in different ways outside of your normal thought patterns

I hope this inspires you to pick up a new language. There are so many to choose from.

Featured image is a gophers, the Go mascot. It was created with https://gopherize.me/. Creating a unique gopher.

Technology does not make us any better

Technology didn’t make our lives better, it simply changed what we can accomplish, but it seems, humans are still very much like we were 100 year ago:

Greedy, Selfish, Looking to impress, Wanting to do good, Doing good and so the list goes on.

We now only have better tools. Tools that allow us to do more harm and more good. But this is just more of the same. More of what we’ve always been doing. More harm but also more good.

They say it is exactly the same with money. Money doesn’t make you bad or good it just amplifies who you already are. Money gives you more options, but which ones you choose largely depend on who you are.

It all balances out in the end. We should not look to technology to make our lives better, we should look at how we treat the people who can do nothing for us. That is who we are. If we can better that, we can better ourselves.

Microservices Are Something You Grow Into, Not Begin With

The craze around microservices is great, but starting small and simple is the best use of our limit time, specially when starting a new project, More on this from the link below:

https://nickjanetakis.com/blog/microservices-are-something-you-grow-into-not-begin-with

Golang Channels: explained simply

I see go channels as a pipe connecting two air tight vacuum cleaners. One vacuum cleaner can not push anything into the pipe, if the other vacuum is not pulling from the pipe. Both need to do the opposite action. If one sends the “package” will be stuck until the other turns on it’s receiving action.

Channels can contain multiple slots for “holding” the “packages”.

Pushing more into the pipe than wha the pipe can handle results in a broken pipe.

I also think of it as a queue, first in, first out ( last in last out ). The only difference is this one is ultra sensitive and very particular.