Forem: 21 Lessons

The Customer and Boring Tech

21 Lessons — Sat, 03 Oct 2020 01:07:56 +0000

For a long time, I really hated on Ruby on Rails. It did too many things, too much magic, not following idioms, etc.

From a developer perspective, these were all valid points. If I was to come up with a solution that’s abstracted in a better way, has less magic, then it’d be more valuable than Rails. That it probably would take longer wasn’t a concern. I was a Software Developer and it was my job to deliver well-designed and abstracted solutions.

My point of view has changed over the last years. Direct interaction with customers has taught me a lot.

The customer doesn’t really care if I used Rails, Django, Sinatra, or a custom-built web framework. It just needs to do its job.

I use Rails whenever I can to get the job done faster and more reliably, whenever I can. Technical elegance is not as important anymore as a happy and productive customer.

The SSH Beginner’s Primer

21 Lessons — Mon, 29 Jun 2020 12:44:55 +0000

When I decided to leave Windows Desktop App Development for Web Development, I opened up to a whole new world. First of all, learning Ruby, improving my HTML and CSS knowledge, but also working on Mac + Linux instead of Windows.

On Windows, I deployed applications to either a Network Share or an IIS (Internet Information Services, Microsoft’s Internet Web Server, competing with Apache and NGINX) instance. Both required either the Windows explorer or a Remote Desktop Connection.

In this new job, we deployed our Ruby applications to Linux Servers. I had used Linux before on my computer, but this was different. As it turned out, Linux servers don’t have any graphical user interface. The only available interface is the command line. To connect to a remote Linux server, we also wouldn’t use Remote Desktop but SSH (Secure Socket Shell). For me, SSH was a steep learning curve because it came with so many things all at once.

General SSH Concepts

SSH allows us to connect to a remote computer. Usually, that remote computer is a Linux machine, but it also works with macOS and even Windows. When we connect to that remote machine, we have terminal access to it, and can execute commands. It looks and feels like executing commands on our local machine.

One of the key features of SSH is that the entire connection is encrypted. If somebody was to listen in on the network traffic, they couldn’t see the commands you executed or any of the results that came back. Previous remote access protocols didn’t have this feature (e.g. telnet).

To ensure this level of security, SSH uses Key Pairs. An SSH Key consists of two files, a public, and a private file. The private file stays on your computer, and the public part lives on the remote machine you want to connect to.
Why two files though? The reason for that is that SSH uses asymmetric encryption (Read more here about asymmetric encryption).

Step 1: SSH Keys

Before we can log in to any remote computer, we need to generate a new SSH key pair. Linux and macOS have tools preinstalled, for Windows you either need to install ssh manually or use WSL (Windows Subsystem for Linux) as I do in these examples.

Open a new terminal and make sure that you’re in your home directory:

Now, we use a command to generate a new key pair:

$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Once you hit return, ssh-keygen will ask a few questions:

Let’s look at this a bit closer:

At first, it’ll ask for the absolute filename. In this case, it suggests /home/jan/.ssh/id_rsa. If that looks good, press return, otherwise specify a new path.
An SSH Key can be protected by a passphrase. Then, whenever you want to use it, you need to type in the password first. It adds an additional layer of security on top and I highly recommend using a password.
That’s it! Now, your key is ready to use.

Where does it live though? By default, all SSH Keys are stored in .ssh, which is located in your home directory:

Before we move on to the next step, let’s example the screenshot above a bit closer. You see, that both id_rsa and id_rsa.pub have very restrictive file permissions. Why is that?

These restrictive permissions protect the key from any unauthorized use. That means, the key can only be used by us and not anyone else who might be using this computer. Otherwise, another user on this computer could log in, copy the keys out of our home directory, and impersonate us. Therefore, SSH Keys by default are restricted to our own use only. In fact, the ssh command refuses to use these keys if the file permissions are too permissive.

Connecting to a remote machine

What do we need to connect to a remote server?

Its address, which can be either an IP Address (e.g. 192.168.0.1) or a host name (myserver.example.com)
A user on that machine
A key configured on the machine

Let’s connect:

$ ssh myuser@myserver.example.com -i ~/.ssh/id_rsa

This will open a new connection to myserver.example.com and create a terminal session as myuser. We tell the ssh command which key to use via -i ~/.ssh/id_rsa.

From then on, we can run commands on that server.

Associate an SSH Key with a User

Before we can connect to a new server for the first time, we have to associate our key with a user on that machine. Otherwise, every connection attempt will result in a “Permission Denied” error.

The server rejects all connection attempts with keys it doesn’t recognize to prevent malicious activity.

How do we configure an SSH Key though? On the server, each user has a .ssh directory within their home directory. On our local machine, .ssh has all our SSH keys. On the server, we find a single file: authorized_keys.

This file contains a list of all public keys that are allowed to connect. Our key needs to be in this file as well.

How do we get it in there though? On an existing server, we ask somebody who already has an account who then configures the public key for us.

If this is a brand-new server, you can add it through your hoster’s web interface (in my case, DigitalOcean). They then will take care of adding the key to the machine once it’s created.

I’m curious, did this guide help you? What other questions about do you have? Let me know down in the comments.

This post was published first on 21 Lessons

Learn a new Programming Language

21 Lessons — Thu, 06 Feb 2020 04:02:41 +0000

This post was published first at https://21-lessons.com/2020/02/05/learn-a-new-programming-language/

When you learn your first programming language or an additional one, have you wondered where to start learning?
A programming language comes with a lot of features, syntax and language constructs. If you look at it for the very first time, it can all be intimidating.

Over the last 13 years I learned something between eight and twelve programming languages. Looking back at it, I’d like to share my method with you.

Step 1

Install the language on your computer. Most languages have an installer on their website that works for your operating system.

Step 2

Open the language’s documentation website. Most programming languages have a documentation on their website that walk you through the basics.

Step 3

Read about these topics in the documentation

How to run Code in this language
- Does it need to be compiled?
- Is there anything else you need to take into account?
- What is the basic program structure?
Variables + Variable Declarations
- How do you declare variables
- How do variables work in this language? Are there any special behaviors to take into account? (Variables behave very similar in many languages but here and there this can differ)
Data Types
- What kind of data types does the language offer?
Assignments
- How do you assign values to variables? Is there anything to take into account?
Expressions vs. Statements
- How do Expressions and Statements work in this language? What’s the syntax?
Functions
- What’s the syntax for functions and how do they work?
Loops
- What kind of loops are available? for, while, …
Conditionals / If Statements
- How do Conditionals / If Statements work? Are there other types of conditionals the language offers?

Step 4

Write the first programs to apply all of these features. These programs should be small and are only meant to exercise the new knowledge. Once you become more comfortable with the new language these serve no purpose anymore.

Step 5

Once you become more familiar with the language basics, you can start to read and learn about the more advanced features. Advanced features can be:

Classes
Macros
Higher-Order Functions
Meta Programming
Reflection / Introspection
…

I’m curious to hear from you how this method works for you or if you have a different approach. Comment below and share your thoughts!

If Hemingway Wrote JavaScript

21 Lessons — Sun, 29 Dec 2019 18:15:49 +0000

This Post originally was published in the Junior Dev Insights Newsletter. Sign up here to receive more of these every week: https://learn.21-lessons.com/junior-dev-insights

It is better to learn JavaScript late than never to learn it at all.
- Sir Arthur Conan Doyle

This is a quote from "If Hemingway Wrote JavaScript". If you haven't read it, it's showcasing JavaScript Code as it had been written by famous book authors such as Virginia Woolf or Franz Kafka. It's humoring to read the code and the comments, written in a similar fashion as their books. Every chapter is about solving a particular programming problem such as writing a function that returns the Fibonacci numbers. Then, a handful of authors showcase their solution.

I like the book very much for the excellent stories but also because it's illustrating pretty well that there's always more than one solution available for a given problem.

I spent a good deal thinking about the reasons why this book is so fascinating.
When I grew up, I got taught implicitly that there's always a definite solution for a given problem or task. Any deviation would cost points. I had a hard time learning this but also an even harder time to unlearn it again when I started with programming. When you're sitting in front of the computer and wondering how to write these specific lines of code in the best way, it's up to you to figure out the best way. Most of this will come from experience. Going over the same code over and over again, you develop a feeling for readability but also maintainability.

There are standard applications that solve common problems such as spreadsheet calculations or word processing, but there will always be the need for more niche solutions. It's a bit like the Red Ocean vs. Blue Ocean Strategy. In short, the red ocean describes a world where market share is finite, and in order to increase your share you need to compete with others.
In contrast, the Blue Ocean describes a world where there's uncontested market space, without relevant competition. The latter comes with a mindset of finding solutions that might not be standard, not written down in any books. It's a "thinking out of the box" exercise where you need to combine various aspects from existing methods or procedures to create something new. It's challenging, because of the lack of definite instructions but also exciting. You get to design the world as you like.

In order to get there, you need to build up your own personal toolbox. This consists of Design Patterns, patterns you learn from other people's code, knowledge of available libraries and so on. This helps to build up knowledge you can draw from when the next new project comes your way.

Three Core Skills

21 Lessons — Mon, 16 Dec 2019 23:01:26 +0000

This Post originally was published in the Junior Dev Insights Newsletter. Sign up here to receive more of these every week: https://learn.21-lessons.com/junior-dev-insights

Becoming a software developer is an ambitious goal. It takes time, practice and patience. When you start out, one of the first things you start to learn is a new way of thinking: How can I break down these problems into manageable pieces for the computer?

You get familiar with your first programming language, its features, strengths and weaknesses. Your first language, together with the skill of breaking down problems helps you move forward.

But then, there's another skill that you might not be aware of: Learning how to Learn. This is crucial. It is even more important than knowing the In's and Out's of your first programming language. It is the skill that will keep you in the game.

Simon Sinek talks a lot about Finite vs. Infinite Games. (Most Leaders Don't Even Know the Game They're In | Simon Sinek at Live2Lead 2016). Quoting his definition from the linked video:

A finite game is defined as a game with fixed rules, known players and an agreed-upon objective (i.e. Soccer or Baseball, the player or team with most points win).
The infinite game is defined as having known and unknown players, the rules are changeable and the objective is to play to keep the game going. The only way a player drops out is when they lack the will or resources to play.

When I grew up, I was told that getting an apprenticeship after school is the way to go. One would train for three years and once finished, hopefully the company offers you a contract that lasts until retirement.
You learn once and draw from that knowledge for the rest of your professional career. According to old standards, this would be considered a win - winning the finite game.

Today's landscape is different. The world is changing faster than ever. For us software developers, this means that new versions of programming languages get released more frequently and new libraries and frameworks pop up every day. It's very likely that we get in touch with new technology almost every week, even every day.
There's no chance to "win" this - to know enough so that you don't have to learn anymore. Instead, our objective is to stay in the game.
That requires a different mindset compared to the idea of learning once and benefiting from that knowledge until retirement. When we don't know something, that's okay. We need to develop tools and strategy to master new programming languages, tools and frameworks.
Let's say you want to learn a new programming language. The first step is to check out their website, install it on your computer, then reading the first tutorials. Additionally, you start to look for tutorials via Google and YouTube to get better. Also, for the major languages, there are a lot of well-written books available.
The information is there, what matters is how you consume them.

What is your strategy to learn new things in Tech? Reply to this email and let me know.

Computational Thinking / Algorithm Design

21 Lessons — Sun, 15 Dec 2019 20:50:05 +0000

The third part of Computational Thinking is the most important one: How do you design an algorithm?

It all starts with the idea for a new program. The problem is well understood and already broken down into smaller problems. You've already identified a few recurring patterns.

An algorithm helps you to break down a problem into concrete steps for the computer to execute.
Let's say you're tasked with determining if a given email address has the right format. The input parameter is an email address a user has filled into a web form. The algorithm needs to return true or false. Does the address include an @ sign? If not, return false. Does the address include a top-level domain? If not, return false. And so on.

What are your thoughts on this? How did you learn to design algorithms?

21 Lessons helps Junior Developers to level up their skills step by step via their weekly newsletter. Do you want to get out of Tutorial Hell or you're wondering how you develop the skills to write sophisticated programs yourself? Sign up and receive weekly articles and recommendations right in your mailbox.

Computational Thinking / Pattern Recognition

21 Lessons — Sun, 15 Dec 2019 01:23:08 +0000

Let's talk about the next part of Computational Thinking, which is Pattern Recognition.

A big part of the daily developer work is dealing with patterns. Sometimes it's more about patterns in data such as (75% of people who bought a croissant also bought a Latté), other times you focus more on patterns in your code.

A common pattern could be that the user input always need to be validated before it can be saved. You first implement this code in the insert method, but turns out that the same code is also needed for update as well.

Detecting these patterns can help you to make more informed decisions about how to write code. This also sometimes involves higher abstractions, as in making sure that the code for validating user input is only written once and can be called from multiple places.

Can you relate to this? Is there more from your side that goes into pattern recognition? Comment below!

Computational Thinking / Decomposition

21 Lessons — Fri, 13 Dec 2019 19:00:54 +0000

I started to sketchnote a while ago, mostly focused on topics that are interesting and relevant for beginners. In my head I had these thoughts about these core skills you need besides your first programming language. After lots of googling, I finally found out the term for what I was looking for: Computational Thinking!

There are a few aspects to Computational Thinking and here's the first one:

Decomposition - or how to break down a complex problem into smaller, more managable problems.

Let's take a TODO Application as example and break it down into its pieces. Part one is creating the user interface, followed by making sure that the UI reacts to user input such as button clicks or text inputs.

Then, we only accept TODO items that actually have a text. We don't want any empty items on the list.
For now, we're only saving them in memory. The last step is to render all TODO items that are stored in memory.

How do you get your first Job in Tech?

21 Lessons — Wed, 11 Dec 2019 21:29:07 +0000

There are a lot of ways to get hired into your first software development role. Today, I want to share mine with you.

I've been practicing a lot of programming while I was still going to school. I found it fascinating what I could create with Code.
I started to learn C# in 2008, because my Dad offered me some work in his business, using C# and .Net. There was another developer who also worked for him, using C# as well. So, with me also using it would allow to work together.

Over two years, I created a lot of projects. Most of them were "Just for fun", because it scratched an itch like "I'd like to manage my notes and ideas properly" or they served the purpose of practicing new language features, design patterns and so forth.

But a few of them, mostly the ones I wrote for Dad, were used by other people. These were the hardest ones to create and maintain, but in retrospect also the best ones.

In 2010 I had to start working, mostly because a few other options I had lined up after school didn't work out.
Most of the job ads weren't written for somebody like me. I went to a professional college, didn't have full-time work experience, and no experience with tools like version control yet (though I knew about it and what it's good for).
I applied anyways. As expected, most companies rejected me right away. But a few extended the invitation for an interview. Why did they invite me for an interview, even though I didn't match the criteria they had outlined in their ad?

My Dad had recommended to me that with my application, I include a list of projects I had worked on. This list contained most of the projects that were used in Dad's business, plus a few of my own worth talking about. I included the project's name, a brief description and the technologies used.

During these interviews, we would come to talk about my projects eventually. Common questions were "What does it do? What problem does it solve? Explain it to me" or "What did you learn during development? What were the obstacles?". I explained the project's purpose, what technologies I've used and why and also what I've learned from it.

The company that eventually hired me also had a questionnaire filled with questions around C#, .Net, SQL databases and a few other Windows technologies. Most of the questions were multiple choice, as far as I remember.
I also remember that I asked to skip two entire topics because I had no experience with that whatsoever.

A few months later, my boss shared his thoughts on what they've hired me., I got hired because I was upfront about what I knew and didn't at the time, together with the experience I had gathered with these side projects.

Now, what can you take away from this for your own journey? Here are the three learnings:

Make a list of things you want to learn, like "How do I use the Observer Pattern?", "How do I pass data from one dialogue to the next one?"
Create small projects for each one of these list items. These projects don't have to be completely polished. Their only purpose is to help you progress your learning. If there are unfinished parts, that is okay and part of the exercise.
For your job application: Make a list of projects (include GitHub Links if possible), together with a brief explanation and technologies used. Use this as a basis for further conversation during the interview.

If you like to read more of this, make sure to subscribe to https://learn.21-lessons.com/junior-dev-insights