DEV Community: Juha-Matti Santala

Learning Rust #4: Parsing JSON with strong types

Juha-Matti Santala — Wed, 12 May 2021 18:30:44 +0000

Last December I finally started learning Rust and last month I built and published my first app with Rust: 235. Learning Rust is my new monthly blog series that is definitely not a tutorial but rather a place for me to keep track of my learning and write about things I've learned along the way.

One big difference with Rust compared to Javascript and Python that I've been writing for most of my career is strong static typing. With JS and Python, I'd just call an API, get some data in JSON, parse that into a Python dict or Javascript object and then access different values directly.

With Rust, I'm working with differently typed structures and while I understand the value of it, sometimes it feels very cumbersome to write.

I started with serde_json::Value

When I started working with Rust to build 235, I decided to use Serde that seemed to be a popular library for serializing and deserializing data. While I was still learning the basics, it felt overwhelming to figure out the correct way of defining types for the entire API response. I decided to leave that as a refactoring exercise for a later day and started by using serde_json::Value, which is kinda a catch-all solution. It is an Enum that represents any valid JSON value.

#[tokio::main]
async fn fetch_games() -> Result<serde_json::Value, Error> {
    let request_url = String::from("https://nhl-score-api.herokuapp.com/api/scores/latest");
    let response = reqwest::get(&request_url).await?;
    let scores: serde_json::Value = response.json().await?;

    Ok(scores)
}

Here's my original fetch_games function that called the API and parsed the data into a serde_json::Value. Nice and clean, easy to use.

But it led to my code being full of code like this

let games = scores["games"].as_array().unwrap();

let home_team = &game_json["teams"]["home"]["abbreviation"].as_str().unwrap();

let all_goals = game_json["goals"].as_array().unwrap_or(&empty);

I had to code very defensively because any type conversion with as_ methods could have fail and thus needed to be unwrapped and in some cases, made sure the keys even existed in the beginning:

if (&game_json["teams"]).is_null() {
  return None;
}

let home_team = &game_json["teams"]["home"]["abbreviation"].as_str().unwrap();
let away_team = &game_json["teams"]["away"]["abbreviation"].as_str().unwrap();

Using serde_json::Value did help me build the first functioning versions of my application but in the back of my head I had the knowledge that defining the structures as Rust structs would make my code better.

One key thing that kept me from doing that in the beginning was I couldn't figure out how to deal with dynamic keys. The API I use uses team abbreviations as keys on certain places and I had no idea how to do it so I left the issue for months.

How to define structs for JSON

Using custom structs to define expected types with JSON is rather straight-forward if you're familiar with structs.

I'll start with the example from the documentation:

#[derive(Serialize, Deserialize)]
struct Person {
    name: String,
    age: u8,
    phones: Vec<String>,
}

Here we define a Person that has name as String, an age as u8 and a list of phone numbers as Vec<String>. Once we have this definition, all we have to do is to use that as a type of the result and serde_json and Rust will validate that the structure and types of data matches what we defined:

// Parse the string of data into a Person object.
let p: Person = serde_json::from_str(data)?;

// Do things just like with any other Rust data structure.
println!("Please call {} at the number {}", p.name, p.phones[0]);

Then we draw the rest of the owl

I found the base example very good and nice to follow. However, that wasn't all that I needed so next I needed to figure out how to draw the rest of the owl.

snake_case of Rust with camelCase of JSON

First, Rust likes to use snake_case and gives you a warning by default if you don't. JSON keys are usually in camelCase so my editor and my shell were full of warnings and that was annoying. I learned that I can silence them by defining an allow attribute for each struct that needed it:

#[derive(Debug, Serialize, Deserialize)]
#[allow(non_snake_case)]
pub struct TeamResponse {
    pub abbreviation: String,
    pub id: u64,
    pub locationName: String,
    pub shortName: String,
    pub teamName: String,
}

I haven't yet found out if there's a way to use snake case'd names and automatically map them to corresponding JSON values. (Raymond Hettinger from the Python community has a nice talk for why it's valuable to have your code in idiomatic Python; much of it is applicable to any language).

edit: Thanks to PatatasDelPapa's comment in pull request, I was able to fix this:

#[derive(Debug, Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct TeamResponse {
    pub abbreviation: String,
    pub id: u64,
    pub location_name: String,
    pub short_name: String,
    pub team_name: String,
}

Code organizing API response types into a separate file

Second, you'll see that in the snippet above, definitions start with pub. That's because I wanted to move my API response type definitions to its own file so they don't pollute my main.rs and it's easier to find and change them. So I made api_types.rs file, moved them all there, added plenty of pubs and imported them with

mod api_types;
use api_types::{APIResponse, GameResponse, GoalResponse};

in main.rs.

Dynamic keys

Third, I needed some support for dynamic keys. I was expecting to have to jump through some hoops but this ended up being one of the easiest steps in the process. Thanks to this GitHub issue, I found the solution: use HashMap<String, serde_json::Value> for any object that has dynamic keys.

#[derive(Debug, Serialize, Deserialize)]
#[allow(non_snake_case)]
pub struct GameResponse {
    pub status: StatusResponse,
    pub startTime: String,
    pub goals: Vec<GoalResponse>,
    pub scores: HashMap<String, serde_json::Value>,
    pub teams: TeamsResponse,
    pub preGameStats: PreGameStatsResponse,
    pub currentStats: CurrentStatsResponse,
}

In the documentation of the API, scores field is defined as

scores object: each team’s goal count, plus one of these possible fields:

overtime: set to true if the game ended in overtime, absent if it didn’t

shootout: set to true if the game ended in shootout, absent if it didn’t

and looks like

"scores": {
  "BOS": 4,
  "CHI": 3,
  "overtime": true
}

The keys for each team are gonna be dynamic so by using HashMap. The downside of this that I wasn't able to figure out, is that I'd like to put overtime and shootout keys into the type definitions.

Optional keys

And finally, fourth, some keys are optional – or to be specific in this case, they are dependent on the situation.

I'm happy I already learned about Option types earlier (check out Learning Rust #2 if you haven't heard about them). And that's all you need with Rust and serde_json:

#[derive(Debug, Serialize, Deserialize)]
pub struct APIResponse {
    pub date: DateResponse,
    pub games: Vec<GameResponse>,
    pub errors: Option<HashMap<String, serde_json::Value>>,
}

In this example, which is the top level definition of my API response type, I've defined errors to be optional – it's only present if the API I use found some errors in the data it's using.

By saying that the type of the data is Option, we'll either get a Some(value) if the key exists and None if it doesn't. For most cases in this application, it's not random which keys are there and which are not. So if I'm already in a branch of logic where the prerequisite is being dealt with, I can trust that the value exists and can unwrap without dealing with potential Nones.

Result? Much cleaner code

Refactoring the code with these definitions is not only an exercise of writing code for the sake of writing code. The result of this work is that we push the problems at the boundaries of parsing the data and we don't have to deal with them at the logic level anymore.

I already showed some examples in the beginning about the code I wasn't happy about. Let's see how they look like now:

Before

if (&game_json["teams"]).is_null() {
  return None;
}

let home_team = &game_json["teams"]["home"]["abbreviation"].as_str().unwrap();
let away_team = &game_json["teams"]["away"]["abbreviation"].as_str().unwrap();

After

let home_team = &game_json.teams.home.abbreviation;
let away_team = &game_json.teams.away.abbreviation;

Before

let empty: Vec<serde_json::Value> = Vec::new();
let all_goals = game_json["goals"].as_array().unwrap_or(&empty);

After

let all_goals = &game_json.goals;

I don't know about you but I'm very happy to see my code being much more simpler and easier to read. I can also trust that once the data comes through from the API, it won't have any surprises.

Anything I don't like?

Writing type definitions for these kind of nested structures feels sometimes overly complicated. There are some definitions that I don't need anywhere outside one value in the structure and having to write a named struct to that feels bit annoying.

One thing I did enjoy in Typescript is a way to write in-line nested types and interfaces like this:

interface IEndpoints {
 auth: {
  login: string;
 }
}

In Rust, I would have needed to make two structs.

Pull requests for all these changes

If you wanna check out all the changes and how the codebase cleaned up during this process, you can find it in GitHub: hamatti/nhl-235/pull/27.

How Spice Program supported my creation of 235

Juha-Matti Santala — Mon, 19 Apr 2021 12:43:15 +0000

At the end of 2020, I decided to finally start learning Rust. For over a year before that, I had been playing with the idea of it but it took me all the way until the end of 2020 to get started. Rust is an interesting language for me, as I have mostly programmed with languages like Python and Javascript. Rust is something quite different and from the outside looking in, its community looked great as well.

After my initial steps with the language where I was solving Advent of Code puzzles, I decided to build my first software with Rust. I'm an active command-line user so for me the obvious first choice was building a CLI tool. Hence, on a dark wintery Friday evening, I started working on a hobby project that would become 235.

What's 235?

For the small subset of readers who live in Finland and have been fans of the National Hockey League (NHL) for a long time, the number 235 rings a bell. For decades, the Finnish broadcasting company Yle has provided NHL results on their teletext service on the page 235. For me, and many others like me, it's a habit to start every day by checking the page 235 to see the results of previous night's games.

Inspired by this cultural phenomenon, I decided to build a tool that combined the minimalist and iconic style of that teletext page with data from an API for NHL results.

235 is my first Rust program and it provided me a great opportunity to learn a new language – the spec was small and well-defined - it didn't require complex advanced features of the language - I knew it would be useful for me and people like me on a daily basis.

For learning & hobby projects, that combination of usability, simplicity and small scope is key. I know I'm not the only one with dozens of unfinished projects that grew too big from the original idea and with limited time to work on, personal projects never ended up being finished.

235 is published with MIT license and the code can be found on GitHub. (The project is called nhl-235 because Rust doesn't allow project names to start with a digit.)

Distributing executables is a very different world than web apps in browsers

As I mentioned above, this is my first Rust project and coming from a background of really different languages, there has been a lot to learn. This is the first time I've been working with binary executables. For almost two decades, I've loved web for its distribution model — you write code, deploy to server and it's updated for everyone. With executables, people need to proactively update their versions which means I need to think about new ways to reach them and communicate.

Certain things are also much slower for me to develop. One thing I really enjoy with Python and Javascript (both given their dynamic style and my experience writing them) is how I can focus much more into the content and domain, and much less on meta level things. I recently shared my thoughts about Option and Result types on my blog. Even though I have a theoretical understanding of how they work and what their benefits are, my development too often comes to a halt and I need to rethink and refactor things a lot more with Rust.

Luckily, the Rust community is great and I've gotten so much help in my learning journey from local and global Rust developers who have been so helpful and compassionate when I've been stumbling around trying to understand the basics of the language and how to write it.

And my employer supports my work on 235

In 2013, Spice Program was born as our open source and social impact program. Part of it is the support for open-source contributions of Futuriceans. In a nutshell: when you work at Futurice and do open source work on your own time, we support that with a monetary bonus of 15 euros/hour, capped at 30 hours/month.

In 2019, we expanded it to be more inclusive to people in the company who don't code:

The key purpose of our volunteering bonus is to make use of and develop your professional skills for social impact. For us, open source is always considered social impact, but there are many other ways to achieve that impact.

When a designer helps to create a beautiful web presence for a poor non-profit on an important mission, it should count, even if the graphical assets cannot be properly published as open source.

When an HR specialist helps in organising and running code schools for kids, it should count, even if there are no digital deliverables.

When a business advisory professional teaches principles of lean service creation to an NGO striving to make sure whales don't start smoking, it should count.

From a perspective of a developer, I'm happy that I get to build things that I want to see in the world and be appreciated for that with a small bonus.

And even more, it enables and incentivises me to learn more and to contribute to the open source ecosystem. With its flexibility, I'm not forced to do anything or have to make choices between other things in live and coding: sometimes I spend a weekend on a personal passion project and sometimes it's months that I don't code anything on my free-time.

One thing I realised only after I had built the first version of my 235: the API I decided to use was also developed with Spice support back in the day. That's the beauty of the open source ecosystem and community: things you build today can be fundamental in helping others build new things.

Over the past few months, we've been averaging at roughly 700 hours of Spice contributions per month. You can find more about the Spice Program here.

Learning Rust #3: crates.io & publishing your package

Juha-Matti Santala — Thu, 15 Apr 2021 09:10:31 +0000

Last December I finally started learning Rust and last month I built and published my first app with Rust: 235. Learning Rust is my new monthly blog series that is defnitely not a tutorial but rather a place for me to keep track of my learning and write about things I've learned along the way.

This week I wanted to take a look at the publishing and distribution of Rust applications. It presents a major difference to what I'm used to and what I love in the web app world so I'll discuss that first and then look at the practicalities and the documentation of getting your application to the computers of your users.

When I was young, we bought software from store

I want to start this with a bit of a story. When we got our first family computer in the early 1990s, we'd buy software in floppy disks from a computer store. This was true a decade later with the small change that the software was distributed in CDs.

The Internet was young and the connections and download speeds were not suitable for mass scale distribution of software as downloadables. In the early 2000s, I started to use some online services like forums and early versions of social media via browser.

When I was 15, I knew I couldn't write my own software, get it to store shelves and have people buy it. I was just a beginner developer learning the first steps. So building things on the web, to be used with browsers was what I decided to go with. It probably wasn't as concious and thoughout decision as I see it through the goggles of nostalgy. However, the fact that I could build something, upload it (we used to deploy by moving PHP files with FTP client to the server) and it would available to anyone interested in using it was definitely a major reason for why I fell in love with the web as a medium.

So, for 15 years, almost everything I built, was deployed to a webserver somewhere and accessed via browser. I did build some tools for myself that were run locally but they were never meant to be given to other people so distribution was not a factor.

As the web development as a field progressed over the 15 years, distribution became even easier and instead of ftp'ing bunch of files to the server, we started to set up automatic deploys and working with version control. But the essence of distribution didn't change: I make a change and it's available to everyone without needing any action from them.

Then I built my first Rust binaries

This brings us back to 2021 and me learning Rust. When the end result of your work is a binary executable, everything in terms of distribution changes. No longer, can I fix an issue quickly and have it in front of every user within minutes.

Thanks to the internet and Rust's package ecosystem, there's no need to burn the app on a CD, put into a beautiful cardboard box and sell in stores. Now people can download it in seconds, update it easily and get things rolling with the new version.

But there's still one major difference: people need to update their app manually. There might be some ways to let people know that their application needs updating: first thing that comes to mind is making an API call to a server that returns the last version number and if it's newer than what the user has, print a "you should update" message. Thinking of it now, I might end up doing that before 235 hits version 1.0. Let me know if there's a better way.

But still, people may run your application for months or years without checking for updates, especially if it works. Or they might abandon it quickly if there are annoying bugs and when they notice it, there ain't no new version yet.

The authority of updates moves from the developer to the user. And that changes so much.

crates.io

Rust's package registry is called crates.io. If you're a Javascript developer, it's similar to npm. For Python users, it's similar to PyPi. It's the place where you find the tools you need to write great Rust programs without reinventing the wheel. It's also where you can install 235 from.

cargo install nhl-235 is the command line command that pulls the package and builds it.

To publish Rust code in crates, you need two thing: account in crates.io and Cargo.toml file with certain information you can check from the docs. After those are correctly done, cargo publish transfers your code via the highway of information to the package registry so others can install it and use it.

I really enjoy the process. It's developer experience is fantastic and once I've gotten a new release version done, I just publish it and people can update it with cargo install nhl-235. So good.

Building binaries

You don't have to share your program in crates.io though. Since the result of the build process is a binary, you can just share that. I'm still learning how to use the Releases page of GitHub but whenever I publish to crates.io, I upload a new release build to GitHub to which I also link from my website.

This allows people to download and run your program without any need for the Rust language tooling installed.

I develop 235 on a macos and I'm not 100% sure if my builds work on any machine. It's on my todo list to learn more and test it more thoroughly but so far, nobody has complained. If you wanna give me a hand and use Windows or Linux, download the latest release from here and run it from the command line and let me know in Twitter if it works or not.

A huge benefit of the binaries compared to crates.io is that the end user doesn't need any Rust tools installed and I gain full control over distribution. And those updates? It's bit more of a hassle since people need to go and download the binaries again and replace the old ones.

Eventually 235 will reach design and technical maturity where it won't be updated with new features and hopefully won't have breaking bugs anymore. At that point, the need to update constantly will thankfully disappear. Until I may have to do some changes to the API.

Making a release is more deliberate

One thing I've noticed is that when I can't just deploy a change or fix in a matter of minutes, I need to be much more deliberate, test things out more and figure out if the design of the program is correct. In the beginning, it's more okay to experiment especially as I'm learning the language but as I reach version 1.0, I'm looking to only make changes in larger chunks.

All in all, publishing 235 via crates.io and as binaries has been a very educational process and a refreshing change of pace compared to my usual web development projects.

Learning Rust #2: Option & Result

Juha-Matti Santala — Fri, 19 Mar 2021 09:00:47 +0000

Last month I started this series by talking about something I really enjoyed: pattern matching. And while writing and after sharing that post, I did further refactoring on the codebase based on ideas and suggestions by the community. Special thanks to Juho F. for helping out!

This month, I want to talk about something that made me struggle a lot and caused (and still causes) my code writing to slow down considerably: Option and Result types and how I constantly run into issues with them.

Coming from Python and Javascript development, I'm used to values being most often just values (or null). I can call a function and immediately continue with the return value.

In Rust, things are done a bit differently. You can still write functions that take an input and return a value but in many cases, functions return an Option or Result that are kind of wrappers around the actual values. The reason for this is to add safety over different kind of errors and missing values.

What is an `Option`?

Option is a type that is always either Some or None.

fn divide(numerator: f64, denominator: f64) -> Option<f64> {
    if denominator == 0.0 {
        None
    } else {
        Some(numerator / denominator)
    }
}

The above example is from Rust Option's documentation and is a good example of Option's usefulness: there's no defined value for dividing with zero so it returns None. For all other inputs, it returns Some(value) where the actual result of the division is wrapped inside a Some type.

For me, it's easy to understand why it's implemented that way and I agree that it's a good way to make the code more explicit about the ways you treat different end cases. But it can be so frustrating especially when learning programming.

There are a couple of ways to get the value from Options:

// Pattern match to retrieve the value
match result {
    // The division was valid
    Some(x) => println!("Result: {}", x),
    // The division was invalid
    None    => println!("Cannot divide by 0"),
}

Continuing from previous example and my previous blog post on the topic, pattern matching gives a clean interface for continuing with the data. I find this most useful when it's the end use case for the result.

games.into_iter().for_each(|game| match game {
  Some(game) => print_game(&game, use_colors),
  None => (),
});

In 235, I use it for example to print games that have been parsed correctly and just ignore the ones that were not. Ignoring them is not a very good way in the long run but in this case, it's been good enough.

Other way is to unwrap the Option. The way unwrap method works is that it returns the value if Option is Some and panics if it's None. So when using plain unwrap, you need to figure out the error handling throughout.

There are also other variants of unwrap. You can unwrap_or which takes a default value that it returns when Option is None. And unwrap_or_else which functions like the previous but takes a function as a parameter and then runs that on the case of None. Or you can rely on the type defaults by running unwrap_or_default if all you need is a type default.

But there's still more! For added variety, there's the ? operator. If the Option it's used on is a Some, it will return the value. If it's a None, it will instead return out from the function it's called in and return None. So to be able to use ? operator, you need to make your function's return type an Option.

To create an Option yourself, you need to use either Some(value) or None when assigning to a variable or as a return value from a function.

What's a `Result` then?

The other "dual type" (I don't know what to call it) in Rust is Result. Similar to Option above, Result can be one of two things: it's either an Ok or an Error. To my understanding so far, Ok basically functions the same than Some that it just contains the value. Error is more complex than None in that it will carry the error out from the function so it can be taken care of elsewhere.

Same kind of pattern matching can be used to deal with Results than with Options:

match fetch_games() {
  Ok(scores) => {
    let parsed_games = parse_games(scores);
    print_games(parsed_games, use_colors);
  }
  Err(err) => println!("{:?}", err),
};

In 235, on the top level, I use above pattern match after fetching the scores from the API. If anything happens with the network request, the application will print out the error. One of the tasks on my todo list is to build a bit more user-friendly output depending on the different cases rather than just printing out raw Rust errors. I haven't figured out yet how to deal with errors in Rust in more detail yet though – once I do, I'll write a blog post in this series about it.

Like with Option, unwrap and ? also work for Result.

So why do I struggle?

As I've been writing this blog post, everything seems so clear and straight-forward to me. Still, when actually writing the code, I stumble a lot. As I mentioned earlier, I come from Python and Javascript where none of this is used.

One thing I've noticed to struggle is that I write some code, calling a function from standard library or some external library and forget it's using either Option or Result. Or I forget which one had which internals and thus, I'm still in a phase with Rust where I need to check so many things from the documentation all the time.

It also feels like you need to take so many more things into consideration. If you want to use ?, you also need to change the way your function is defined and how the caller works and sometimes that can go on for a few levels. So my inexperience with the language leads to plenty of constantly making messy changes all around and occasionally ending up in a dead end I can't dig myself out of and I end up starting over.

And while I know it's mostly about getting used to a different system, I sometimes feel so dumb when I struggle with making the code not take into account all different ways it can crash (which is a big reason Option and Result are built the way they are).

What's up with 235?

I've been using 235 myself daily since the first developmental version and I'm loving it. It's the one piece of software I'm most proud of and it's been answering my needs very well – and from what I've heard of from others, their needs as well.

235 is about to hit version 1.0. I'm getting confident that I've taken care of most of the major bugs conserning the basic usage and that gives me confidence in incrementing the version to 1.0.

Two things still need to be taken care before that and I'll hopefully get them done early March once I get a couple of lectures and talks out of my plate. First thing is to fix a bug that has a slight chance to appear during the playoffs. Second one is to make the error handling bit better and provide more user-friendly outputs when things go wrong.

If I wanna learn Rust, where should I go?

Like I said, don't take these posts as gospel or tutorial. If you wanna learn Rust, my recommendation as a starting point (and one I started with) is Rust Book and with it, Rust by Example. Also, joining your local Rust communities and being active in Twitter by following @rustlang and taking part in discussions with #rustlang.

Learning Rust #1: Pattern Matching

Juha-Matti Santala — Thu, 11 Mar 2021 09:38:40 +0000

My process of learning is reading some guides and docs (with Rust, I started with The Rust Book and Rust by Example), then I try to make something that works, ask a lot of questions from the community, improve, fix bugs, read some more and now I'm writing blog posts which require me to do more research and help me futher improve my program.

The first concept that I've really liked and that I have not used in other languages is the match operator for pattern matching. In correct use cases, it can make the code nice and easy to read but it also can end up becoming a messy spaghetti. I'm currently still trying to figure out when it's best to use and when not.

Basics of pattern matching

First use case I have for match is to map team name abbreviations from the API into the city names I want to use in the app:

let str_form = match abbr {
        "BOS" => "Boston",
        "BUF" => "Buffalo",
        "NJD" => "New Jersey",
        "NYI" => "NY Islanders",
        "NYR" => "NY Rangers",
        "PHI" => "Philadelphia",
        "PIT" => "Pittsburgh",
        "WSH" => "Washington",
        "CAR" => "Carolina",
        "CHI" => "Chicago",
        "CBJ" => "Columbus",
        "DAL" => "Dallas",
        "DET" => "Detroit",
        "FLA" => "Florida",
        "NSH" => "Nashville",
        "TBL" => "Tampa Bay",
        "ANA" => "Anaheim",
        "ARI" => "Arizona",
        "COL" => "Colorado",
        "LAK" => "Los Angeles",
        "MIN" => "Minnesota",
        "SJS" => "San Jose",
        "STL" => "St. Louis",
        "VGK" => "Vegas",
        "CGY" => "Calgary",
        "EDM" => "Edmonton",
        "MTL" => "Montreal",
        "OTT" => "Ottawa",
        "TOR" => "Toronto",
        "VAN" => "Vancouver",
        "WPG" => "Winnipeg",
        _ => "[unknown]",
    };

(Editor's note: while writing this blog post, I'm exposing myself to how bad my variable naming is in this project. That's partially because so much mental energy is spent on figuring out how to write Rust that there's not much left for thinking about good names. I'll fix 'em little by little as I refactor so it might be that at the moment you're reading this, I have already renamed them in the source.

Another example of how I use match in 235 is when deciding how to print lines of goals:

let score_iter = home_scores.into_iter().zip_longest(away_scores.into_iter());

for pair in score_iter {
  match pair {
    Both(l, r) => print_full(l, r),
    Left(l) => print_left(l),
    Right(r) => print_right(r),
  }
}

Here, I have score_iter (again, not the greatest name, I admit) which is a Zip that supports uneven lengths. For example, it could look something like this (this example is pseudo, the actual data is more complex. _ denotes a missing value):

[
  ((Appleton, 2), (Boeser, 0)),
  (_, (Hoglander, 8)),
  (_, (MacEwen, 26)),
  (_, (Boeser, 57))
]

By matching these pairs, each line will either be (itertools::EitherOrBoth::)Both which means both values are there, Left meaning only the left value exists and Right for only right value existing. Matching these with match pair, it's nice and clean to run the corresponding print function.

This second match example also showcases binding where we bind the values into variables l and r so we can refer to them inside the expressions.

Options and Results

Another very handy use case for match is with Result and Option. My main logic when running 235 on the command line is done within api() function that returns Result<(), reqwest::Error>.

match api() {
  Ok(_) => (),
  Err(err) => println!("{:?}", err),
};

Since Result will either be Ok or Err, I'm matching Ok with no-op and Err with printing out the error into the console.

Example with doing similar with Option is

games.into_iter().for_each(|game| match game {
  Some(game) => print_game(&game),
  None => (),
})

Here, if a game was parsed correctly, it will be Some and if it didn't, it will be None so we can just skip the None case and only print the games that were parsed correctly from the data.

Guards

One thing I haven't used yet and only learned about it while doing research for this blog post is guards. They are essentially additional if clauses combined with a pattern so you can differentiate similar values based on extra condition.

The example in Rust by Example is this:

let pair = (2, -2);

match pair {
  (x, y) if x == y => println!("These are twins"),
  (x, y) if x + y == 0 => println!("Antimatter, kaboom!"),
  (x, _) if x % 2 == 1 => println!("The first one is odd"),
  _ => println!("No correlation..."),
}

I haven't yet run into cases where I'd have use for the guards but wanted to record it here so you'll know it exists.

Conclusion

All in all, match might be my favorite syntactic thing in Rust so far. Sometimes it feels bit too much like a hammer (in sense of if all you have is a hammer, every problem starts to look like a nail) in that I tend to overuse it even when other means would make more sense. But I'm sure it's something that I'll find the right balance as I code more with Rust.

Advent of Code #1: Getting Started

Juha-Matti Santala — Thu, 03 Dec 2020 16:11:48 +0000

Every year I embark on a magical Christmas adventure with Advent of Code. Quite often, I end up working on the first few days' challenges and then it takes a backseat to other things in life. This year – like every other before it – I'm serious though and want to try to finish the entire challenge and document my learnings meanwhile.

This series won't be a tutorial nor a "this is how you solve these challenges" guide but rather a journal of my progress with Advent of Code and Rust. If you're afraid of being spoiled on those challenges, try to solve them first before reading further as I'll show and talk about some code as well.

Why am I so excited about code puzzles?

When I was a kid, a chocolate advent calendar was the best way to get hyped for Christmas. Every morning, I started the day by opening a new window and find chocolate that was usually very sub-par in quality but it was never about the taste of chocolate. It was about the freedom to eat chocolate in the morning and the excitement of days leading towards the Christmas Eve (which is when we Finns celebrate).

As a web developer occasionally working on client projects but mostly focusing on developer community building, I'm often looking to do something fun with code, experimenting with new technologies and keep learning but I don't want to start a multi-year project. Advent of Code is perfect for that. I can do snack-sized puzzles with some technology without any pressure of finishing or writing amazing code.

This year I'm using Rust

I have never really done any systems programming. I did one combined C & C++ course in university but that's pretty much it. Last year, when I was speaking at PyCon Estonia, I met Dom Weldon and saw his talk Oxidizing MyPy in which he talked about using Rust and Python together. That sparked an interest in me to get started with Rust.

It took me a year to actually do anything with it. I was kinda saving Rust for another project but since I realized I might never make that happen, I'll start learning Rust with Advent of Code.

One of the reasons I wanna learn Rust is to build command line tools. I have previously written about my love for CLI tools if you wanna know why. I've seen Rust becoming quite popular for CLI tools and I want to get into that groove.

Days 0 to 1

First contact with Rust

I wanted to get a good start with a new technology so I took a head start and spent the evening of Nov 30th to make sure I had a setup where I can start working on.

So I started by installing Rust and Cargo, read the first few chapters of Rust docs, built the number guessing game in the documentation to make sure I know the very basics and built a template for unit tests.

For me, Advent of Code is perfect place to use Test-Driven Development and I've figured that if I learn how to write and run tests with new technology from the very first touchpoint, it's more likely I'll write good tests when I start using the language in more serious projects.

Another thing I wanted to learn is the conventions of documentation in Rust. And Rust is great for that. Already on Day 0, I fell in love with cargo doc that generates local documentation, not only from your own code but of your dependencies as well. How is that not a main feature in all languages and ecosystems? It is so smart. And it encourages good documentation of your own crates and functions as well. Rustdoc has great documentation for how to write and build documentation.

December 1st

First interesting thing I noticed with Rust is that it's recommended to keep unit tests in the same files as the functionality. Rust uses something called conditional compilation which means that you can define in source level, if you want something to be compiled to the final binary or in this case, only when running tests. That can be defined by annotating a function with #[cfg(test)].

A bit similar functionality that I've used before is Python's doctest that allows tests to be included in docstrings of functions. Rust also has similar functionality but from a different perspective. Developers are encouraged to add an example or two into their documentation of functions so it's easier for readers to use the functionality. To make sure those documentation examples work, rustdoc runs those examples and tests them for you. What a great way to keep documentation and code in sync.

And then it happened. I wrote my very first Rust code (by furiously googling and copy-pasting code together) and IT WORKED. I got my very first star for this year. My code didn't look very beautiful and it probably wasn't the most idiomatic Rust. I'm guessing it looks like Python or Javascript developer's first Rust code.

So I submitted it for code review to my colleagues at Futurice and fellow Rust developers at Koodiklinikka. A great way to improve fast is to take a challenge, figure it out by reading docs and googling and then having a discussion about it with other developers. Thanks especially to Aarni and Jaakko for helping me improve my first bits of code.

Learning new is exhausting

I've been coding more or less actively for a few decades since my teenage years. I noticed something very interesting (which reminded me it's been a while since I've been actively learning something new): even though I'm very familiar with basic concepts like reading input and looping and all that, when learning a new language like Rust, I keep completely forgetting all the basics.

I decided to build my solution so that it reads the result from standard input rather than file and Jaakko did the opposite. After discussing our solutions and reviewing our code, I totally forgot I had done that, ran my code and waited for half a minute wondering why my code is so slow. I had forgotten to provide the input into standard input so the code wasn't doing anything.

On the bright side, I love that kind of really intensive learning. It tickles my brain in just the right way and gets me excited with stuff.

The first couple of days of Advent of Code are usually quite nice warmup challenges. They are helpful in making sure my setup works and my code is run correctly. This year was not an exception to that rule and I'm happy about that because there's always an extra added layer of complexity when setting new things up.

My solutions

I update my solutions to my GitHub repository at hamatti/adventofcode-2020. Since I'm a very beginner with Rust, I don't recommend taking them as example or you'll probably learn some bad habits.

I won't probably solve those challenges every day but rather in batches of a few days at the time.

How to ask help for technical problems?

Juha-Matti Santala — Tue, 24 Nov 2020 17:24:19 +0000

This post was originally shared at my personal blog at https://hamatti.org/posts/how-to-ask-help-for-technical-problems/. If you're interested in more posts like this, check out my other blog posts there and sign up for my monthly personal newsletter.

Over the years, I've been involved in a lot of different groups and communities where people ask for help for technical problems. I've seen some great questions and some where even just getting to the actual problem has taken a long time.

In this post, I want to give some tips for anyone who wants to get help with their problems because the better your question covers different things and explains the problem and what you've done, easier it is for someone to help you. I do want to emphasise that for beginners, it's not easy to ask questions because there's so many unknowns. Hopefully these tips will help you on your journey to seek knowledge.

Most of these are meant for asynchronous communication like chat apps or forums or sites like Stack Overflow and focuses on programming related questions to narrow the scope of the post.

The common thread in all these is to provide as much information and being as specific as possible up front so you and your helpers don't have to spend a day going back and forth before getting into the actual problem.

1. Ask your question, don't ask if someone can help

Let's start with the first message you send. I often see people start by asking "Is there anyone who can help me with XYZ?".

It sounds reasonable, right? However, it can hinder your ability to gain help a lot:

It's hard for the helper to know if they can help
It lengthens the discussion loop unnecessarily long

Let's say you are struggling with something in CSS. If you post a message on a proper chat room (like developer communities in Discord or Slack), there might be a lot of people who know CSS but they might not know the exact thing you're struggling with.

Second, by asking that requires someone to say "Yes, what's your problem?" and it may take a day to even get into the discussion of the problem itself.

Instead, just ask your question directly. "I'm trying to center align a div inside another div but can't figure out how?" is a much better start. We'll learn how to make it even better later in this post.

When you ask the question like that, anyone at any point can take a look at it and have a better idea about if they can help you and they can start answering right away. You might get a solution to your problem even before you return to read the chat for the next time.

2. Explain what you are trying to achieve

It might sound obvious but very often it's missing and can lead the people helping into a wild goose hunt to the wrong direction. This is especially relevant with new developers because you might be trying to do something with a bit wrong set of technical tools.

The more specific you can be here also helps people grasp what you're aiming to do which helps them give you better answers.

Rather than focusing on the technical implementation details, focus on what you want the effect of the code to be.

3. Include example input and output data

If you're working on something that takes in data and outputs something else, provide both an example set of data to be used as an input and an expected output. Even better if you can provide multiple sets of different input/output pairs so your helper can test out that their implementation of the fix actually answers to your question.

For example, if you're working on some regex or validation with Joi, offering a test input helps a long way in reducing back-and-forth between you and your helper.

4. Share the errors

"My code doesn't work, why?" isn't very helpful but often encountered question. The answer to that often is "I have no idea".

So instead of being vague, be as specific as possible. One way to be specific is to share the error code you get (and share it every time when it changes during your process of figuring it out). For an experienced developer, errors reveal a lot so sometimes just looking at the error alone we might be able to figure out the problem – especially if it's a very common one.

And please, always share those as copy-paste into code blocks (see next section for those) because that allows us to copy-paste further and search from Google if it's something we're unfamiliar with. Screenshots of errors are often just one more hinderance in trying to figure things out.

If you're using some specific applications or libraries, share version numbers of those. For example, if you have a problem with Django, please tell the version of Django and version of Python that you're running. Programming languages and tools evolve and it might be that it's a specific issue to your version.

5. Show your code

It's very important to show what you have tried to do for a couple of reasons.

First, it's more motivating for someone to help you when they know you're not just asking someone to do the work for you but that you've actually tried solving the issue yourself and are genuinely stuck.

As someone who teaches a lot, I try to avoid giving direct answers as much as possible and rather try to help people learn how to figure it out themselves and how to find the right information. That's impossible if you're only looking for direct complete answers.

Secondly, it can be really difficult to give programming advice to a specific problem if the person giving advice doesn't know what your code looks like. This is especially important when you have an error or something's functioning incorrectly.

There are different ways to share the code. For HTML/CSS/Javascript stuff, you can use Codepen or for more complex frontend code, use Codesandbox. The big benefit of these two is that you can run the code and see the result. Most problems are not solved by staring at the code and returning the answer but often require some tinkering and these platforms are great for that.

For other code, there are tools like Pastebin which allow you to paste anything, choose a syntax highlight and click submit. Or if your code is short, you can send it directly in Discord/Slack. For that, here are couple of tricks to make it easier for your helper to help you:

To share code in these platforms, wrap it around three backticks:


```
// your code here
```

On Discord, you can also add a language definition after the first three ticks to add syntax highlighting:


```js
// javascript code here gets highlighted
```

On Slack, you can create a code snippet from the lightning menu which allows you to add syntax highlighting:

Slack's Code Snippet modal with example Python code
(thanks Juri for pointing this feature out)
Reading code that is not shared inside these code blocks (created by triple backticks) is very difficult to read.

6. Create a Minimal, Complete, Reproducible Example

Codebases are often large and complex and it's not beneficial to share all your code that exists.

Quoting from a great instruction post in Stack Overflow:

Your code examples should be…

…Minimal – Use as little code as possible that still produces the same problem

…Complete – Provide all parts someone else needs to reproduce your problem in the question itself

…Reproducible – Test the code you're about to provide to make sure it reproduces the problem

I won't copy or rephrase everything from that post but rather advice you to read it with thought.

This is one of those things where I think we need to be most lenient, especially with new developers. If you're new to software development and your code doesn't work, it's very likely you don't know why (that's why you're asking, after all) and it can be very difficult to create an example like that.

But reading it through and understanding why it's a positive thing to thrive towards can help you a long way.

Wrap-up

A good question is a combination of all the above: asking directly to get things started, stating what you're aiming to achieve, sharing the errors you're encountering, sharing the code is causing you these problems and making the shared examples minimal, complete and reproducible.

By putting these advice into work, I can guarantee that your experience with seeking help will get much better. A side effect might be that you get less discussion going (less people asking for more info) but you also save your and other people's time when they don't have to ask a lot of things only to find out that they cannot help you that time.

And finally, remember to say thanks when you get help. I didn't add it as its own point since I've never had the issue of people not saying thanks. But if you have gotten help and didn't say thanks – do so in the future.

I know asking help can be a daunting task: exposing your imperfection to strangers can be scary. Despite making this long list of things you should do, I do want to encourage you to ask even if you are not perfect in all of these. This post is aimed mainly to provide you with some new ideas that you might not have thought about or known about.

I wish you get help for your technical problems!

(PS. If you're an experienced developer, you might notice that all of these translate very nicely into writing good bug reports. That's because a bug report is essentially asking for help in fixing something.)

5 key learnings from running a developer newsletter

Juha-Matti Santala — Thu, 30 Jan 2020 12:32:25 +0000

For quite a while, I've been entertaining the idea of starting a developer newsletter. Personally I'm a big fan of newsletters and as I've been building communities for a while already, doing one of my own was a thing I wanted to try out. In August of last year, a great opportunity to do that arose and I took on the challenge.

I started building Dev Breakfast in July and released the first issue in August. It's a monthly email into which I curate interesting articles, blog posts, talks and tools that are interesting to software developers. Our company has 300 developers who love to discuss topics in company internal Slack and I wanted to bring up those interesting articles discussed also to others.

1. Have a focused topic

When I started building this newsletter with our team, the first question that needed an answer was the focus and topic. We decided to go with software development in general since we are interested in serving a larger audience.

Software development is a huge field and right now I feel like we should have been bit more bold to go for a more narrow niche. It's difficult to build an audience for any content if it's all over the place and it's easier also to curate and author content the smaller the topic is.

One way that we're tackling this moving forward is that starting from February, each month will have a theme based on interests of my colleagues who will start to curate the content.

2. Start with minimum viable newsletter

There's a lot to do and optimize in newsletter publishing. You'll learn that as you go so my suggestion is to start by doing something and regularly reflecting on how it's working. Pick up a platform (like Mailchimp or Hubspot, build a list and make a really simple signup page.

After that, do marketing: share it in social media, your blog, your talks or just ask your friends and colleagues to sign up. Once you have people, start publishing and learn on the way.

Our process of building the newsletter has evolved a lot during the first seven months. You'll learn what works, what's easy, what's hard and what pain points you encounter as you build your newsletter and grow your audience.

3. Focus on your readers

Whether you're running your newsletter for your business, your personal brand, a non-profit or any other reason, put your needs on the backseat. Put every bit of focus on the people reading the newsletter (or potential subscribers from your audience).

If your newsletter doesn't provide content that is interesting to people, you're wasting your time. Platforms like Mailchimp and Hubspot offer great analytics so you can see how many people open your emails, which links they click and if you're linking to your own content, using UTM tags allows you to analyze what your readers are doing after they reach your site.

The number of subscribers is not a valuable metric so don't look at that too much. Pay more attention on how many people actually read your emails and interact with it.

4. Make it easy for people to unsubscribe

Some marketing emails make this really difficult and it's just silly. Many platforms will charge you based on the amount of emails sent so having people not interested in your emails to unsubscribe serves you well. Also having subscribers on your list who never open your emails doesn't serve any purpose for anyone.

So don't try to hide the unsubscribe links. If you use existing services to run your list, they already have good setups for this.

5. Do things that you enjoy

While your readers should be the main focus, running a newsletter where creating the content is a chore that you hate to do will not last. So pick a theme that you're excited about, use a format that makes you happy. I do a link curation but you could also write original content or spark discussion.

When you enjoy the process and the content, it becomes visible to your users and the quality of your newsletter will improve. Don't be scared to experiment, change things around and see what works. Finding a good balance between things that excite you and things that are interesting to your audience is not an easy task but it's where we all should aim for.

If you're interested in learning about interesting new things in the software development industry, check out Dev Breakfast.

I'd love to hear your opinions on both the content of the newsletter as well as the ideas presented in this post.

Cover image credit: Photo by Yannik Mika on Unsplash

My journey in diversity and inclusion in tech

Juha-Matti Santala — Wed, 28 Aug 2019 18:42:59 +0000

Some people who know me personally well and have been involved in my professional career for the past 4 years, know that I'm very passionate and increasingly vocal about diversity and inclusion in tech. Others, who have known me for longer, might see me as a hypocrite.

I haven't always been so passionate about it and I want to share my story. It's not an easy one to share and quite frankly, publishing this post is little bit nervewrecking. But it's so much less that than what other people have to endure sometimes in this industry.

Backstory

Let me tell you little bit about me before 2014. I grew up little bit socially clueless, spending8 most of my time in online forums and IRC channels. Many aspects of my social behaviour were affected by culture where saying things like "There are no women in Internet" was a norm or the dominant way of thinking was that men were superior to women. I learned that culture.

That obviously leaked into my real life. I would like to say I made inappropriate jokes but there was nothing joke-like there. I was an asshole. I didn't realize it back then. For me, it's was just witty banter. I can't remember if people pointed it out. Maybe they did and I just shrugged it off. Maybe they didn't because it's hard to say about those things that to a friend.

I have always been very competitive in everything in life. In 2014, I moved to San Francisco to work in a small startup. In March, we hired our first developer who was a woman. I made stupid remarks in a group chat of some fellow startup people, something along the lines of "now I need to really start focusing on my work so I don't lose to her".

Then the best thing happened. I got called out for it. I didn't realize it then well enough. I tried to defend my position and explain my way out of it. I wasn't able to see how my thinking and actions could affect things outside me.

None of my bullshit behaviour back then is excusable by anything.

Living in San Francisco and being in the center of so much more discussion about diversity and inclusion problems in tech slowly started to make me understand things from another angle. And then, I started to do my best to make things better.

Why diversity and inclusion matter?

There are many reasons to promote diversity and inclusion in technology industry. There are business reasons and studies that say how diverse teams are better performing ones. For me, one of the reasons (other than being a decent human being) is this:

We are building products, tools and services for the humankind. There are so many different kinds of people in the world that if everyone in the team building these tools are too similar, we fail to build services that take into account different kind of people.

Maybe 20 years ago, technology was an opt-in - you could choose to use and interact with it. 2019, that's no longer the case. In many societies in the world, it's very difficult to even be a member of the society if you are not computer literate.

That's why I think it's crucially important that we bring in people from different backgrounds, different life situations (I think career-changers into tech is a wonderful thing) and different ways of seeing the world.

You might not agree with the above and that's perfectly fine. I don't claim to know that I'm right. But I want to be clear on why it matters to me.

I also keep fighting because I've been to the other side. I feel the pain in me when I see people treat others inappropriately. And I keep fighting because I hope that while I can never make my past actions acceptable, I can hopefully make the future a better place for many people.

As an industry, we have so much work to do. And it all starts by realizing and accepting that it's not about "us good people" and "them bad people". Even the good companies, good events and good communities have issues. We cannot turn a blind eye on them. We need to all strive to make our culture more accessible and more inclusive to different people.

I still have lot to learn and lot of work to do in my own networks. One of the developer communities I ran, Turku <3 Frontend, is quite homologous because I have been bringing in people from my limited networks. I want to expand those networks and make sure that we are a community that is a great platform for everyone to learn and grow, not just people who happen to be like me and hang out with me.

And most importantly, I need to also be better at treating people with the respect that they deserve and to make sure that whenever mistakes are made, that I own up to them. Because I know I will make mistakes.

Why I love using command line interface?

Juha-Matti Santala — Sat, 27 Jul 2019 07:51:16 +0000

My Saturday started by waking up to a Twitter thread I was tagged into:

// Detect dark theme var iframe = document.getElementById('tweet-1154988415244472321-813'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1154988415244472321&theme=dark" }

Tweeting out my answers, I started to come up with more and more reasons, so I figured I'll also document them down here in my blog and open up each point a little bit in detail.

1) You can replicate commands

The first benefit that came to my mind when I started thinking about this, was replicating commands. If I use a GUI, to replicate some complex action, I need to do a lot of clicking around, whereas using command line, I can run the command with one copy-paste command (or using history feature) as many times as I want without having to do any more work.

Replicating commands provides a way to upfront the amount of work that needs to be done. Sometimes it's bit more but quite often, if you run the command more than once, you start winning time and effort.

Replication has other benefits too. Let's say I want to download 100 Youtube videos:

Using a GUI

With a GUI (of an imaginary downloader software), I have to copy-paste the urls one at the time, click Download, wait and repeat.

Oh wait, what if I realize that the application downloaded all videos with default 240p quality? Maybe I go to settings, change a quality setting to 1080p and start pasting in those URLs again.

Using a CLI

With a CLI, I can dump all 100 URLs to a file and run a download command for each line in that file. With one command, I just downloaded 100 files.

And if I need to change the quality option, I can just add an option flag to my loop, rerun that one command and wait as my videos are downloaded.

2) History

Second one of my favorite aspects about command line interfaces is that I get access to history of commands. I can easily repeat the previous command or search for any command I have run before.

With most GUI applications, I have used, this is not possible. Some photo or video editing software has repeatable history but most software doesn't.

I personally use mcfly as my bash history search app. With it, I can quickly find and re-run commands that I have done before.

3) Chain commands

If a CLI application is designed nicely, it takes input from stdin and outputs to stdout. Of course not all CLI apps do this and for some apps it doesn't even make sense really.

But many do. And that design allows for chaining commands. You can take your toolbox of bash tools for example and mix-and-match them however you want.

For example, let's say we are interested in Pokemon TCG cards (if you've been reading my blog, it should be quite obvious I'm a huge Pokemon fan). We want to know every unique card name that includes 'Charizard':

curl https://api.pokemontcg.io/v1/cards?name=Charizard | jq '.cards | .[] | .name' | sort | uniq

Here we curl'd an API, which returns a JSON into the stdout. We then pass that JSON to jq, that reads JSON from stdin and allows us to do operations on it. In this case, we access the cards property and get all the name properties. Once again, we output that to stdout so that sort can read it, sort alphabetically and finally uniq removes duplicates.

Some GUI software aimed for interacting with HTTP calls allows this kind of operation built-in. But the beautiful thing with the command line is that we can combine any tools we want. You don't have to plan for every possible use case when building the tool: as long as you read from stdin and print to stdout, your CLI app can be combined with any other.

4) Programmability

An extension of the replicability in #1 is that we can alter conditions and parameters of calls programmatically. Let's expand on the downloading Youtube video examples from #1.

Maybe this time we get a mix of different sources, not just Youtube. You can use basic conditionals within your script to call different applications based on the source or filetype.

Maybe you pass Youtube links to Youtube downloader, image and txt file links to curl or wget and some other proprietary formats to specific software that allows extracting the information.

5) Share commands

How many times have you helped someone remotely to use their computer for something? Maybe it's a friend who needs to install some software or maybe it's a colleague trying to setup their development environment. Or maybe you're writing a blog post teaching people how to use a software.

With GUI apps, it's often bit vague "click on the blue button in the upper right corner that says Scan" verbal instructions or screenshots/screencasts. The instructions grow quite long and take a disproportional amount of time to write down.

With CLI apps, you can just copy-paste the commands and send them to the one in need or add them to your blog. Please be careful though: running commands that someone else tells you to run is very dangerous. You should never blindly run commands anyone tells you to run without understanding what they do. I have seen some havoc that has been done to systems by misinformed users.

6) Automation / scheduling with cron

The universality of these command line tools means that you don't have to build every feature to every application. If we continue with our example of downloading Youtube videos:

You know that your favorite creator uploads a new video every Monday at 10.00. You could set yourself a reminder to download it with your GUI app manually or hope to find a GUI app that downloads Youtube videos and allows scheduling.

Or you can use the CLI downloader and combine that with cron. Now you can use one app to find the URL to the latest video, feed that to the downloader and schedule it all to happen every Monday at 10.05.

Cron is great for maintenance tasks that are essentially the same task run over and over again on regular intervals. Like doing backups, cleaning up some upload folders, etc.

7) Less change in interface

I left this one for last because it's a bit different and less universally true. I have noticed that GUI applications quite more often make changes to their UIs than CLI applications to their API. That makes using history and written-down instructions much better at lasting time.

Conclusion

In which situations you prefer CLI over GUI and why? Let me know in the comments and I can hopefully learn new tricks.

I am starting a Youtube channel Juhis Talks Tech to expand my knowledge sharing beyond these blog posts. The first episode will be out soon and in that, I'll be showing you how to debug Javascript effectively using my favorite tools and techniques.

Teaser: Twitch Stream Series on Software Development

Juha-Matti Santala — Tue, 23 Jul 2019 06:59:32 +0000

Do you have a basic understanding and skills to write Python and/or Javascript but would like to get more into how to build full-stack web applications? Don't worry, I'm here to help!

Starting in September 28th, I'll be doing Saturday streaming in Twitch to help you learn how to build a real web application with Django in the backend and React in the frontend. We'll build a single page app (SPA) for tracking personal expenses that communicates between React and Django using a REST API.

You can find my streams at twitch.tv/hamatti and my other upcoming programming videos in Juhis Talks Tech Youtube channel. Clicking a Follow on both will make sure you won't miss the videos.

I've been teaching programming for years but now I want to take it into the next level and start learning filming and editing videos to share my knowledge to an even larger audience.

What programming skills are you learning right now?

Juha-Matti Santala — Fri, 19 Jul 2019 16:25:13 +0000

I guess the people on this site are quite eager in learning new things and improving. I'd love to know what skills (maybe it's building or consuming REST APIs, learning React Hooks or SQL) you are learning right now.

In the comment section, let's work together to help each other learn these things by sharing good ideas, articles, learning materials and so on.

I'm currently working on learning how Electron works and how sharing data between the main thread and renderers work. Mostly by trial-and-error.

DEV Community: Juha-Matti Santala

Learning Rust #4: Parsing JSON with strong types

I started with serde_json::Value

How to define structs for JSON

Then we draw the rest of the owl

snake_case of Rust with camelCase of JSON

Code organizing API response types into a separate file

Dynamic keys

Optional keys

Result? Much cleaner code

Before

After

Before

After

Anything I don't like?

Pull requests for all these changes

How Spice Program supported my creation of 235

What's 235?

Distributing executables is a very different world than web apps in browsers

And my employer supports my work on 235

Learning Rust #3: crates.io & publishing your package

When I was young, we bought software from store

Then I built my first Rust binaries

crates.io

Building binaries

Making a release is more deliberate

Learning Rust #2: Option & Result

What is an Option?

What's a Result then?

So why do I struggle?

What's up with 235?

If I wanna learn Rust, where should I go?

Learning Rust #1: Pattern Matching

Basics of pattern matching

Options and Results

Guards

Conclusion

Advent of Code #1: Getting Started

Why am I so excited about code puzzles?

This year I'm using Rust

Days 0 to 1

First contact with Rust

December 1st

Learning new is exhausting

My solutions

How to ask help for technical problems?

1. Ask your question, don't ask if someone can help

2. Explain what you are trying to achieve

3. Include example input and output data

4. Share the errors

5. Show your code

6. Create a Minimal, Complete, Reproducible Example

Wrap-up

5 key learnings from running a developer newsletter

1. Have a focused topic

2. Start with minimum viable newsletter

3. Focus on your readers

4. Make it easy for people to unsubscribe

5. Do things that you enjoy

My journey in diversity and inclusion in tech

Backstory

Why diversity and inclusion matter?

Why I love using command line interface?

1) You can replicate commands

Using a GUI

Using a CLI

2) History

3) Chain commands

4) Programmability

5) Share commands

6) Automation / scheduling with cron

7) Less change in interface

Conclusion

Teaser: Twitch Stream Series on Software Development

What programming skills are you learning right now?

What is an `Option`?

What's a `Result` then?