DEV Community: Thamara Andrade

Colorall Game Devlog - Creating a game in one week

Thamara Andrade — Mon, 07 Feb 2022 03:56:56 +0000

tl;dr;

I developed a game by myself for the One Minute Game Jam using Godot in just a few days. You can check it and play it online at itchi.io.

How it all began

I will not lie that when choosing courses for college, one of the big highlights of computer science was the possibility of becoming a game developer. But soon I found out there were a lot more options out there and I ended up working with software development in the EDA industry, which I really like. In the past years, after spending a lot of my free time playing electronic games, I was getting more and more curious about what it takes to create a game. So I started watching a tutorial here and there, but nothing beyond that.

The first Game Jam

So jumping to the end of 2021, a dear friend of mine asked me and some other friends to join him on a Game Jam, which I had no idea of what it was really. He explained that it was like a "hackathon", to put in words I was more familiar with. During a determined period, you would work on developing a game that would fit some restrictions and themes defined by the Game Jam. It was not required to be a complete and bug-free game, the important thing was to have fun. That was also when he presented me Godot, a free and open-source game engine, and so, using Godot we developed Bring Ur Glam, a 2D platform/shoot' em up game for the Game Off 2021, where the theme was BUG.

It was a lot of fun working on this game and I think the result is absolutely beautiful. I got to learn a lot about game development and Godot, understanding the basics of movement, collisions, camera movement, enemy AI, and more.

Getting back

After the Game Jam, I was like "when is the next one?", but the end of the year was around the corner and lots of other things were happening, so I let go of this possible new hobby. I would still watch occasional videos on Youtube on this subject, but not get up from the bed to do anything concrete.

A few weeks ago, I opened Godot again for the first time in the year and started doing some experimental things. But, one of my biggest flaws when it comes to personal projects, is that I work hard in the beginning, but when things get to the usual busywork, I get tired and find something else to do. I almost always need someone else with me to get me continuously excited, or need a clear and defined deadline/goal.

One Minute Game Jam

On Sunday, Jan 30th I bumped into this video from Vimlark, which is one of my favorite creators on the subject of game jams and game development. He was highlighting the upcoming game Jams and there was one starting the next day going up to Feb 5th: the One minute game jam. The limitation of this jam was not to make a game in one minute but to create a game with gameplay of less than one minute, and a theme that would be released when the jam started. Five days sounded like something I could handle and the time limitation would make me stick to a reduced scope, so I joined it, and this is how it went.

Day 1: Monday, Jan 31st

The jam started at 20h my timezone and theme was "COLORFUL".

I already had one idea in mind which came to me when I saw the time limitation, but after a few minutes of brainstorming, I could not fit the theme in any way, so I started a new brainstorming session looking for the main concept.

I thought about something related to chameleons, mixing up colors, metro lines, stained glass, and more. But nothing was really clicking beyond "mixing up colors".

So I went with it and started thinking about how the game would be, and settled on something like "you are working on selling paints and need the get the raw material, mix it, and deliver paintings". The way you would get the raw material would be through a match-3-like game, in which, when matching 3 or more of the same color you would get number as paint material, but could also switch two non-matching tiles of primary colors to make secondary colors. You would get a minute and be scored on the number of paintings completed.

As I would only be able to work on this game at night, I begin with the implementation right away. The first thing I needed was the basics for a match 3 game, that is tiles, a grid to put the tiles, and the ability to change tiles placement. That was fairly easy to set up as I found out days before that Godot's tilemap is capable of returning the real position from a tile numbering and vice-versa, so no complex math was required.

At the end of the time I had to work on the game on Monday the really basic blocks for everything was done.

Day 2: Tuesday, Feb 1st

On Tuesday I worked on the system to exchange pieces placement, matching them, registering matches and refilling the board, and also the painting orders. That went kind of smooth, especially after finding this playlist by Mister Taft Creates where they implement a match 3 game in Godot.

After around 2 days, 8-ish hours of development here's what I had:

And it was... terrible! I'm not even talking about the colors, lack of beautification, or anything like this. The gameplay was bad. It was really horrible to focus on which colors I needed to match in order to complete a painting. There was no fun in it. My idea was bad and definitely was not working for a game that should be played in one minute.

I was frustrated and started thinking about how to fix it. The more I tried to adjust it and make it be fun, the more I got sad about everything. Maybe I have bitten more than I could chew entering a game jam by myself.

That's when I took the best decision for this jam: I would abandon everything and start fresh. If I couldn't make it in time, that was ok. I was already in a state of mind where I wouldn't submit anything. If something good came out, profit, otherwise, learning opportunity.

Looking back, I see that I was dealing with the sunk cost fallacy effect, where you had a hard time abandoning something just because you already spend time and energy on it. This unfortunately is something that I see myself doing many times, from continuing a show I'm not liking until the end just because I had already spent so much time on it, to keeping projects on the pipeline because it's 90% complete, even though I don't see it being that helpful anymore.

I went back to my brainstorm document (aka a piece of paper with lots of scribbles) and spend a few minutes just staring at it. That's when it hit me, a game where you have a grid of colored tiles, and, starting at a given point, you can change the color of the tile to match one of its neighbors. Somewhere in the past 1 or 2 years, I had played something similar, but in there, there was a limitation of steps you could take, so you would need to be very thoughtful when choosing a color. But I thought that it could be fun to recreate this, but limiting the time, allowing the player to win more often.

I closed the work on Tuesday with this idea, and the best thing is, I already had the grid. I didn't need all the features to exchange tiles, only be able to change a tile color, which I already had too.

Day 3: Wednesday, Feb 2nd

As mentioned, I already had the basic building blocks for the new idea, it was a matter of cleaning up the code and adjusting some of the functions to work like the flood fill instead of matching 3 or more tiles of a given color.

In a matter of fewer than 2 hours, I already had something that was already working but to have a more realistic feel for the game I started working on a few visual elements, mainly the colors and how the user would select colors.

I'm not that good with choosing colors that would look cohesive, especially because I needed 8 different colors. So I headed to Lospec and selected a palette I liked. This is a great resource if you need some help choosing colors for a game or pretty much for anything. The site has palette lists that are focused on pixel art, but really, you can do anything with that. Now it was time to work on the means of changing colors in-game.

On the left, the initial idea, just a plan small grid with the colors. But this showed up to be not that great. If the player wanted to go from dark blue on one corner to red on the other corner, the mouse would need to move quite a lot and as time is a precious item here, I went with a color wheel, illustrated in the right, this way, the mouse needs to move less between colors. I ended up liking so much this color wheel that I make it the icon for the game, as well as included it in the name of the game.

After throwing some fonts and a timer, the game was already playable:

I send it to a few friends and collected feedback. The feedbacks were great, of course, it was still missing a lot of UI elements as well as sound work, but helped me validate the idea. They also mentioned that it was not completely clear what they needed to do, even though I had sent a brief explanation. So it was clear that the game needed a tutorial of some sort, as well as a better indication that you should use the wheel to change colors, not clicking on the tiles.

But before working on this feedback that was still something bothering me: a player could just start clicking mindlessly on the colors and get a high score, pretty much making this game a "let's see how fast you can click", which was not the idea. To try to force a game approach close to what I wanted, that is, you have to think a bit about what you are doing, I changed to score to be not only the number of squares you complete in the time but to be a function of the number of squares completed minus the number of clicks it takes you, all of this multiplied by the time left. This way the player would be rewarded for being fast, but still needed to think about their moves.

This wasn't still enough, as in the end, in a grid of 10x10 for example, you could still go crazy clicking without thinking and finishing quickly. To solve this I added a click cooldown of 1 second. After this, I tried to break the gameplay I had in mind, and, although theoretically, the player can still not think about what you are doing, most times when I tried to play like this, I end up losing the game, so, this seems to work well.

I finished the day with the main part of the game implemented and ready and had already started working on the main menu and being able to go from it to the game and back. That was also when I settled on the name "Colorall". This was actually my placeholder name, but it started growing on me and I decided to go with it.

Fun fact: a few hours before submitting the game after even with a mostly complete page for the game, I almost changed its name to "Blob", as I constantly saw myself using this word to refer to the initial group of pieces you control. But I realized it would be too much work to change everything, from screenshots to the game itself, and let it as Colorall.

Day 4: Thursday, Feb 3rd

On Thursday it was a lot of busywork. There were a lot of constants hard-coded in the engine and I wanted to make it all parametrized so I could easily reuse everything for different levels. It was definitively worth doing so.

Once I had the main game scene parametrized to the width, height, and some other things, it was just a matter of instantiating the scene with different values and I could have an easy, medium, and hard mode. In practice, the only change between those are the width and height and click cooldown. The easy mode is 7x7, the medium is 12x9 and 14x11. The easy and medium modes have a cooldown of 1 second, and the hard one is down to 0.5 seconds, as it contains ~150 tiles (I tried with 1 second too, but it was just too damn hard).

Initially, the levels would also vary in the number of colors available, but I decided against it just because I would need to introduce a lot of other features just to make this possible. Changing the dimensions of the grid already added enough playing variety.

I also throw a new level selection screen, worked on the music and effects, as well as fixed some bugs that were lingering.

The main feature added on day 4 was the ability to save high scores and notify when a user hit them. The idea is that I have a GameManagere singleton that is initialized before the game and is responsible for loading the player's high score. This component is also notified when a game is finished to save the score (if it's a new high score).

On Thursday's I always meet with some friends over zoom where we play board games online and chat. I used this opportunity to get more feedback. Again, the feedbacks were great! They really liked the game but pointed out that it was still hard to understand what should be done. I took note of everything and started to incorporate the solutions while still on the call with them. I could try a few things, share the screen and get more feedback. To my friends: thanks again! And sorry me not joining as many board games as usual.

As I'm used to sleeping late on Thursdays' I was able to progress a lot and finished the night with a game that was already complete. It had everything I wanted at that point, including a simple tutorial. It stored scores, had some nice sound effects as well as all necessary screens. I could submit the game at that point, which really surprised me. I was sure I would need to pull an all-nighter from Friday to Saturday, but instead, I was able to develop a full game which I was proud of in about 2 days! Of course, with so much time left in my hands, I started to scope in a lot of other things.

Day 5: Friday, Feb 4th

On Friday I basically worked on two things: fixing the bugs and an achievement system. I never thought about how these systems are implemented, so I started researching and watching/reading how other people do this. Turns out, it was much simpler than I thought, at least a system that worked for me in this game.

The way I did was to create a scene that would be an overlay of my game scene (remembering that all levels of difficulty use the same game level). This achievement scene contains just one small container that, when an achievement is unlocked, it will show on the corner. This actual "new achievement" object is set to be destroyed a few seconds after it's added to the scene. I also added some code so that at the most, one new achievement unlocked is shown, this way there's no risk of the player facing a wall of notifications.

The next challenging part of the achievements (beyond writing achievements - like I don't know why but this is really hard to me) is how to display and store them. Storing was actually easier, because, as metadata, I could handle and modify it as I wished, but actually showing it to the user was a different case.

I wasn't completely sure of how many and which were the achievements I wanted, so I wanted to work on something that could be extendable and not hardcoded. It allowed me to mess with the Control nodes of Godot, something that until this point I never really understood.

In the end, after some experimentation, I could create something that I was proud of, like, really proud of. It's not the most modular thing, but it works very well. When adding a new achievement I just needed to make sure to add an object with the achievement id and register that id in the GameManager. The id is later used to query the important things of the achievement like the name, description, and of course if the player achieved it or not.

In the final version of the game I selected 5 achievements that I found fun and interesting, as well as achievable considering a short game session:

Soooo close!: Complete a level with less than 1 second remaining
Full cycle: Complete a level where the last color is the same as the color of your starting blob
Beat the Dev: Get a score higher than the developer of the game (Easy: 1370, Medium: 2411, Hard: 2532).
Saving much?!: Complete a level using at least one color only up to one time.
10x everywhere!: Play a level at least 10 times. Winning is good, but playing is what counts.

At the time of writing this, I actually realized there's was a typo in one of the descriptions for the achievement. Hopefully, nobody will notice. Ooops

What I call GameManager, that is the game manager is also responsible for triggering the achievement notification as well as storing everything. This required some cleanups and also pointed to some bugs in the game. Those bugs were not impacting the game in a bad way, but definitely impacted the computation of the achievements. All the bugs identified were fixed, but most liked there are still many bugs out there. After all, this was developed in a few days.

Day 6: Saturday, Feb 5th

In all honesty, many of what I'll describe later actually took place during the night between Friday and Saturday. I'm usually most productive at night. I get in the zone and just go. This, plus a dentist appointment early in the afternoon of Saturday made me want to finish everything in the dawn of Saturday.

Everything was actually ready-ish. There were some final touches on the achievement system as well as some minutes playing and replaying the game over and over again. A few bugs were caught and fixed and I started to gather screenshots and well as put together the page on itch.io. I wanted a very nice page as I think games with nice and clear pages receive more attention.

In this last mile, I created a lot of releases as I was constantly noticing things that were incorrect or could be better. The major bug found in this phase was that I noticed that I had left all my debug key binds on. While developing, especially the achievement system, I had added code that would trigger specific achievements, just to test everything without needing to actually achieve them, and all these were in the release still. Luckily, there was still time and I removed the debug code and nobody even saw it.

There was just one last feature I wanted to add. When I settled for a game with uses colored tiles, I knew it was not really accessible for color blind people, but I thought it was a compromise I had to make as it probably would take time to improve the game. But there it was, I still had time, so, why not?

To my happy surprise, because I was really using two sprites, one for the tiles and the other for the color wheel, it was easy to create another version of these with symbols on top. So I jumped into Inkspace, throw some random shapes, imported them into Godot, and with a global variable that stores if it's on colorblind mode or not, made the tile and color wheel components select the correct resource.

I do know that there are still many elements that make the game not accessible for many people and even related to color blindness, I may have done better, but I don't think I'm educated enough in this matter to make better decisions yet.

And at around 7 AM on Saturday, I published the game and submitted it to the game jam! Closed the notebook and went to bed. I haven't slept yet. After 5-ish hours of sleep, I woke up to my appointment, and while Uber-ing there I checked the game page and there were already some comments of people liking the game, it got me so excited I even forgot I was sleepy.

After hours

After the Game Jam finishes, everybody who submitted a game can play and rate the games. I'm currently slowly taking in every game submitted and there are some really nice and interesting games! It's really cool to see how other people interpreted the theme and limitations and created unique and cool games.

The final rates will only be available in a few days, but the comments on Colorall have been absolutely incredible. People are complementing the game, the graphics, the simplicity, yet with great execution. A user has even said that "I would download this on the app store for my phone right now.". I'm feeling very fulfilled and really glad that I didn't give up on day 2.

Final remarks

I am very happy with the result and definitely, it was a cool challenge to take on. For sure I'll be doing that again but most likely not in a jam that runs basically only on weekdays. I worked every night of this week on the game and by the end of the week I was so tired, I spend most of the weekend sleeping.

I missed most of the game night with my friends as well as got set up in some other activities I usually do during the week. But Game Jams that would span weekends would totally be doable.

If you want to check the game, it's available in itch.io, and you can play directly in the browser, or download it and play on a Windows machine for a better experience. The code is also available on GitHub.

And thanks one more time to Hamilton, not only for the feedback on this game but for presenting me the world of game development, game jams, and Godot, as well as Bárbara, Arthur, and Daniel who played the game and provided feedback. You are great! <3

Guessing better in Wordle using Python

Thamara Andrade — Fri, 07 Jan 2022 14:34:05 +0000

It's a new year and usually, people tend to make goals of working out, getting more organized, and leaving addictions, and I'm no different. But to my surprise, I started the year with a new addiction I don't think I'll plan to quit so soon: Wordle, that game by Josh Wardle (@powerlanguish) which was even featured in the NY Times.

The idea of the game is pretty simple, yet, very interesting. You have 6 tries on guessing a word per day. On each guess, the game will tell which letters are in the word - in the correct spot and somewhere else in the word - and if a letter is not in the word at all. With this information you try more times, getting more information on each try, up to the 6th or earlier guess where you guesses correctly or you didn't get it.

As you have only 6 guesses per day, this can become very serious. In the past few days, I spent about 15 or more minutes trying to solve this. With many of these minutes it was just me idling, thinking of 5 letter words in English.

But, being the curious person I am, I started wondering what would be the best approach for this. Many theories came from friends and the internet: starting with a specific word, trying to use words with non-repeating letters (even if you are already sure of a letter in a specific place), and more. But, are they right?

So I decided to take on this little challenge of getting these answers using code, more specifically, my favorite language for this kind of thing, Python. But looking back, as I wanted to test different scenarios multiple times, I should've tried using C++.

Disclaimer

From this point on, I'll share pieces of code and information that can potentially be used for cheating. My idea with this was never to cheat in any way when playing (I mean, what's the point?). I haven't used any of the key information I got for this end, and I highly recommend you not spoil the fun either.

In case you want to play with this, I'll be making all the code available on GitHub (link to come soon - ping me on Twitter if the link isn't here yet and I'll let you know when it's ready - still cleaning it up a bit).

I'm by no means the first to think of writing a piece of code that could solve or aid the game. After having the idea some posts started to pop up on my Twitter feed, but I didn't want to get "contaminated" and decided to bookmark those for later. After playing a lot with my solution on Python I went ahead to look at the other's take on this. Tyler Glaeil wrote a really cool article on the mathematically optimal first guess, Rodrigo Serrão wrote a solver in python and shared it on their site, and Bertrand Fan also decided on answering what's the best starting word in Wordle.

Word database

The first thing I did was to find a database of English words. I started with the words from swyl/english-words repository. Later, when I read Bertrand's post, I realized I could actually use the words from the game source code. The results I'll show here are considering the game words, but initially, I only used the words from the first source I mentioned here, which were more than enough for playing with and yield very similar results to the Wordle words.

The database is made by 2315 possible words for each day, with other 10657 words that are less common and are accepted as guesses. So, a total of 12972 words are to be used in guesses and in my experiments.

For all effects, the results I'm showing here are running the tests 1000 times, keeping the same secret words in between experiments, meaning I'll test 1000 different words in each approach and will compare them.

Implementing the game itself

With the word database, I started to implement the game. As the game is simple, so was the code that plays it. The basic structure is like this:

def play(secret_word):
    words = get_all_words()
    for i in range(0, 6):
        guess = pick_word(words)
        result = calculate_guess(secret_word, guess)
        if all(result[i] == Result.CorrectSpot for i in range(0, len(result))):
            print(f"I got it in {number_of_guesses} tries! The secret word was: {secret_word}")
            break
        words = filter_words(guess, result, words, secret_word)

I start storing all the 5 letter words in an array words. And then, iterate 6 times picking a random word from words, calculating the result for this guess, and, if in the result all the letters are in the correct spot, then I know I won. Otherwise, I filter the words on the array with the information I got from the result.

To represent the result I used an Enum and a simple matcher to calculate the result:

class Result(Enum):
    CorrectSpot = 1
    IncorrectSpot = 2
    NoSpot = 3

def calculate_guess(secret_word, guess_word):
    def match_latter(secret_word, guess_word, i):
        if secret_word[i] == guess_word[i]:
            return Result.CorrectSpot
        elif guess_word[i] in secret_word:
            return Result.IncorrectSpot
        else:
            return Result.NoSpot

    return [match_latter(secret_word, guess_word, i) for i in range(0, len(secret_word))] if (len(guess_word) and len(secret_word)) else None

For each letter on the guess word, there's a Result value: A Result.CorrectSpot if the letter in the specific position in the guess word is the same - in the same position - in the secret word. An Result.IncorrectSpot if the letter is not in the same place in the guess word, but it's present in the word somewhere else. And Result.NoSpot if the letter is not present at all in the secret word.

def filter_words(guess_word, result, words):
    # remove the guess_word from the list of words
    words = [word for word in words if word != guess_word]

    # filter by the letters we know aren't in the secret word
    forbidden_letters = [guess_word[i] for i in range(0, len(guess_word)) if result[i] == Result.NoSpot]
    words = [word for word in words if not any(letter in word for letter in forbidden_letters)]

    # filter by the letters we know are in the secret word, in the correct spot
    for i in range(0, len(guess_word)):
        if result[i] == Result.CorrectSpot:
            words = [word for word in words if word[i] == guess_word[i]]

    # finally, filter by the letters we know should be in the word
    existing_letters = [guess_word[i] for i in range(0, len(guess_word)) if result[i] != Result.NoSpot]
    if existing_letters:
        words = [word for word in words if any(letter in word for letter in existing_letters)]

    return words

The filter is very simple. I start by removing the guess word from the words left. Then, I follow on using the information from the result, that is, removing words that have any letter that was flagged by Result.NoSpot, removing words that do not have the letters in the specific locations identified by Result.CorrectSpot, and finally, filtering out the words that don't have any of the letters that we know are in the secret word, tagged by either Result.CorrectSpot or Result.IncorrectSpot.

With this, I was left on how to pick my guesses. My first approach was a naive and the simplest solution I could think of: randomly pick a word from the words array.

def pick_word(words):
    return random.choice(words) if words else None

With my naive solution, the program was being able to win the game 49.7% of the time, with an average of 4.1 guesses. On the losing scenarios, I got an average of 1.3 letters in the correct place found. It was kind of ok, but now the real fun begins. What I can do to increase the winning percentage?

Smart-ish solution

The first thing I wanted to try was to prefer guesses that didn't have any duplicated letters, trying to have more information on different letters on each guess. If there is no word fitting these criteria, then I would fall back to the naive random solution.

def smartish_pick_word(words):
    good_options = [word for word in words if len(set(word)) == len(word)]
    return pick_word(good_options) if len(good_options) else pick_word(words)

With this mode, I got 66.7% of wins, with an average of 4.1 guesses. A good improvement from the 49.7% from the naive, but not as I was anticipating. I believe the reason for this is that at the end of my guesses, I was still left with an average of 12 letters in the alphabet as well as many words to try as in the losing scenarios. In the cases where it loses it only knows about 1.2 letters in the correct place. That's why I called it smart-ish, the idea looked good at first, but not that much in practice.

Smart considering most common letters

To try to improve my implementation, I tried to use the knowledge of the most common letters in English. The idea was to keep the idea of choosing words without repetition of letters, but first, consider words that contained at least 2 of the 8 most common letters in English. If we don't have any words fitting this, then fall back to the Smart-ish solution.

def words_with_common_letters(i, words):
    # filter words that have at least two of the 8 most common letters
    most_common_letters = ['e', 't', 'a', 'o', 'i', 'n', 's', 'r']  
    good_options = [word for word in words if len(set(word)) == len(word)]
    good_options = [word for word in good_options if (sum(1 if letter in most_common_letters else 0 for letter in word)) >= 2] if len(good_options) else []
    return smartish_pick_word(i, good_options) if len(good_options) else smartish_pick_word(i, words)

This improvement barely raised the win porcentage from the previous 66.7% using the Smart-ish solution to 66.9% wins, with an average of 4 guesses to win.

Weigthing the letters

I still had hoped of using the information on the most common letters so I decided to try this in another way. Still, with the idea of preferring words that don't have duplicated letters, I follow on giving weights for the words. This weight is a simple function of using the frequency of each letter in the alphabet as the value for that letter in a word. For example, the letter E is the most common with a frequency of 13%, so the weight of the letter E is 13. The letter T has a frequency of 9.1%, so its weight in a word is 9.1. And so on.

def weigth_words(words):
    good_options = [word for word in words if len(set(word)) == len(word)]
    if len(good_options) == 0:
        good_options = words
    words_weigth = [(word, sum(most_common_letters[letter] for letter in word)) for word in good_options]
    words_weigth = sorted(words_weigth, key=lambda x: x[1], reverse=True)
    return words_weigth[0][0] if len(words_weigth) else words_with_common_letters(words)

When there was no good option without duplicated letters, I would still try to weight all the remaining words. And, after sorting those, I would choose the one with a higher weight.

This yield a good result, with 75% of wins, with an average of 3.7 guesses.

Avoiding any repetition at first

That's the point where I started talking with friends to understand their approaches. One of them told me they tried to use words that didn't have any letter in common with the previous, even if the previous one gave them some knowledge of the placement or existence of a given letter. So I wanted to try this option.

def avoid_repetitions_at_first(i, tried_words, words):
    if i < 3:
        forbidden_letters = [word[i] for word in tried_words]
        good_options = [word for word in words if not any(letter in word for letter in forbidden_letters)]
        if len(good_options) == 0:
            good_options = words
        guess = weigth_words(i, good_options)
    else:
        guess = weigth_words(i, words)

    return guess

For this, I stored all the previous guesses and removed any words that had any letter that was already used. With some tests, I saw that using this only on the first 3 tries yielded better results. Otherwise, when this is not possible - there are no words matching this - I would use the weighting method.

With this approach, I got 76% of wins, with an average of 3.8 guesses to find the correct word. Which Is not that different from weighting the letters, but in practice, for a human approach, is much easier to use.

Starting with a specific word

The last test I wanted to conduct was to see if starting with a specific word would give me better results than any of the previous attempts. This has been the most discussed thing around the game, with some saying that starting with words like "roate", "soare", "orate", or even some words that don't look like words but have a bunch of vowels like "adieu" or "aeons" will give better results. So, I want to put that under a test. I chose to stick to words that actually sound like words because in practice when playing, those are the words I usually try.

The code for this is basically forcing the first guess, and afterward falling back in the avoid repetition method, as it was the one yielding the best results so far. As I had more than 2300 words to consider, and I wanted to run each test 1000 times, this took ages to run. At this point, I regretted not watching out for performance in the code, but I was already committed and went the lazy way - multiprocessing the code.

Going by the numbers, the best word (and again, here I'm only considering words that are more common) to start the guesses is "prism", with 83.4% of victories. But other words like "stomp", "crisp", "sport", "blush", among others were still above 82% of victories. The average number of guesses ranged from 3.7 to 3.9. In total, about 110 words being chosen as first words gave it more than 80% of the wins.

That was very interesting to see because it actually raised the percentage of wins from a previously 76% in many cases, which I was not really expecting to be that different. Also, when checking the lowest scoring words, many words with repeated letters show up, like "queue", "jetty", "woozy", corroborating with the idea of prioritizing words with unique letters. These worst rating words only made about 64% of wins, with an average of 4 guesses.

The words I found in many of the articles are not considered as real-ish words by the game, in the sense they will never be answers to the daily challenges. But either way, I wanted to see how they would behave, and to my surprise, they did not that great compared to the words I found as the best ones to start. Using the word "roate" as a first guess gave 78.1% of wins, "orate", "adieu", "aeons" had between 77.2% and 77.6%, and "soare" only wins in 74.5% of the times.

Summary of attempts

	Naive	Smart-ish	Smart with common letters	Weighting letters	Avoiding repetitions at first	Starting with "prism"
Winning percentage	49.7	66.7	66.9	75	76	83.4
Average tries	4.1	4.1	4	3.7	3.8	3.8

Final thoughts and (possible) future work

At the end of the day, most approaches here are not practical unless you want to use a computer to solve the challenges which is basically taking out the fun of the game, but regardless, I had a lot of fun playing with the code, trying to tweak the algorithms to reach better results. There's still quite a lot of things I would like to try, for instance, perfecting the guesses to better distribute the possible letters when using an approach like avoiding the repetition and doing a frequency and placement analysis of the letters in the possible 5 letter words instead of using the generic frequency of letters in English. My gut feeling is that with better algorithms I could reach something around 90% or higher.

Also, recently a Wordle version in Brazilian Portuguese was released and I would like to see if the same approaches for the English version would work as well in Portuguese.

Based on the not-so-great performance of some of the experiments, I would also consider redoing this in C++, just so I have a bit more room for longer and more expensive computations.

In a few weeks, given that I will not get tired of the game sooner than this, I also intend on returning to this code to see how much better or worst the algorithms are compared to my non-cheating-human-powered results. So far, for the few words I played, I'm doing much better than my best algorithm here as I haven't got any word wrong, but yes, it's too early to conclude I'm better than my computer.

If you got any ideas on how to improve the performance of the algorithm and would like to share, just shout out on Twitter.

Online tools for C++ developers

Thamara Andrade — Mon, 02 Aug 2021 12:54:09 +0000

C++ is the main language I use. It's what pays my bills but more than that, is what gives me a lot of joy due to its complexity and powerfulness. But many times when I'm working I miss the ability to do quick tests without having to compile the code or writing auxiliary structures.

Lucky for me (and for all the C++ developers out there) there are online tools that will ease these tasks. In this post, I'll present some of those tools that I use more frequently and the scenarios where they are the best fit for me.

Learn Cpp

Before everything, this first tip is meant for those that are still learning or want to learn C++. Learn Cpp is a free website devoted to teaching you how to program in C++. Whether you’ve had any prior programming experience or not, the tutorials on this site will walk you through all the steps to write, compile, and debug your C++ programs, all with plenty of examples.

When someones come to me questioning what they could do to become C++ developers, Learn Cpp is my first suggestion. It approaches from the very basic syntax and constructions, passing through data types and inheritance, up to more complex topics and even updates on newer versions of C++.

Source: learncpp.com/

C++ shell

C++ shell as the name suggests is an online C++ compiler shell. It's much simpler than the items that are to come in this list, but it gets the job done. If you want to quickly check something and see the output, it will be enough for you. It does support C++ 98, 11, and 14 and some warnings and optimization levels, but that's it.

This is usually my go-to whenever I want to test some small code to see if it's behaving as I wanted and I'm not interested in anything fancier.

Source: cpp.sh/

Online GDB

Online GDB is like the improved version of the C++ shell. It's also an online compiler, but it also has a built-in feature for debugging using GDB. You can compile, run and debug code, not only it supports C++ (including C++ 11 to 17), it also works with languages such as Python, Rust, and many others.

Source: onlinegdb.com/

Quick C++ Benchmark

Quick Bench is an online benchmarking tool intended to quickly and simply compare the performance of two or more code snippets. It does support different compilers (with many versions available), C++ from 11 to 20 (really!), different optimization levels, and other customizations.

Not only it's super easy to set up the benchmark, but it will also create a chart with the comparison of the snippets. And if you are into it, you can still check the assembly, and see what are the instructions that are making your code slower.

Source: quick-bench.com/

Perf Bench

If Quick Bench didn't sound right to you, maybe Perf Bench will make it. Similar to the previous item, Perf Bench it's an online C++ code profiler. It lets you write and benchmark C++ online and see latencies on charts, comparing performance between different versions of the code.

What I really like about this tool is that it allows to nest different scopes of profilers and specify the number of loops for each profiler. Honestly, most of the time this is a bit overkill to my use, but on specific occasions, it's exactly what I need.

Source: perfbench.com/

Compiler Explorer (Godbolt)

Compiler Explorer is an interactive compiler explorer website. With a huge list of compilers and languages supported, you can see what's the assembly of the code you are writing in real-time. Different tools and visualizations are available and the UI is very customizable.

Although the focus of Compiler Explorer was (and I think it still is) to convert code into the assembly, it also has the support for execution. In this talk on CppCon 2019 from Matt Godbolt, creator of the Compiler Explorer, he presents the history of Compiler Explorer, some of the newer features (at that time), and some of the behind the scenes.

Source: godbolt.org/

Cpp Insights

Cpp Insights is a clang-based tool that does a source-to-source transformation. Its goal is to make things visible which normally, and intentionally, happen behind the scenes. As they say: It's about the magic the compiler does for us to make things work.

You'll be able to see what the compiler actually sees, removing a lot of the syntax sugar we are used to. You can check out the talk from Andreas Fertig on NDC Oslo 2017 where he talks about these hidden costs of the language's features, and Cpp Insights is all about that!

Source: cppinsights.io/

Final thoughts

All the tools I talk about here are available online and have some way of sharing the code snippets with others and some are even integrated, which allows you to bring a code from one to the other with the click of a button.

This by no means will replace having a compiler installed with other libraries you are using, but still, they are great tools for quick tasks, where you want to validate a solution, compare versions of the same code, or just are interested in learning more in-depth information on the compilation/language details.

As an open-source advocate, I also want to highlight that many of these tools are open source. You can check the repositories from their sites and collaboration is welcome.

Hope this is useful, and please share what are the online (or maybe local) tools you use that help you in the development process.

As always, I'm on Twitter @thamyk, just waiting to hear what you think!

Code Review - What is and why you should care

Thamara Andrade — Mon, 26 Jul 2021 14:37:18 +0000

Recently, I gave a talk on Code Review at the WomentTech Global Conference (I even talk about how it all happened in this post). It was such a great experience, I decided to share in a text (and some GIFs). It ended up becoming quite a long post, so my suggestion is to pair the reading with a Chai Latte (or really anything you like to drink).

As always, feel free to talk with me about this, or really anything, on Twitter, @thamyk. Other contacts on my about page.

Story time

Before we jump into code review, let me share two stories with you.

In 1962, NASA launched the Mariner 1, a vehicle intended to perform a Venus flyby. Roughly 5 min after launch, the Range Safety Offices called for self-destruction of the rocket. This caused a loss of more than 327 million dollars.

Some years later, in 1999, NASA developed a satellite that was supposed to orbiter Mars, collecting weather information from the planet, the Mars Climate Orbiter (MCO). But the satellite never really got into Mars' orbiter, becoming lost in space (literally). This caused a loss of 125 million dollars.

What do both of these stories have in common? Well, both have their root cause boiled down to issues in software. Issues that are commonly caught during code review. The Mariner 1 counted with the omission of a hyphen in coded computer instructions, which allowed transmission of incorrect guidance signals to the spacecraft. While the MCO had two important components communicating with each other, one considering the imperial measuring system and the second the metric one. Needless to say, recipe for disaster.

One important disclaimer here is that I'm in no way blaming developers from NASA, nor stating they don't do code review. What I want you to take from these stories is that: software errors can get pretty costly, especially when the software is in production. And I'm not alone claiming this.

A study done by IBM estimated that the cost of an error catch after the release of the product is 30 times the cost if caught during specification.

Code Review will be able to contribute to catching errors during implementation, which helps lower the cost of the development.

What is code review?

We went a little ahead, so let's back down and answer an important question. What is this code review I've been talking about?

Code Review is an activity where one or more people go over someone else's code, proving feedbacks (negatives and positives). During this activity, the following are identified:

Completeness: Is the problem being resolved as a whole? Any missing (and important) part?
Consistency: Is it following the guidelines for the product? And the guidelines for the code?
Side effects: Could this cause unwanted effects?
Maintainability: Will this be easy to maintain? Coming back at this code one year from now, will we be able to understand it and the reasoning behind it?
Tests: Are there enough tests for this? Are the tests covering everything?
Performance: Could this cause performance issues? Is it optimal?

Types of review

There are many ways of code review. Here I talked about 3 types I find more common in the routine of the corporations and projects out there.

Pair programming

Pair programming is a well-known practice in our field. In it, two programmers work on developing something together, using only one workstation. During the development, possible problems are spotted and fixed.

Using this allows for fast response between peers, reducing overhead between finding an issue and fixing it. It's great for solving complex problems, especially when each part knows only half of the domain, or even when both parts don't know much about the problem, and together learn and work on the solution.

The downside of such a practice and one of the reasons why it cannot be used as a silver bullet is that it required the full dedication and allocation of two people.

Live review

Live review, as the same suggests, is when you call for one or more people and presenting the code on a screen, go over it, reviewing together.

Again, the upside is for this type of review is that the turnaround time between peers is reduced. The person who is reviewing can get answers from who developed as they go through the code together. Because of this, it's a great option when the reviewer needs further clarification on the context.

One big issue with this is that it ends up forcing a context switch for reviewers, adding one more (among the many) meetings in their day. The person has to stop doing something at the given time, go to the review session, and later come back to that something that was stopped.

Asynchronous review

Maybe the most common one, the asynchronous review happens, well, asynchronously. The person sends a review request to the reviewers, and they will go over that, sending the comments back whenever they have a chance to look at it. The requester will receive such comments, work on the code, send it back, and after some iterations, the code is approved.

Many tools are available that auxiliaries this process. GitHub's pull request system is one of the most commons, but others are out there.

This breaks some dependencies on the flow, creating specific steps in the whole software development flow, as well as helps to reduce the context switch for the reviewers: they can tackle reviews at their time. But of course, this comes with the penalty of possibly taking more time between the first request and final approval.

Which one should I choose?

All of them!

Each one will fit a different kind of problem, and using one should not prevent the use of another in the same situation. For example, you might have created something using pair programming but still, ask for a review from others. Or do the first session of live review and then submit the changes to a review platform.

The important thing here is to know that these options exist and use them as you need.

Why should I include Code Review in my process

Increase software's quality

If you refer to what is identified during code review, you'll notice that the general focus of this process is to increase the quality of the code. Reduce bugs and also preventing the code from becoming a huge problem in the future.

Increase customer's satisfaction

No customer likes buggy software, so if the quality of the product increases, you'll most likely see the satisfaction of the customers raising too.

Reduce cost

Going back to the story time, bugs are costly, and catching them as early as possible will reduce the cost of the product developed. This might take some time to be noticeable or even go unnoticed, but believe, it's there.

Reduce bus factor

The bus factor is one of the terms I like the most. It is a measurement of the risk resulting from information and capabilities not being shared among team members, derived from the phrase “in case they get hit by a bus”. What would happen to your product if that one person who owns solely an important component gets hit by a bus? Would your product survive? How long would it take to get someone to take ownership of that?

Of course, we don't want anyone getting hit by buses. But many reasons could make someone who is an important key in a project leave it. Maybe the person left the company, maybe it got send to another team, maybe it had to take a leave. It doesn't really matter the reason, the point is your team is left with a big problem in their hands.

By implementing code reviews, even if you have someone to own by themselves something because others are also looking at the code, reviewing it, they start to get a feeling of that too. And, if a bus hit (again, metaphorically), you'll have other people who would be more prepared to step up and assume that.

Mentor of juniors

You might've heard of “we learn things better by doing”, which for the dev world could not be more true. Code review is a step-up on that. Not only someone is doing, but it's receiving feedback from people that know more about the software or the language, helping this person ramp up.

Obviously for this to work you need to count on the collaboration of the more seniors of your team, to not only correct someone but to actually explain and teach on why something should be done in a given way. In my experience, this is not a burden on the review, but instead, is an investment in the future (which pays off really nicely) and an extension of other learning initiatives your team has.

Guarantee project's guidelines

Directly from Wikipedia, coding guidelines or coding conventions are a set of guidelines for a specific programming language that recommend programming style, practices, and methods for each aspect of a program written in that language. These conventions usually cover file organization, indentation, comments, declarations, statements, white space, naming conventions, programming practices, programming principles, programming rules of thumb, architectural best practices, etc.

These guidelines are essential for improving the maintainability of your software, and guess what process can ensure these are kept across all your codebase? Yes! Code review.

Many of these guidelines can be automated by tools and scripts, but still, human inspection is essential.

Increase collaboration

Last but not least, code review allows for increased collaboration in your team. Even if you have a developer working alone in a given task/component, because they are sending their work to review, others get to be a part of the solution too. This creates a sense of teamwork.

Tips for applying Code Review

What to start applying this or even enhancing the process you have today?

Fear not! I have some tips to help you!

Review everything

First and foremost: review everything. Just one line change? Review it. You never know when a possible typo or missing hyphen could cause problems.

Believe me when I say this: sometimes the smallest change can cause a ripple effect you cannot foresee. But if code review is stated, it can reduce the chances of some disastrous changes.

Make lists

If you are starting with reviews, make lists of what you'll be checking. This can help you get comfortable with the flow and after a while you won't need these lists anymore.

Here's an example of a list you can get inspired by (source):

Code formatting
Architecture
Coding best practices
Non-functional requirements: maintainability, reusability, reliability, extensibility, security, performance, scalability, usability

Automate what's possible

How I love automating things. And for code review, this can be your best friend. From the list I mention in the item before, you might be able to spot lots of checks that automated tools can do (instead of the human). Use them to your advantage.

It might take a few manual iterations at first (as any task you want to automate) to get a grip on what and how something should be done. But once you have this, automate whatever is possible and safe and leave the more complex steps to human reviewers.

The idea is not to substitute humans but to use machines to make our life easier.

Plan and share the load

Code review takes time and it should be included in your process and planned accordingly. When planning your and your team's work, take into consideration the time spent on reviews. Not only on doing, but asking for reviews and iterating to fix the possible problems.

Also, share the load of reviews among every one of your team. The idea is not to make someone's job to only do reviews. It should be a task included in the jobs description of each one, regardless of level.

Everybody gets in the game

As I mention, everybody should be included and use the review process. It's not just seniors reviewing code from juniors. Sometimes we need the fresh eyes of someone who is less experienced to spot issues in the code. Use that to your advantage and make a rule for everybody getting into this.

Review before merge

I'm not going to lie: I already convinced myself on a few occasions that I would push/merge some code and do the review afterward, aka, after it was already in production. Such times were commonly motivated by some deadline or critical of the issue and it made sense at the time. But this is a terrible idea! And trust me, I regretted it.

If you have code in production and you need to do some adjustments, things get hard, and possibly you already lost the momentum on that task you were doing and it becomes a big source of a context switch.

So the tip here is to make such occasions as exceptions as possible. Make sure your process has a strict rule of no push/merge without review.

Time management

I already mentioned that code reviews take time. You might be looking into 1-2 hours a day for reviews if your team is big, even more depending on your position and the work you do. Deciding to take those all at once can be problematic.

Several researchers out there tried to measure the attention span of adults, but they have a hard time converging. But you know yourself: how much time can you take a task with all the attention required, not getting distracted by your phone, emails, messages on Slack, or whatever? Whatever your answer was, this should be a limit on the time you take reviews at once.

For me, this time is about 40-45min. So if I have ~2 hours of review to do, I'll break it into chunks. Do some in the morning, as I start my day. After lunch do some more. And finally close to the end of the day. Using this tactic, I can guarantee that when reviewing, my attention is focused on that.

Embrace the subconscious implications

If you are starting to apply code review, if you are a junior, or even if you are just a regular person who puts a lot of pressure on yourself, there's a big chance the idea of showing your code to the world, or actually to a few specific people, might frighten you. You are not alone!

I can say that until this day, after more than 8 years of experience as a software engineer, depending on the work I do or who is going to review it, I get kind of scared. Scared that people will criticize me through my work, or judge me on whatever scale they have. But I can safely say that this fear is totally a thing in my head, and I make sure to never hold me back from doing my job or ask for code reviews.

What I do instead, and leave as a tip for you, is to embrace this fear. Let it motivate you to create the very best piece of software you can. If you get some issues being raised during review, learn from them and improve yourself.

Don't take it personally

Really connect to the last item, never take a review comment personally. You will receive critics, but they are not towards you. They are issues on a piece of code you wrote, and you can (and hopefully will) learn from those.

Final thoughts

I hope I could shed some new light for you on code review. I only scratched the surface, and there's a lot more information on the web if you want to get deeper into it.

I really love and support code reviews. I see it as an essential part that has helped shape the developer I'm today, and even after years of experience, I keep learning new things whenever I ask for a review.

If you want to discuss something about what I talk about here, tell me your experiences with it, I'm more than happy to chat with you. As always, you can find me on Twitter at @thamy, you can send me an email at tkcandrade@gmail.com, or even come by at my LinkedIn profile.

Code Annotation: a VSCode extension for adding notes on your code without commiting

Thamara Andrade — Mon, 19 Jul 2021 15:07:53 +0000

tl;dr;

Code annotation is a Visual Studio Code extension that creates and tracks annotations from your source code without actually committing comments on your code.

You can download Code Annotation directly from the Marketplace.

Problem Statement

When I'm investigating some bug, or just going through the code for some reason, it's very common that I came to some realizations:

Oh oh, this code is too strange, this shouldn't be like this, need to check it later
Damm, this is a horrible name for this method/variable
I need to come back to this function after when popping the calling stack I'm traversing
I need to fix the use of this API here, here, and here (in multiple files)

But because this happens while I'm working on something else, I don't want to stop, take care of it, and get back. So, what I used to do was either to:

Open my to-do list app, insert an entry on it for the future, and possibly not adding enough context for the future making it a useless entry
Add a not-so-beautiful comment like // DO NOT COMMIT: Thamara check this, which usually lead to me forgetting and committing it anyway (and having to remove, rebase, merge, whatever)
Use of the adding breakpoints feature on VSCode, and frequently losing track of why I tagged something, as well as getting my actual breakpoints all mess up

Needless to say, I needed a better system.

To summarize the problem: I wanted to add some notes that would be tied to a code, but I could include a better description of why I was adding that note. I wanted to track what I added and I didn't want to commit anything (read: didn't want to rely on adding TODOs to the code).

I went over several extensions on the VSCode marketplace and could not find anything. So I did the very best thing I do when I have a problem: I solved it myself. If there was no available solution, I would build it.

Code Annotation

Code annotation is a Visual Studio Code extension that creates and tracks annotations from your source code without actually committing comments on your code.

It has a nice panel that shows your notes and their details, including status: completed or not. You can remove/edit/add new notes using shortcuts or right-clicking on some selected code.

You can download Code Annotation directly from the Marketplace.

As an open-source extension, it's available in GitHub and you are more than welcome to contribute to it by reporting issues, suggesting improvements or developing new features.

What I learned: Perfection is indeed the enemy of done

I have started working on this in August 2020, commit the base for the extension, and stopped. Around Hacktoberfest some people stopped by the repository and contributed too (how I love the open-source community!). By November of that year, it was pretty much what it looked on this first public release.

Since November, I've been using it, but put off publishing it for "a bit". What took less than 2 months to be done (August and October), took 8 months for me to publish it. YES! EIGHT MONTHS.

I initially put the blame on it working so well and solving my problem that I forgot about it, but the truth is that I wanted the first version to be a super complete extension. I have so many ideas, but this would require the time I didn't want to commit to.

That was when I bumped into this article on "Why Perfection is The Enemy of Done", and let me tell you, the shoe fitted.

So, I decided to publish anyway. Did a few minor adjustments and released it to the world.

After a few days, I presented it to some coworkers and they loved it! They had the same problems as I (some didn't even realize that until I pointed out), and they were more than happy to start using it.

So, lesson learned: Done is better than perfect.

As always, you can find me on Twitter at @thamy, tkcandrade@gmail.com, or LinkedIn.

My learnings while becoming a conference speaker

Thamara Andrade — Mon, 12 Jul 2021 14:28:41 +0000

Before everything

In 2020, before the pandemic hit us, I had included in my life goals to attend a tech conference. With COVID and most of the conferences being canceled or postponed, I thought this goal would set sail (among many of other of my goals). But then everybody got used to the idea of virtual conferences and I had the opportunity to attend CppCon. I talked about this experience in this post.

At CppCon I got to know many of the speakers that I only knew before through YouTube, blogs, and Twitter, and to my surprise, they were like, real people. I know this sounds dumb, but believe me, it was how I felt. This was really important to me because it demystified the whole speaker role, and the path to becoming one started sounding so much accessible.

I had a dream, and then, another dream, and then it was reality

By then, I had another life goal: speak at a conference. And again, what I thought would take some time, happened in November of 2020, when I gave a talk on She'sTech conference, the largest event of women in tech from Brazil. I was overwhelmed by happiness, and again, I raised my goal to talk at an international conference. And well, it happened.

It started with an email from the Women in Tech group at the company I work for. It was a list of next conferences with the call to papers open. One of those was WomenTech Global Conference (WTGC). As I had already prepared a talk on Code Review for the She'sTech conference, I decided to go with this topic, as I was already comfortable with the topic.

I applied on a Sunday night, and, before even having time to speak and notify my manager of my intentions, on Monday morning I received the email stating that my talk was approved. The company I work for encourages joining such opportunities, so it wasn't a problem to have the talk approved before having time to talk with management. It was all sorted out, and I gave the presentation in June 2021.

What I learned in this process

So, what I learned from these experiences? First and foremost, I learned that I really love giving presentations on topics I'm passionate about. This was already something I was pretty used to in more intimate environments, but talking to an audience that I didn't know was still pretty frightening. This didn't hold me back and has only made me stronger.

Don't sell yourself short, you have something to share

Choosing a topic to talk about was possibly my main struggle. What could I share with the world? I had to work on changing my mindset and stop thinking that what I had to say was already public domain. This took some practice, but most of all, it took a lot of work on stopping underselling me.

Once this mental switch was flipped, and I must add that it was not overnight, I could start thinking about topics I felt ready and comfortable to present to others.

Be ready to receive NOs

This whole post is about the YES, but believe, there are NOs too. On my first no, I felt horrible, and after a few time to process it, I learned that sometimes it's just a matter of your presentation not fitting in the conference. Other times you just got unlucky. I kept trying, adjusting and didn't let it take me down.

Your presentation doesn't need to exist for you to submit the call for papers

Most call for papers doesn't require the full presentation to be ready. Instead, they ask for the outline, takeaways, and target audience. This should be simple to get ready if you have already the idea in mind. Understanding this prevented my perfectionist side from stopping me.

Takeaways

Ok, if I didn't need the full presentation ready, how can I define the outline? The answer: think about the key takeaways. This should be what you want the audience to leave out of your session, and work on the presentation should deliver this. Writing those down helped me shape and define the outline, and later, guided my work on the actual presentation.

Words are hard

Names are the worst. But naming is very important. This is probably what will catch the attention of the audience before even reading the outline for the talk. When brainstorming names, I focused on names that would be catchy and instigate the interest of others.

Ask for feedback

Especially if you are a first-timer speaker, ask for feedback from friends and coworkers. This is valid even before submitting the call for paper. Discuss what are your intentions, what kind of information you want to pass, and how you think of doing this.

If your talk was approved, schedule some time with those close to you and present it to them. This will help you not only with the content, identifying what you need to explain better for example, but also work as a dry run to get the feeling of the time and possible questions.

A friend of mine does this thing where he presets and asks for feedback from his wife, someone who isn't in the same field as him. If she understands, the presentation is great. This might not be true for every domain, but sure is something to try out.

I have done all of those, from presenting to my parents to presenting to friends who are highly skilled at the topics I choose, and I could not be happier with the feedback. It allowed me to change some details and make the presentations better.

Final thoughts

A talk is always about telling a story, and we do this every day: we tell stories about our life, what we have done, what we will be doing, everything. Conference speakers are out there telling stories just like we do in our daily life, the difference is that they already overcome the fear of public speaking (some might still even have it) and had worked on learning how to tell the stories to others.

If you want to get in touch, you can contact me on Twitter (@thamyk) or by email at tkcandrade@gmail.com.

How to sleep... in different programming languages

Thamara Andrade — Tue, 16 Feb 2021 17:56:31 +0000

Every now and then, as a developer, we need to add a sleep in our code. Usually to make some test work, or god knows the reason. In particular, I use this a lot in Tcl, as this is the primary language for the tests I write at work. And there was not a single time where I tried a simple "sleep" command, only to have it fail. The reason? In Tcl, the sleep command is actually "after", something I find exceptionally not natural.

To prove my point on the wrong name for such command in Tcl, I decided to investigate how the same is achieved in different languages. In all examples below, I'll be implementing a sleep of 3 seconds and judging the language on the way it allows the sleep to be implemented. The languages I choose are based on the most popular programming languages, which I found on some random site, and I cannot guarantee the veracity.

Please note that I'm not proficient in many of the languages I mention here. Feel free to contact me on @thamyk if you found some error, want to give feedback, or think I should change my grades.

C

sleep(3);

8/10, does not allow precise units unless you want to use usleep, but still is limited to microseconds or seconds.

C++11

Using chrono and thread libraries, is as beautiful as:

std::this_thread::sleep_for(std::chrono::seconds(3));

10/10, beautiful and expressive.

Go

Using time package, it's pretty simple:

time.Sleep(3 * time.Second);

10/10, direct and offers a simple way to convert between the units.

Java

Thread.sleep(3000);

8/10, simple but only accepts milliseconds as the parameter.

JavaScript

As far as my research and knowledge go, there's not a way of stoping the execution of Javascript. Still, there's something similar that can be achieved using a callback, like the following:

setTimeout(function() { doSomething(); }, 
           3000);

5/10, at least allow something similar to be done, but not in a good way.

Python

Using time module:

time.sleep(3)

8/10, very practical, but requires the argument in seconds.

Ruby

From my investigation, you can simply use a sleep function or use the ActiveSupport library:

sleep(2.minutes)

10/10, maybe the grade should be lower if using ActiveSupport is not something ordinary.

Rust

For being syntactically similar to C++, the sleep function is also similar to C++, using thread and time libraries:

thread::sleep(time::Duration::from_secs(3));

10/10, allow easy conversion between units.

Scala

As a close friend of Java, Scala's sleep is pretty much the same as Java:

Thread.sleep(3000)

8/10, simple, direct, but requires milliseconds.

Swift

As I have absolutely no proficiency in Swift, I'll be sharing two options for this. The first one is based on Unix's sleep command, and the second one is closer to the implementation of a callback. (Based on this stack overflow question)

Option 1:

sleep(3)

Option 2, considering Swift >= 3:

let seconds = 3.0
DispatchQueue.main.asyncAfter(deadline: .now() + seconds) {
    // Put your code which should be executed with a delay here
}

6/10, does allow sleep in multiple ways but rely on Unix syntax or require you to use a Dispatch Queue and some other logic.

Tcl

Argh!

after 3000

1/10, terrible name, but at least allows the sleep, and just for this will get one point.

Final thoughts

First of all, I must say that using a sleep in your code is not the best solution in most cases. Still, as I mentioned before, there are indeed scenarios where you do want that. Based on this, I was astonished at how easy it's in most languages to do what is desired.

The drawback of many languages is the necessity to remember precisely the type of unit you need to use on the call (gravitating between seconds and milliseconds).

Some languages seem to overcome such limitation through external libraries, which I think is a great solution and would be great if somehow this could be incorporated in newer releases of the language.

That all being said, I conclude this post with the confirmation: Tcl has the worst command for sleep!

Finally got an answer to a long-lasting question - How many times I watched a show on Netflix

Thamara Andrade — Mon, 16 Nov 2020 00:20:05 +0000

I subscribe to Netflix for almost 10 years now. Of course, I have my favorite series and movies that I repeatedly watch, especially before bedtime. With this, I came to memorize many scenes, especially from Friends, Brooklyn 99, and Modern Family. I always wondered how many times I watched a show, but Netflix never gave me that answer. Until now.

A few days ago, I found out it was possible to download all my data from Netlix, which included my viewing history. As the name suggests, the viewing history has the logs for all the things you watch on Netflix, with time, duration of the session, content title, and more. So, it was just a matter of manipulating the data little, and I would finally have the answer to a question I have for a while.

The straight (and boring) answer

My first approach was pretty straightforward, using all my knowledge from Excel, creating some formulas to filter and sum the hours. A few minutes later I got my answer, and to my surprise, I found out I had watched Friends almost 20 times!

I got my answer, but let's be sincere, how much fun is a little cell on Excel? There was so much I could still do and also make it beautiful. It was also an excellent opportunity to write some Python and play with D3, something I've wanted to do for a while. I often feel the need and the opportunity to use D3 but haven't gotten familiar with it.

tl;dr;

If you don't want to read the details, you can go directly to this example page, to see the report format. Or to this project GitHub page where you can fork/download and use on your own data.

The data

I'm by no means a specialist in Data Analysis or Data Visualization. Still, I know that the first step in working on a data set is to understand it, and that's what I did. Alongside the information Netflix makes available from your account, there's also a Cover Sheet that contains all the documentation for all the data you'll receive. This made it very easy to understand all the fields in the viewing activity CSV file. Here is the crucial information from it w.r.t. this project:

Profile Name: the name of the profile in which viewing occurred
Duration: the length of the viewing session
Title: the TV show or movie viewed
Supplemental Video Type: Videos other than a TV show or a movie (such as trailers)

For my analysis, I wanted to ignore all the entries where "Supplemental Video Type" had a value: the different videos such as trailers, recapitulations, etc.

Title adjusts and extraction

From checking the data, I could see that I would be able to also break down the titles to recover in case of a TV show, what the show was, the season, and the episode. Here are a few examples of the titles of a few entries:

Brooklyn Nine-Nine: Season 6: The Honeypot (Episode 7)
The IT Crowd: Series 3: Tramps Like Us (Episode 3)
Chilling Adventures of Sabrina: Part 1: Chapter Eleven: A Midwinter's Tale (Episode 11)
Skins: Vol. 2: Tony and Maxxie (Episode 1)

As you can see, although there is not much consistency between the naming of the seasons, with one regular expression, I could capture the series title, the season, and also the episode name. This might fail for some languages/shows, but it worked pretty well in my data as a heuristic. I had to add some translations because my data had entries both in English and in Brazilian Portuguese. The regexp looks like:

r'(.*): (Season|Part|Vol\.|Series|Chapter|Temporada|Parte|Universo|Capítulo) ([ a-zA-Záéíê\d]*( Remix)*): (.*)'

Duration

To make my life easier, I decided to convert all the durations from the format "HH:MM:SS ", to a single integer seconds. This allows me to sum all the durations without caring for the format. Later in the flow, I could just convert back from seconds to some more user-friendly value.

# 0:01:05 -> 65
def durationTimeToSeconds(duration):
    try:
        [hour, minutes, seconds] = duration.split(':')
        return int(hour)*3600 + int(minutes)*60 + int(seconds)
    except:
        return 0

# 65 -> 00:01::05
def secondsToDurantion(seconds):
    hours = math.floor(seconds/3600)
    remainingSeconds = seconds - (hours*3600)
    minutes = math.floor(remainingSeconds/60)
    remainingSeconds = remainingSeconds - (minutes*60)
    return '{:02d}:{:02d}:{:02d}'.format(hours, minutes, remainingSeconds)

Processing the data

I think now is a good time to say that my Python skills are not the best, and on top of that, I'm really rusty. There's possibly a lot of better ways of doing what I'm doing, so don't focus on how I'm solving the problem, and don't take that as the correct way. Anyway, let's continue.

My script starts by processing the CSV information, filtering the data I don't want (in this case, only ignore trailers and the particular kinds of video), and creating an array with the specific information I want, as well as the profiles available in my account. From that, I break it down into two sets of data, movies, and series. Basically, what I do is sum up the balance for all the occurrences of the same entry in each profile.

Well, at this point, I do a lot of for-loops and a lot of ifs, and in the end, I got data in the format:

# for movies
{
    'profile 1': {
        'movie 1' : 3974,
        'movie 2' : 3412,
        'movie 3' : 3974
    },
    'profile 2': {
        'movie 1' : 3974,
        'movie 4' : 3780,
        'movie 5' : 2629
    }
}

# for tv-shows
{
    'profile 1':
    {
        "serie 1": {
            'season 1': {
                'episode 1': 241,
                'episode 2': 3552
            },
            'season 2': {
                'episode 1': 241,
                'episode 2': 3552,
                'episode 3': 3512
            }
        }
    }
}

Viewing the data

My goal was to generate an HTML page where I could see the data and interact with different types of visualization. But I didn't want to write strings in python that would later be written into a file. In my experience, this can make the script quite big and confusing, so I decided to use Jinja, a "modern and designer-friendly templating language for Python, modeled after Django's templates".

To use jinja you basically create a template, which in my case is a HTML file, and, on the places you want to include specific information, you call render, passing the data to be replaced/added. Something like:

loader = jinja2.FileSystemLoader('template.html')
env = jinja2.Environment(loader=loader)
with open('output.html', 'w') as output:
    output.write(env.get_template('').render(variableToReplace=values))

Table

To start I wanted a simple table with all the data. This helped me understand better the data, see what I was doing wrong, specially around extracting the information from the TV shows. With Jinja, this was pretty easy. In my HTML template file, I created a table, and added jinja's tags:

<table id="watched-table" class="table table-striped table-bordered" style="width:100%">
    <thead>
        <tr>
            <th>Profile</th>
            <th>Movie</th>
            <th>Type</th>
            <th>Watched time (HH:MM:SS)</th>
        </tr>
    </thead>
    <tbody>
        {% for item in watched_table %}
        <tr>
            <td>{{item.profile}}</td>
            <td>{{item.title}}</td>
            <td>{{item.type}}</td>
            <td data-order="{{item.total_seconds}}">{{item.total_time}}</td>
        </tr>
        {% endfor %}
    </tbody>
</table>

Jinja accepts an array and is capable of doing the iteration on the fields. All I needed to do is create an object in the format expected (with profile, title, type, total_seconds, and total_time), and boom! The table was being built as expected.

Visualization

I wanted something like a treemap for the visualization, allowing me to see the information on different levels (user, movies/series, season, etc.). Checking the examples on D3's page, I thought the Zoomable Sunburst was a great option. Later I came to find the Zoomable Sunburst with Labels, which was almost perfect.

For those not familiar, D3.js is a JavaScript library for manipulating documents based on data, helping you bring data to life using HTML, SVG, and CSS. The example's page has many beautiful visualizations, and it's a sight for sore eyes!

Anyway, I was able to use pretty much the same code as in the example, only changing a few things on the labels and titles. The hardest part here was actually generating the file in the expected format for d3. (I won't go into details, but you can find them in the script on GitHub).

I was amazed that even though I had quite many entries (almost 40k), D3 generated the SVG image in little time. The use, however, not the smoothest, is pretty responsive.

With this, I completed my first milestone for the analysis page, and you can see an example (with real data) in this page.

Future work

While working, I noticed that a lot of things can be improved. Mostly new visualizations can be added, tackling portions of the available data, but I haven't worked on yet.

Final thoughts

I know many people have done much more in-depth and much more complicated analysis on the Netflix data and made that available. Still, considering my personal goal of writing some python lines and work with some different technologies, this project was a great success. I had a lot of fun with the data, thinking about what I wanted to display, and especially how.

I'll consider working on this a little more, improving the visualization, and making the use of the script easier (maybe publish it as a notebook?). If you have any suggestions or have any problems running the script, you can find me on Twitter.

How to make someone's day in under 5 min

Thamara Andrade — Thu, 15 Oct 2020 10:14:55 +0000

Over the weekend, I got an email notification from someone I didn't know. The subject read, "Thank you for your GitHub post!". I got curious. This person was thanking me for one issue I fixed in my own Open Source App a few months ago in the email. That has allowed this guy to understand and resolve an issue that was blocking him for 2 weeks. This has made my day. It was amazing to know that something I was doing for my own purposes had a positive effect on someone else's life.

This person probably spent less than 5 minutes writing the email, and as a side effect, caused me to be happy a whole day.

Some days ago, I sent a thank you message to someone involved in the organization of the scholarships for the CppCon (I talked more about this in this post). Just by hitting send, I felt good because I was acknowledging the effort someone (actually a lot of people) put into doing something unique that had a significant impact on me. In the reply, the person thanked me for taking the time to send it, which only made me even happier. In this email, this person also shared that often they don't hear back from people, so my message was extra-appreciated.

On a personal project with a few friends, we help women build stronger resumes by giving feedback on their current CV. When we send the feedback, we also send a link for a survey on their expectations and what we could do better. As for today, we have already reviewed around 115 resumes; from those, only 25% have filled the survey. Often, those who respond are grateful for the work we've been doing. On some occasions, they even follow up thanking us for helping them be more confident and get a new work position. When this happens, it shows us we are on the right path, which makes our work totally worth it.

If complimenting makes us feel better and makes the day of someone else, why don't we do it more often?

I invite you to try to enforce it on your day today. Identify the people and the occasions, and give genuinely complements. It should take you less than 5 minutes and has the great potential of making the person's day.

Remember, there's no size for the impact; maybe someone wrote a tweet that had a considerable effect on the way you work and live, or perhaps someone spent a lot of effort in preparing a presentation or event that you attended, and, even if the person was only "doing their job", take a few minutes and acknowledge the excellent work and make this person's day by complimenting them.

Photo by Jacqueline Munguía on Unsplash

Contributing to Open-Source, a brief how-to

Thamara Andrade — Sat, 10 Oct 2020 09:21:51 +0000

October is here, so it is Hacktoberfest, an event by DigitalOcean in partnership with Intel and Dev to celebrate Open Source and get more people involved with it.

As someone who found in open source a lot of fun and knowledge, I'm always talking to others to join this party. Still, usually, I get the following answers:

I don't know Git and Github...
I don't know how to program...
Where do I even find a project to start with?

To answer all of that, and much more, I got together with Tulio Leão, a dear friend that shares all my excitement regarding open-source, and we hosted a virtual Meetup on Youtube to answer all of that.
If you are a Portuguese speaker, you can check the recording in here.

In this post, I will cover a summary of the event, hoping it can be useful for someone who wants to start contributing to open source.

Git

Git is the kind of skill that, doesn't matter what you do, mastering it should be useful. If you are a developer, you probably already know Git or any other form of source control, and that's great! The hardest part of learning git is understanding the concepts; if you already know something, it should be a matter of adapting to the commands.

Explaining Git from the beginning should take more than one post, so I leave this to you. I suggest you start and my new favorite game-ish site Learn Git Branching, where it will explain you the concepts of Git, step by step, and you can practice directly on the site (no need to worry of messing something up). Git's own page is also a great resource, with a completely free book on git commands.

GitHub

As you would expect, GitHub is related to Git, in a way that it's a hosting platform for version control (usually Git) and collaboration. Basically, it's a source of repositories where multiple people can work simultaneously. Besides this, it also adds lots of functionalities to improve project management, such as an issue tracker, continuous integration, wikis, and much more.

The best way to learn how to use GitHub is by actually using it. So let me walk you through what a usual work is using GitHub:

GitHub Workflow

First of all, we need to find a project (there will be more tips at the end on how to find those)
When you find one project you want, you can browse around, check the code, the issues, what people are doing, until you find something you feel comfortable taking
You fork the repository to your account, kind of creating your own copy of it for you to clone and modify
In your fork, you start a new branch for your modification
Now it's time you start coding or doing whatever was the task you meant to do; this will become commits in your own fork of the project
With your changes done, you push the commits to your fork
From your fork, you open a Pull Request (or PR for simplification); this is saying to the maintainers of the project that you did something and is ready to share with them
The maintainers (or actually anyone interested) will review your changes and point to some things you need to change. This step might take some time and some iterations until it's all good.
With the change approved, now it's up to the project's maintainers to merge your PR, thus making it available in the standard branch of the project, and guess what?
You are done!

The flow can change from project to project, but this is considered the typical case. All of this is beautifully illustrated and explained in GitHub's Understanding the GitHub flow.
In my presentation, I illustrated this scenario; you can check it here.

Coding is not the only skill required to contribute

When we think about open-source, usually we imagine a developer or someone who knows to program. If you don't know, you may think open-source is not for you. Well, this is entirely incorrect. There are many different roles in projects, and for sure you can find something you can help.

Here are a few examples (there are many more) of roles you can assume to contribute to open source:

As a user: Yes! Open source projects need users, especially those that are willing to give feedback on the project. This can be opening issues, proposing enhancements, and a lot more. As a user, you are not required to understand a single line of the code or the project's infrastructure.
As a manager: Most projects have some sort of a software development process established in terms of releases, task organization, features prioritization, and more. You can help to manage it, with a higher-level view of deliveries and again, without actually needing to code a thing. As a translator: Lots of projects have a way of localizing its content. You can help translate it to the languages you are familiar with or even just reviewing previous translations.
As an artist: At some point in my life, I heard that developers don't know how to draw. Although I disagree this is true, many projects out there will benefit from someone with a more artistic view. This means that there are tasks for you to work on the branding or on specific components that need an artsy touch.
As a documentarian: if there is something that any project is missing at some level, it is documentation, not only on the code itself. We are talking about the documentation of the tool or whatever is the product of the project.
As a reviewer: Code reviews are essential, and on the open-source, I think it's vital. But many times, the maintainers of the project cannot undertake all the work, and you can help them by doing reviews!
As a developer: that's the obvious one, but it's not apparent that you don't need lots of experience in a language/technology to contribute. You can even use it as a way for you to improve your skills.

Where to start

Finding a project to start is maybe the most challenging step when we talk about open source. My first suggestion is to check the products you already use; chances are that some of those are open source. Because you already use them, it will be easier to understand the project's scope and intent. Sometimes this can be a little challenging, so there are other paths.

Under a project on GitHub, you'll find that the issues have different labels, some of those with great names such as "good-first-issue" or "first-contributors", and more, indicating those that are more straightforward tasks that you can work on to get you more comfortable with the project and the flow.

You can search for these labels directly on GitHub, or you can check the pages below:

As this is my post, I can do some advertising some of my own projects too, right?!

Time to Leave: A working hours tracker that notifies you when it's time to leave. It's based on Electron and written in JavaScript. You can help with development, translation, testing, and whatever you feel like, really.
Code Annotation, a VSCode exntension: A VSCode extension that allows you to create annotations (like todos) on your code, without actually committing the changes. As this is something, I have started recently, any kind of help is welcome!

Final thoughts

I hope this has inspired you a little bit more to contribute to open source. I've been actively contributing to several projects, including creating my own for more than a year now, and I can't even measure how much I learned during this time. Especially over the past months, due to Corona and such, this has been the hobby that has helped me keep my sanity.

If you have any questions, feel free to get in touch on Twitter over @thamyk. I would be glad to help you on this journey!

What if I need to make a change in node_modules?

Thamara Andrade — Fri, 11 Sep 2020 01:46:49 +0000

I have an application build on top of node/electron, and recently, because of an update in the electron, some dependencies have broken down, preventing me to upgrade to the newer versions while keeping all functionalities.

In such cases, the correct behavior would be to reach out to the dependency, and open an issue, or even submit a Pull Request, but what if your dependency is not maintained anymore, or the development process on such repository is stalled or slow, and you really need to move on with your development?

That was the scenario I was facing. The change I needed was very localized, but I could not, in a million tries, get to make it work on my fork of the dependency. To make things worst, the last commit on the repository was over 6 months ago, and no sign of a reply on the issue I opened in a week.

That's when I found patch-package, a package that lets app authors instantly make and keep fixes to npm dependencies.

ds300 / patch-package

Fix broken node modules instantly 🏃🏽‍♀️💨

patch-package lets app authors instantly make and keep fixes to npm dependencies. It's a vital band-aid for those of us living on the bleeding edge.

# fix a bug in one of your dependencies
vim node_modules/some-package/brokenFile.js
# run patch-package to create a .patch file
npx patch-package some-package

# commit the patch file to share the fix with your team
git add patches/some-package+3.14.15.patch
git commit -m "fix brokenFile.js in some-package"

Patches created by patch-package are automatically and gracefully applied when you use npm(>=5) or yarn.

No more waiting around for pull requests to be merged and published. No more forking repos just to fix that one tiny thing preventing your app from working.

Set-up

In package.json

 "scripts": {
+  "postinstall": "patch-package"
 }

Then

npm

npm i patch-package

You can use --save-dev if you don't need to run npm in production, e.g. if you're making a web frontend.

…

View on GitHub

The README has all the information you'll need, but I'll summarize here the idea:

Install patch-package (using npm or yarn)
Update the scripts rule on your package.json to include a call for patch-package:
```
 "scripts": {
+  "postinstall": "patch-package"
 }
```


3. Do the change you need on the dependency, directly on node_modules
4. Call patch-package specifying the package you modified:

    ```


    (npx | yarn) patch-package package-name

The last command will create a patch file (a diff) in `patches/`, which is a diff between the public dependency and your changed version.

Commit the changes, including the new patch file and everything will be working as expected.

Now, whenever you (or someone) calls install on your repository, patch-package will be called, applying that change on it.

Problem solved!

What about you? Have you ever needed to take a similar action?

We are not all guys, we are not all he

Thamara Andrade — Wed, 09 Sep 2020 04:30:53 +0000

I have to warn you, if you don't already know the issue with "guys", you are about to, and this will forever change you.
This is an outburst that many women and non-binary people might relate to, and I ask for the men who found this to continue reading and empathize with the cause.

So, what's the problem with "Guys"

tl; dr;: heyguys.cc

Well, the problem is that "guys", is not as inclusive as you think. People who aren't men can feel excluded when addressed as "guys," even if that is not the intent. And, from the moment you (especially if you are not a man) realize this, forever you'll feel discomfort when people say the two words "hey guys" (and all its variations).
The problem is even worst when we have it in the singular form. Recently I heard "I will take this to the RD guy", but I was the RD person, me, a woman, and the person who said it knew that. It bothered me. And we see this kind of thing every day.

The solution

At a glance, the solution is simple: replace guys with other words, or get rid of that for complete.
"Hey guys", can become "Hey folks", "RD guy" can easily be replaced by just "RD". And in the cases where you want to specify a group, why not replace "RD guys" by developers?!

The difficult part here is that we are used to these sayings, and changing them requires a mental effort and some attention. Kate Gregory goes deeper into this issue, even pointing out that "people" also means "men" in her post Thoughts about "guys", which I highly suggest you read. In there she concludes:

The hard part isn’t figuring out how to reword the sentence to avoid the word guy or guys. The hard part is breaking the habit.

What about the "he"?

How many times you heard or read something like:

Each user of the program will input his login and password.

Notice anything strange? I'll point to you in case you missed: We are using "his" as the pronoun for "user", even though we want to be generic.
This happens a lot, and if you are not a he, you'll probably notice that already.

The solution

You could rephrase your sentences saying "he or she", or "his or her", which is a much better option, but something that has been gaining some space in the English language, is the use of the singular they. The singular they, as the name suggests, is the use in of the pronoun they or its inflected or derivative forms, as a gender-neutral singular pronoun.
I'm extremely pro the use of the singular they, but there might be some public that dislikes it, so its usage is not well established yet. If you feel this is the case of the public you usually speak to, there are alternatives still.

In the article of Gender-neutral Technical Writing by Tech Whirl, we have several suggestions on how to have a gender-neutral vocabulary, without butchering the language. Here are a few examples:

Bypass the problem of gender whenever possible: Use imperative mood when talking directly to the user (usually in instructional manuals) or use second person instead of the third person (you vs he/she)
Use plural nouns and plural pronouns instead of their single counterpart
Avoid pronouns completely when you can
Use generally-accepted titles: engineers, programmers, users, etc

Last thoughts

For those who reached here, thank you for listening. At first sight, these might look like ridiculous rants, but the ugly truth is that this is just another example of how (especially) the tech industry is not an inclusive place. Paying attention to the language is a small step towards a better and diverse ecosystem.

After reading, tell me, what do you think of this?

Title partially borrowed by Clare Macrae.
Cover photo by The Climate Reality Project on Unsplash