lessons learned - freeCodeCamp.org

What I Learned from Maintaining a Repo During Hacktoberfest and Merging 356 PRs

Jessica Wilkins — Wed, 02 Nov 2022 16:17:06 +0000

Hacktoberfest is a month long celebration of open source. And this year I participated as a maintainer for freeCodeCamp's Developer Quiz Site.

I merged a total of 356 pull requests and helped a lot of new contributors get started with open source. We were able to add a total of 477 new quiz questions to the Developer Quiz Site.

Here are some more statistics:

Stats on Oct 1, 2022

Number of questions: 694

Forks: 61

Stars:42

Stats on November 1, 2022

Number of questions: 1171

Forks: 246

Stars: 109

This month long journey has been crazy, productive, fun and educational. Here are all of the things that I learned during Hacktoberfest 2022.

How it all began
Preparing for Hacktoberfest
Lessons I learned during Hacktoberfest
Conclusion

How it All Began

In December of 2021, freeCodeCamp was launching their Learn to Code RPG game. It's an interactive visual novel that follows Lydia's dream of becoming a developer.

I was involved with helping to create quiz questions on topics like HTML, CSS, Computer Science, Python, and so on for the initial launch.

About a week before the launch, Quincy approached me and a few others to build out a Developer Quiz Site. This was meant to be a companion site to the Learn to Code RPG game and provide campers with a way to practice more quiz questions outside of the game.

The initial launch of the Developer Quiz Site had about 600+ quiz questions. We also created a few open issues in the repository for the community to add more questions to the site.

During parts of 2022, there was a moderate amount of activity in the repository but a lot of the time it remained rather slow. But once September rolled around, I thought about entering the Developer Quiz Site into Hacktoberfest.

I reached out to Quincy and he thought it was a great idea because we could use this opportunity to get more quiz questions from the community.

Preparing for Hacktoberfest

There were about 3 weeks left before Hacktoberfest started. Here is how I used that time to get the repository ready.

Step 1: Adding the Hacktoberfest topic and labels

The first step was to add the Hacktoberfest topic to the repository so people knew we were participating in this year's event. I spruced up the About section and added the appropriate labels to help invite people to the repository.

I then made sure to create the hacktoberfest-accepted label so I could apply it to each approved PR to help us keep track of the total number of Hacktoberfest PR's. I also added the spam, hacktoberfest, and first-timers-only labels because I knew they would come in handy.

Step 2: Creating issue templates

GitHub issue templates are a great way to ensure that contributors provide all of the necessary information for bug fixes, documentation changes, feature requests or general issues.

I decided to setup 5 issue categories and make certain fields required so contributors would provide some level of detail to the issues they were creating.

Step 3: Updating the contributing documentation

When the repository was initially created, the contributing documentation pointed to the general freeCodeCamp contributing guidelines. While that documentation is very thorough, it wasn't specific enough on how people could best contribute to the Developer Quiz site repository in particular.

I decided to completely overhaul the documentation and create a new in depth file just for the Developer Quiz Site. Since I anticipated that we would have a lot of beginners with Git and GitHub, I tried to make it as accessible and beginner friendly as possible.

Step 4: Creating well-defined issues

In order to attract contributors to our repository, I knew that we needed to have some clearly defined issues. If the issues were too vague, then I knew people would have tons of questions or might not be interested in contributing.

I made sure to include all of the necessary guidelines for submission, including code snippets for the proper formatting, links to the Code of Conduct, Contributing docs, and links to the files they needed to change.

Here is an example of one of the issues I created to encourage more JavaScript questions.

Sample issue

developerquiz.org currently has over 600 quiz questions. We are looking to expand on the JavaScript questions and we encourage other developers to add their quiz questions to the site.

Please note: we are only focusing on general JavaScript questions instead of library and framework specific questions.

You can find the complete list of questions below. https://github.com/freeCodeCamp/Developer_Quiz_Site/blob/main/src/data/javascript-quiz.ts

You can add your own questions to the top of that file. Please first check to make sure your question doesn't already exist in the file before creating a PR.

Here is an example format for the questions.

  {
    Question:
      "In JavaScript, what is the name of the method used to remove white space from the beginning and end of a string?",
    Answer: ".trim()",
    Distractor1: ".substring()",
    Distractor2: ".reduce()",
    Distractor3: ".slice()",
    Explanation:
      "The .trim() method removes white space (including space, tab, etc.) from both ends of a string and returns a new string without modifying the original.",
    Link: "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/trim",
  },

For the link field, please make sure to use a freeCodeCamp article, freeCodeCamp YouTube video, or official documentation. If you choose to reference a video, please make sure to include the timestamp for the topic covered.

You can read more about how to create timestamps in this helpful article.

This issue will not be assigned to anyone and will remain open for multiple contributors.

Please do not assign yourself to this issue or close it.

Happy contributing!

For most of our issues, I wanted multiple contributors to be able to participate. So I added a disclaimer at the bottom letting people know that it would remain open and wouldn't be assigned to anyone.

I also made sure to add the good-first-issue, help-wanted, and hacktoberfest labels to help attract more contributors.

Step 5: Adding Saved replies

Saved replies is a feature on GitHub were you can create and save your own messages that you intend to use repeatedly in issues and pull requests.

I decided to create the following replies:

I wanted replies to congratulate both first time and returning contributors because they took the time to make our repository better.

I also wanted to create a reply where I thanked the contributor for their contribution and requested changes to the pull request.

The last reply I created was to let contributors know that their pull request was reviewed but was not going to be accepted. I saw that the main freeCodeCamp learn repository used a similar reply so I wanted to include it in the Developer Quiz Site repository.

Step 6: Opening up GitHub Discussions

A few days before Hacktoberfest started, I wanted to open up another avenue for contributors to ask questions and propose new features. So I decided to open up GitHub discussions.

When I created this post, we had a few people new to the repository feel welcomed to contribute and happy that there was a place to connect with me and other contributors.

Now that everything was in place, the countdown to Hacktoberfest was underway.

Lessons I learned during Hacktoberfest

Right from day 1, I was pretty busy reviewing pull requests and helping new contributors get started in open source. But the whole experience was very educational and rewarding.

Here are a few lessons that I learned during this time.

Lead with patience, empathy, and kindness

We were all beginners once, and sometimes it is scary to learn something new. I made sure to lead with kindness and empathy because I remember what it was like to just start out in open source.

Every time a new question came in, I made sure to reply back and provide as much as assistance as I could to help them resolve the issue. This resulted in a welcoming and safe environment to learn.

We also had times where some contributors wanted to add quiz questions but were nervous because English is not their first language. My job was to assure them that I was here to help and not pass judgement on spelling or grammar mistakes.

I believe that helped in the larger volume of quiz questions we ended up getting.

Don't get worked up over spam

One of the downsides to Hacktoberfest is the increased amount of spam pull requests for open source maintainers. While this is frustrating to deal with, I learned pretty quickly to just close the PR, label it as spam, and move on.

There was no point in arguing with them or getting upset because that is wasted energy. The majority of people did want to meaningfully contribute and that is where I chose to spend my energy.

How to gracefully close PR's that will not be accepted

One of the surprising issues that came up were people wanting to take quiz questions and explanations from other quiz sites and add it to freeCodeCamp's Developer Quiz Site. The first couple of times this happened, I closed the pull request and let them know that this is plagiarism and we can't accept that.

Well, I received a response back from one contributor stating that they didn't realize and they wanted to know if they could try again. I assured them that they were free to create a new PR and I could help them with any spelling or grammar.

This led me to revise my response to let contributors know that they weren't in trouble and were free to contribute again in the future with their own questions.

This helped to maintain a healthy open source environment and most of those cases ended up being prolific contributors after they understood the rules.

Conclusion

I am really glad that I participated as a maintainer in this year's Hacktoberfest. I learned a lot about communication, empathy, patience, and leadership.

I hope my post encourages you to want to get involved with open source either as a maintainer or contributor in the future.

How I Developed My First Adventure Game

Andrea Koutifaris — Wed, 09 Mar 2022 20:05:24 +0000

It's hard to tell exactly when my journey creating Occulto, a point and click adventure game, started. But I have a significant date in mind:

3 May 2018.

Here's one thing that got the ball rolling:

Luigi: Hello Andrea. Sorry to bother you. I would like to learn how to develop an app. Am I crazy?

Me (Andrea): Hmm... I don't have your number... who are you?

Reading those two WhatsApp messages now makes me smile. But there are also two other pieces of interesting information:

First, that was May 2018. Now it is 2022... 3 years and some months later, we have published our very first game DEMO. So yes, it took us 3 years to release a demo.

But we are now producing at a steady pace, and in the first months of 2023 we will release the whole game.

That said, if you are planning to develop a game yourself, it won't necessarily take you 4 years…and I have some advice that hopefully will help!

Second, an app – everyone wants to make an app. Do we really need another app? What about a game instead? What I mean is: an adventure game is like a book, you install it, play it, enjoy and eventually uninstall it. It is not yet another app polluting your phone's memory.

Before I start, let me step back and explain what this article is about.

What We'll Discuss in This Article

This article is about how I (Andrea) and Luigi developed Occulto, our first adventure game.

It will cover some technical aspects of the project, as well as how we managed creating and developing it. I'll discuss both psychological and practical parts of the journey.

I'll also provide a shallow comparison between using web technologies (like WebGL) for development vs Unity 2D.

This article consists of:

A brief story about my passion for Adventure P&C games, and how I ended up developing my own game.
A section about Occulto, the game I am developing
A tech section with a comparison between web technologies and Unity 2D
A section about what I learned through the process, along with some advice if you're creating your own game.

How I got Into Adventure Games

Many years ago, a good friend introduced me to Machinarium. Machinarium is one of the best adventure games I've ever played.

After I finished it, I felt the need to create my own adventure game. This feeling was not immediate, but grew stronger over time. Eventually it led me to find Luigi and be actually able to create my own indie game.

First adventure game attempt

In my first attempt at building a game, I contacted some friends and created a small group of people who were enthusiastic about creating an artistic P&C game.

We managed to create a draft of the first scene (see the illustration above). The idea was to make an apple fall on Newton's head, who is resting under the tree.

I used the Playn Java framework to write in Java and export to Android, iOS and web. At the time I was a Java developer. Playn is still an active project, it may be worth considering if you are looking for a Java 2D game framework.

This first attempt didn't last long. We had a dinner all together, and asked two friends to present us with a draft story of the game. And then I didn't get any feedback from the others and the project vanished into nothing.

Second attempt

In my second attempt I managed to create four scenes and some game-play among them. But the project failed because I wasn't ready to lead the project. You'll read about that soon.

Below you can see an image of one of the scenes of the game. It was intended to be a modern revisiting of Little Red Riding Hood were wolves were not bad :).

Third and Final Adventure Game Attempt: Occulto

Developing Occulto is my 3rd attempt at creating an adventure game – and hopefully this one is successful!

Unity Editor: 1° Village

Intro to the game

It is a beautiful morning, and Eliot, a young mage apprentice, is going to the studio of his magister for a lesson about magical potions. Something is wrong from the first moment: why isn't the magister opening the door?

Inside the studio everything is a mess, and a note tells Eliot to go to the church in the village. What is going on? Where is the magister?

2° Magister studio

Will you help Eliot in his journey to find his magister and regain possession of the powerful forbidden book titled "The never written book" that an evil figure is trying to steal?

The demo consists of four scenes:

3° Monastery

and one secret passage between the monastery and the private studio of a monk.

4° Secret passage

Below you can see the last scene of the demo.

5° Monk private studio

Tech I Used to Build My Adventure Game

We developed Occulto in the beginning using Pixi.JS and HTML. Then, later, I switched to Unity using the 2D features that are now included as default in the editor.

Since this article is quite long, I will not enter in the details of the code. But I will provide a description of the technologies we used and the process of creating the game.

I am planning to write a second article for the technical part.

We are a group of 3 people:

Myself, Andrea, the developer and project/technical manager. I contribute to the story and game/riddle design as well. I am a software engineer.
Luigi, the wonderful artistic designer who designs and draws the scenes. He is also responsible for the game story and game-play. If you like the illustrations above, then you like Luigi's work :). He graduated in Mathematics.
Antonio is the music and sounds designer. He is a software engineer.

Luigi draws the scenes using Photoshop and makes the animations using After Effects. Then he exports everything into images (jpg and png) that I later use to assemble the scenes.

In addition Antonio provides me with the sounds and music for the scenes. We are using mp3 files at the moment, but we are planning to switch to FMOD in the future.

The game uses FHD (1920x1080) images, and runs also on low end mobile devices. If you want to run on a device with 1 GB of RAM, you need to reduce the amount of FHD images. If you load in memory more than 50/60 FHD images, the game may crash on devices with not enough memory.

In normal Unity memory management, the entire scene is loaded on memory, so you have to pay attention to what you add to the scene.

A simple and classic solution to reduce the memory imprint, is to use sprite sheets for the animations. Most of the time an animation will fit in a 2048x2048 sprite. I use Texture Packer to create and import animation sprite sheets in Unity.

In addition I use ImageMagick CLI to trim images with an object inside. My input is a FHD transparent PNG with an object inside placed in the right position. Then I use:

magick mogrify -trim -verbose *.png > trim.txt

to trim the image and get the precise position of the object.

Finally I add the trimmed image to the scene and place it using a script I made that maps the coordinates inside trim.txt file to the x,y values of the Unity scene.

By trimming and using sprite-sheets, I solved all memory problems. Also smaller images means lower time when loading a scene. In cheap mobile devices, loading a scene can require like 5 or 6 seconds (whereas in more powerful devices it takes less than a second).

Regarding fps and performance, Unity is good – so basically you don't have to do anything special. You just need to avoid bad design. And pay attention to time complexity. For example, avoid searching for an element on every tick of the game loop.

As I mentioned earlier, I am planning to write a tech article about how I developed the game using Unity 2D. If you are interested, follow me or follow us on one of our social accounts.

Unity vs WebGL

Even if I used both technologies, I am not an expert (this is my first game). So below I will just list some of the pro and cons of both technologies.

Pros of WebGL

Easy to port everywhere with Capacitor or Electron.
Programmers friendly: PixiJS makes it very easy.
Almost the only working solution if you need a web responsive version.
Continuous integration and delivery to web is very easy, since the output is a bunch of files.
Web development is mature, and you have access to tons of libraries, utilities as well as a web packers, like Webpack.
Collaboration is very easy and mature with Git. There is something about collaboration in Unity, I didn't explore it. I don't know what happens if two people work on the same scene.

Cons of WebGL

Slightly lower performances compared to more native frameworks.
Subject to WebViews bugs (which you cannot solve).
It can be difficult for programmers who do not know web development.
WebViews doesn't seem to be ready to perfectly support WebGL. The game wasn't working well on my Neffos, and who knows on which devices it had issues. Maybe WebViews are not yet ready for gaming, but they are definitely ready for HTML and hybrids app.

Pros of Unity

Graphical editor: it is easier to visualize/update the scene and fine tuning.
Easy and complete: it has almost everything you need.
Good performance: 60 fps even on low end devices at 1920 x 1080 resolution.
Cross platform, but the WebGL version does not work well on mobile phones.
A lot of indie games are made using Unity. If the Unity team introduces a bug, it will be found very soon.

Cons of Unity

Graphical editor: you need a working updated Unity editor in each of the computers you are going to use. With Linux it's not that simple.
Closed licence but it has a free tier if you earned up to $100K in the last 12 months.
At the moment the mobile web version is not officially supported.
Linux Unity editor is alpha (and I managed to make it work after many attempts).
Not a lot of helpful info about it: most of the posts I read to find help about a particular topic were low quality or were videos. That's far away from stack overflow quality. But the documentation is well done.

Keep in mind that this section is not intended to be an exhaustive comparison between Unity 3D and WebGl frameworks. Depending on your target, one technology could be better than the other.

That said, even if I am a web developer, I must admit that Unity is great for developing a 2D games (and I guess 3D games too).

What I learned While Building Occulto

Someone needs to lead the project

This is my first insight: if it is you who propose a project to others (a game, an app or whatever), they will assume you will lead the project.

At the time I was thinking that I was just a programmer, and didn't act like a project leader. It won't work if someone doesn't actively follow every person in the project.

Have the right attitude

It is important to have the right attitude towards people that are participating in the project. You also need to understand if they can be productive.

In this context, "productive" does not have the same meaning it has at work. Productive means "actually able to produce". At work it means how much you produce and how good is your output.

Before I go on, let me tell you a story:

Before embarking on Occulto game development, I decided to help a guy develop the interface for his board game. I did it because I thought the game he invented was a good game that had some brilliant parts to it.

In this case I was the developer, and he was leading the project (being the inventor of a game, doesn't unfortunately imply that you are also good as a project leader).

In the beginning everything was good, and I enjoyed developing the game. In addition I was learning React, which I used as the framework to build the game app. (It is a board game, not a classic one, so React was a good choice, and also it had a lot of pages, not just the game page).

Then things started to become weird: he started asking for deadlines, complaining about delays on the development, and asking for features which I thought weren't really useful in the first version of the game.

In the end it didn't work out and I couldn't work well with him, so I blocked all communication. Remember that I worked on his game for free, and I even solved a nasty bug that caused the back end side of the game to stop working.

So, why this story? To tell you that making a game with a bunch of friends is a very different job than what you do at work. Some advice:

Don't push people too hard: if you are making a game for fun, it must be fun. Motivate people and help them. They are working (as you are) for free on a project they believe in.
Don't act like a boss: even if you direct and follow every step of the game, people should regard you more as a project manager/team leader than a boss.

Work in your spare time

Being able to be "productive" applies also to you. Are you able to work in your spare time on the game? Can you provide a steady output, without long periods of time away from the project?

This is the first obstacle I encountered in my previous attempts. I wasn't able to provide a constant, timely output and people thought the project was falling apart.

In this case, as a programmer, it is important to integrate the output of your other team members (images, animations and sounds) as soon as possible. People will be more engaged if they see their work quickly integrated in the game. Also the sooner you integrate others' work, the sooner you will find and solve problems.

Remove as many obstacles as you can

In order to work in your spare time, you have to reduce or remove all the obstacles. These can be physical (slow computer, too small a screen, ...) or psychological. The psychological ones are the most subtle. I will try to list some of them:

Feeling guilty for not working: this is hard, and I think is one of the main reasons for quitting. You have to enjoy working on your project. So deadlines, pushing others to produce more, threatening (like "If you don't work enough you are out") do NOT work.

It is better to motivate people and help them understand what's blocking them (or you) to produce some output.

Obstacles that delays the moment you can actually work: you may think something like "I'd like to finish that thing I started, I think I can complete it in 10 minutes." Then you think: "But the PC is slow and it will take forever to start... may be tomorrow, now I'll just serf on Instagram".

It is important that when you think you can work a bit on the game, you can actually do it without any delay or obstacle.

Too tired to work on the game: indeed you must not overdo it. It is important to find a balance between how much you work and how much you rest. But it is also important to avoid long periods of not working on the game.

I noticed that small actions can help: for example for me it is enough to start the Unity Editor to increase the chances that I'll actually work on the game.

Share your results with the others: even though non technical people may not fully understand what you are doing (and vice-versa), it is satisfying to explain that you solved a performance problem, or that you reduced the bundle size, for example.

In fact, in agile methodologies, telling what you did and what your are going to do is one of the main points.

Persist. Not everything will be easy. You will have to persist. Even though you are probably making a game because of passion, it is still requires a lot of work and sometimes you have to persevere and overcome problems/blocks. You probably do that all the time at work, you can do it also for your game.

Not every moment is a moment of pleasure. Imagine when I discovered that the demo, almost ready to be published, wasn't working on some mobile devices and I had to rewrite everything in Unity. I really had a bad weekend.

But then I manage to change my attitude, start with Unity, and regain pleasure in working on the game.

Fortunately Luigi, my partner in the game, understood it and accepted that we needed to delay the release date of the game demo. While it took a lot of time to write the demo (2 years, if you count from the first commit), it took me 3 months to rewrite it.

Focus on developing the game

It is extremely important to focus on making the game, and not the framework for the game.

Being a programmer you will probably want to write more code than necessary and use your preferred language. Chose a framework based on your needs (cross platform? 2D or 3D? ...) and try to develop a simple level to understand if you made the right choices.

When you start, you won't necessarily have a clear view of the possible frameworks/technologies available to build a game – and there are a lot. In addition you will be biased towards some languages/features.

About that, I can tell you 2 mistakes I made:

I used PixiJS and HTML technologies at first. As opposite as you may think, I was able to go at 60 fps with FHD (1920x1080) resolution even in medium performance mobile devices.

This is because most of the work is done by WebGL. But at a certain point the game started flickering on my old mobile phone (Neffos X1 Max) when ported to a mobile app using Capacitor (webview). But it was working well on the browser and on the other phones I had. Even on my Motorola Moto G first generation (2013 low end device).

I should have tested earlier on mobile (not just with the browser). Also the game wasn't smooth on the my lower end device Moto G (still it was running near 30 fps).

I decided that I wanted my game to run smoothly even on low end devices, so I switched to Unity 2D. Unity is used by a lot of indie game developers, and C# is quite easy. I didn't try Unreal Engine, because I am too rusty on C++. Now it runs smoothly also on my Moto G (60 FPS).

The second thing that was almost a mistake is that I developed a library to find the shortest path on polygon areas with polygon holes. Here you can find the JS code (I have ported it to C#, but not yet release on GitHub).

I took me 3 attempts to get it working properly, and a lot of time. Fortunately by the time I started developing Occulto, the library was ready and working. Now I can just draw the walkable area and have the main character move inside it, avoiding obstacles (polygon holes).

The fact is that having an algorithm to move things inside a walk-able area is not strictly necessary, and it is better to focus on actually making the game. Other P&C games do not use this feature, they just move characters along predefined paths.

So, before you embark on something that is not strictly necessary for the game, see if you can find something already implemented or if it is really worth it.

Release a one scene version of the game

After you've chosen the right framework, take a scene, and develop the entire game which will consist on one scene plus a menu and every UI component that is cross scene. It is important to learn everything you need and to find problems as soon as possible.

Also, submit the game for internal testing (not public) to the stores you are going to use. Yes, do everything that's necessary from developing to publishing (privately) the game.

When I published the game demo on iOS, one animation wasn't working. It was working on Android, Desktop, and even on iPhone with the developer build. So yes, you need to test everything as soon as possible, even the process of publishing.

I made the mistake to first develop the whole demo (four scenes, plus menu and some other screens) just to find out that WebGL technology was not the right choice for my game.

Final Notes

I hope you enjoyed reading this article and found some interesting advice. Maybe I will write another article when I have published the whole game, sharing other insights.

If you are curious about Occulto game, follow us on:

Twitter: https://twitter.com/SirioArtGames
Instagram: https://www.instagram.com/sirioartgames
Our website: https://www.sirioartgames.com

or try the demo: http://onelink.to/occulto!

How to Recover from Deployment Hell – What I Learned After My Discord Bot Crashed on a 1,000+ User Server

Lynn Zheng — Fri, 04 Jun 2021 20:41:29 +0000

I built a Discord AI Chatbot in my last blog post and then, to challenge myself, proceeded to stress-test it on a Discord server with 1,000+ users.

In the first hour, Deployment Hell struck and I had to take the bot down for maintenance. Another hour passed and I managed to patch up my bot and send it back.

Now my bot is up and running and more resilient than ever. As for me, I survived and even thrived in Deployment Hell 🔥. In this deployment postmortem, I'm going to show you how.

I sent my AI chatbot into the server at 2 pm on June 2nd, and hype started gathering around it. The chat went on for a while and all was nice and smooth.

At 3:20 pm, everything started falling apart: My free-tier API key reached its hourly request limit, and I had no choice but to take down the bot and the server for maintenance.

Never mind the typos in my message 😅 This incident caught me totally unprepared

Despite being struck by Deployment Hell in the first hour on the first day of my project debut, I knew I need to sit down, take a deep breath, and recover from this incident.

What Went Well with Deployment

As a first step, I didn't forget to congratulate myself on what went well despite this mishap. Clearly, people were enthusiastic about chatting with my chatbot, to the extent that we went over rate limit.

Moreover, in the brief hour when I observed people interact with my bot in real time, I discovered several good design choices that I've consciously, unconsciously, or subconsciously made.

Avoid Feature Creep At All Costs During Development

I originally developed my code for a tutorial, so I kept my code as simple and readable as possible, without complicated features that won't serve my bot's main use case: chatting.

That said, I marked down TODOs and stretch goals in my code, hoping to get back to those if necessary. For example:

 # TODO: cache chat history in DB and load
 # TODO: after each user input and bot input,
 # append them to conversation history for the next query
 ...
 # FIXME: better make this try-except block more fine-grained

As I observed users interacting with the bot, I'm actually relieved that I didn't implement the memory cache feature. Several users were talking with the bot at once, each along their different conversation thread. If I were to keep track of the conversation history, I would have to create a unique log for each user, further complicating database operations.

Abide by the Principle of Least Privilege

One thing I learned in my Computer Security class is the Principle of Least Privilege (PoLP) – granting an application the minimum amount of access it needs to do its job.

My chatbot only needs two low-level security permissions: View Channel for reading users' messages, and Send Text Messages for replying to users.

Of course I could have given it more fancy permissions like those shown below in the image, just in case it needs any. But that would have violated PoLP and who knows whether my malfunctioning bot will bring down anything else with it when it fails?

Permission settings for Discord bots

Other Observations from Deploying My Bot

Despite its ephemeral lifespan, my bot offered me an opportunity to conduct user research in the real world. This is a server with 1000+ users, not my cozy dev server where my friends and I hang out and take turns to politely exchange lines with the bot.

Here, I observed several interesting user behaviors:

People tend to ask the bot open-ended questions instead of factual ones. Because I built my bot based off a video game character, when developing the AI model, I was keen on making sure the model learns the canon information about the character, like name, age, and role in the game. I was relieved when I saw that people are much more curious about the bot character's preference for ice cream flavor than their factual place of birth.
People use a lot of emoticons :), emojis 😃 and GIFs as they text. However, these will most likely be treated as tokens in the AI model's tokenizer, which means I should sanitize user inputs.

I was also very fortunate to receive direct feedback from friendly people on the server. One feature request that I got was to make the bot attach its response to a user's message thread, instead of just dumping its response in the channel.

Buzzing with excitement from people's enthusiasm and armed with insights from user research, I was ready to patch up my bot and send it back as soon as possible.

What I Needed to Fix

As a good development habit, I kept my code well-organized and modularized, so switching from the production bot back to my development bot requires no more than copy-pasting the dev bot's API key.

Once I was running on my dev server, I sat down to identify the types of problems I needed to tackle.

Fatal Crashes

The fatal bug that caused me to take down my bot was that I hit an hourly API rate limit. I took the obvious approach of keeping redundancy in my system: Keep an alternative API key, and once the primary one runs out, switch over to the alternative, and then switch back at the turn of the hour.

Workaround aside, I noted that this is a short-term solution. If I need to properly scale up my system, I should make an estimate of the number of requests per hour, as I'll discuss at the end of this section.

New Features for Usability

I decided on several new features that will make my bot more user-friendly. Some highlights are:

As some server people suggested, I re-programmed the bot so that instead of dumping responses to different user messages into the channel, it directly responds to each user message in the message's thread.
I sanitized user inputs by removing Unicode emojis and Discord-specific <:some_hilarious_gif> tags. This will limit tokens that my AI model will receive and help it generate better responses.
I implemented a magic command $ignore [message] that allow users to send a message to the channel without triggering a bot response. This feature comes from my observation that, whenever the bot says something funny or smart (or both!), users will remark on that by sending a text intended for their friends (and not the bot) to the channel. It'd be annoying to still receive a bot response on a remark intended for a friend. Hence, I hope that this magic command will address this user pain point.
I implemented magic commands for the server moderators to interface with my bot (stopping or rebooting) so that they can keep the bot under control without having to access my Repl.it server. This makes both my job and theirs easier.

Future-proof Logging

In my cozy dev server, there is little complexity, whereas on this 1000+ user server where 40% of users are online at any given moment, complexity explodes.

There are multiple channels besides the chat channel dedicated to my bot, multiple user roles and permission levels, multiple users typing at the same time, and so on.

While I certainly cannot prevent all possible failure scenarios, what I could do is to protect the important part of my code with a try-except block and log out all information that might reveal the cause of a failure. Since real-time system bugs are subtle and difficult to reproduce, logging will save me lots of headaches down the road.

except Exception as e:
            print(e, 'Offending channel', message.channel, 
            'Offending message', message.content, 
            'Offending bot response', bot_response, 
            sep='\n', end='\n\n')

Scalability

Estimating under some system constraints is where basic statistics and heuristics come in. Hugging Face's model Inference API imposes two limits on the scalability of my system:

A 10k tokens (characters) per hour rate limit, which is about 300 queries.
A 30k tokens per month quota for free-tier accounts, which is about 900 queries.

Wonder how I get the numbers? Fun fact: 1) 10k characters is between 1430 and 2500 words. We will take 2100 since Discord messages usually use simple, short words. 2) The average length of a text message is 7 words. 2100 / 7 = 300 messages

After processing these numbers, the fact that I hit the per-hour rate limit during the first hour of my bot debut is quite a remarkable feat. People are clearly hyped about my witty chatbot. 🥳

Suppose the hype recedes and life goes on, consider now a hypothetical scenario where 20 users (2% of the 1000+ on the server) regularly chat with my bot, each for 25 lines, in the two hours following dinner. This produces a total of 500 queries in two hours (or 250 per hour), meaning that my bot is safe from the per-hour rate limit of 300.

However, in a month, 500 * 30 = 15,000 queries, 15 times more than my quota of 900. If my bot is indeed this popular, I would need to switch to a higher-tier subscription plan to ensure that it remains available.

From Tutorial Code to Production Code

Compared to my tutorial code which strives to be simple, readable, and educative, my production code is longer, more complicated, but also more robust.

What Makes a Great Side Project

Having emerged from Deployment Hell, like my bot, I'm more resilient than ever and have gained new insights about the principles and challenges in real-world software engineering.

As a final takeaway, I reflect on what makes my Discord AI chatbot this popular. (On June 3rd, a day when it's up 24 hours, it had already busted the monthly 30k quota on both my account and one I borrowed from a friend, totaling 2,000+ messages. 🤓)

I have completed and polished various side projects that received positive feedback, but none of them were as half popular as this one. In retrospect, it's not too hard to see why.

Among projects that I'm most proud of, I built a chess engine and a rhythm game engine for the Ren'Py Visual Novel (VN) game development engine. Both are rated 5-star on itch.io, a popular platform for publishing indie games.

These projects, however, are open-source engines intended for developers to integrate into their VN games more than standalone playables that can entertain players for hours.

In comparison, my Discord AI chatbot manages to capture each of the following elements that distinguishes a great side project from a good one:

Audience: I'm fortunate to have this friendly server with 1000+ users who are open to experimenting with the bot and provide me with helpful feedback.
Accessibility: For people to enjoy my chabot, there is nothing special they need to add to their routine - not even opening up a new web app - they just log into Discord as usual, and voilà, the bot is here to chat!
Interactivity: Without interactive components, even the most visually-astonishing game will fail to retain players' attention. Nothing to worry about for my chatbot though: Like a loyal friend, it always has something to quip about whenever you need a good chat.

If you'd like to learn more about my methodology for working on side projects, check out my previous blog post:

https://www.freecodecamp.org/news/how-i-built-my-one-person-open-source-project/

Also check out my chatbot tutorial!

https://www.freecodecamp.org/news/discord-ai-chatbot/

You can also try this out in JavaScript:

5 Mistakes Beginner Web Developers Make – And How to Fix Them

freeCodeCamp — Mon, 05 Apr 2021 16:48:42 +0000

By Dave Gray

This list is made up of the most common mistakes I've witnessed during nearly a decade of teaching beginning web development students.

My idea for writing this article is not to make fun of beginner mistakes or embarrass anyone who is beginner.

Rather, my goal is to educate beginners and hopefully save them from some of these common mistakes.

We Were All Beginners

If you aren't a beginner, you may think the mistakes listed below are obvious... but remember, obviousness is relative to experience.

Once upon a time, those of us with experience struggled with some of these mistakes, too.

If you are a beginner, I hope this list saves you some time and anxiety in the near future.

Let the countdown begin!

Mistake #5: Adding Spaces in File Names

You may save your HTML file with the name "my cool page.html", but those spaces between words are a mistake.

Web addresses (aka URLs) cannot have spaces.

If you load this file into your browser, you are going to see "my%20cool%20page.html" in the browser address bar. Spaces must be encoded because they are not allowed in URLs.

If you want to see separation between the words in your file names, use an underscore (my_cool_page.html) or a hyphen (my-cool-page.html).

As a beginner, you probably aren't too worried about search engine optimization (SEO), but Google has noted they prefer hyphens in file names over underscores.

Mistake #4: Ignoring cAsE sEnSiTiViTy

If you are using Windows for your development environment, you might not notice a problem when you inconsistently use lowercase and capital letters. This is a mistake.

Let's say you created a CSS folder named "Css" and a file within it named "Main.css". But in your code, you link to it like this:

"stylesheet" href="css/main.css">

While you're working on your project, there is no problem.

But when you load your project to a web server...Boom! No CSS is applied.

Many web servers have some version of Linux or Unix running instead of Windows. You may have heard of the LAMP stack. Linux is the L in LAMP.

These systems are case sensitive.

Therefore, it is best to use lowercase file names and directory names all the time unless there is a specific naming convention that uses a capital letter. At that point, the file names will still always be consistent. And consistency is what will prevent this mistake.

Mistake #3: Not Understanding File Paths

Students that do not understand how to link files within different directories often dump all their files in the root directory in order to access them. This is a mistake that leads to an unorganized file tree.

Not long after you start learning HTML, you start learning how to link to other HTML and CSS files.

This is fairly straightforward when the files are in the same directory. Even in the example above, we just looked inside the CSS directory for the main.css file.

It starts to get more complicated when we need to go up a directory instead of (or before) going down into one.

In the example below, we are setting the background-image for a web page in our main.css file. The main.css file is in the CSS directory. We are linking to an image in the img directory.

body {
     background-image: url("../img/moon.png");
}

Both of these directories (aka folders) are in the root directory. Therefore, we need to go up and out of the CSS directory and then down into the img directory.

We go up one directory with two dots: ".."

From there, we go down into the img directory to link to the moon.png file.

If we needed to go up two directories, the file path would start like this: "../../"

Remember, one dot indicates the directory you are in. Two dots indicates the directory above where you currently are.

Mistake #2: Not Naming Your Default Page Index

Naming your default page something other than "index" is a mistake.

Web servers look for an index file.

When you're working with HTML, you should have an index.html file.

This file will load by default without showing the file name at the end of the URL.

That's why you can go to your favorite dot com or other web address and not see "/index.html" after their ".com". The index file loads by default.

Granted, your favorite website may use more than just HTML, but this concept carries over to other technologies like PHP (index.php), React (index.js), and more.

As you continue to learn, you will find some developers choose other file names when utilizing other technologies, but as a beginner, stick with index.

Mistake #1: Not Taking A Break!

I receive emails when students are frustrated.

They have poured over their project for hours and cannot find the error.

Often, the problem is a misspelled tag or variable, a missing semi-colon, or other small syntax error.

This happens to us all.

After staring at code for an extended time period, our vision blurs, our brains fizzle, and what would have been easy to see with fresh eyes becomes impossible.

Don't feel bad. Don't blame yourself. Just get up!

Take a walk. Get some coffee. Take a nap. Whatever snaps you out of the haziness and gives you fresh eyes and a clear head again.

Really, this mistake isn't just for beginners. It can happen to anyone.

I must remind myself to take breaks, too.

Come back to the code when you are refreshed and that error you couldn't find will often be obvious!

Conclusion

As you gain experience, you will quickly move past these common mistakes.

What was once difficult to understand will become clear.

If these common mistakes were obvious to you, congrats! You've already got some experience.

If you're just starting out, I hope this review of common beginner mistakes saves you both time and frustration in the near future.

I'll leave you with a video from my YouTube Channel that counts down the Top 10 Biggest Beginner Mistakes. Watch to see examples of the 5 mistakes I discussed in this article plus 5 additional common beginner mistakes:

How I Escaped Tutorial Purgatory – and How You Can, Too

freeCodeCamp — Mon, 23 Nov 2020 17:50:41 +0000

By Daniel Chae

Tutorial purgatory. We've all been there. The mindless scrolling, pausing, and playing. All the copying, and pasting of the coding snippets. It's a lukewarm place to be.

You're "learning" because you're making your way through structured content. But when you leave the tutorial, you can't code any of what you "learned".

The great thing is that you don't have to stay stuck in tutorial purgatory. I'm going to share with you my own experience about how I broke out of tutorial purgatory and how you can too.

Whatever method you decide to use, I'll share the key metrics for breaking out of the tutorial rut.

_Photo by [Unsplash](https://unsplash.com/@dchuck?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Daniel Chekalov / Painful Realizations About My Learning Approach

When I first started learning how to code I looked forward to learning anything and everything.

I'd Google "easy programming projects" and browse the first few search results. I kept my eyes peeled for tutorials because I thought I could avoid failure with the tutorial's help. I also believed that the more tutorials I completed, the more I would learn.

I couldn't have been more incorrect in my learning approach.

The unfortunate aspect was that I wasn't retaining the knowledge of what I was coding. After several months of "completing" tutorials, I soon came to grips with my lack of progress. I couldn't understand the code I was writing.

An example of this was when I completed a Flask tutorial. I thought I knew and understand Python from completing a tutorial. I decided to take w3 school's Python quiz and was confident I would pass. Unfortunately, I failed.

After I discovered I wasn't learning what I thought I was, I felt pretty hopeless. I thought tutorials were the key to learning. I thought about trying projects without tutorial help, but I was too scared to fail. I was burning with desire to become a great programmer, but I was out of ideas for how to do that.

How I Broke Free from Tutorial Purgatory

_Photo by [Unsplash](https://unsplash.com/@pabloheimplatz?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Pablo Heimplatz /

I sat and pondered answers to those two questions. I started researching different types of programming and various career paths. It was illuminating.

I found articles and forums on data science and analysis. I found helpful graphics that explained the difference between the front-end and back-end. I discovered how the front-end and back-end interact. I also found videos that explained what APIs were and how to view, receive, and write data from an API.

I would encourage you to ask the same questions:

What is it that you want to work on?

What type of programming is out there?

As you reflect on what it is you want to work on and explore, you'll begin to narrow down your learning path.

You'll feel less inclined to learn everything there is to know and more of what you are most interested in. You'll also feel less overwhelmed as you focus in on what type of programming interests you the most.

Meetups Changed My Life

_Photo by [Unsplash](https://unsplash.com/@windows?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Windows /

This is What Freedom Feels Like

_Photo by [Unsplash](https://unsplash.com/@micahtindell?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Micah Tindell / Meetup.com.

I would also encourage you to check out the r/learnprogramming subreddit. There are some snarky individuals on Reddit who may give you a hard time for asking questions. But there are also plenty of people who are more than willing to guide, inspire, and help you. If you allow them to, they'll help you become a better programmer.

Your Keys to Success When Learning to Code

_Photo by [Unsplash](https://unsplash.com/@mlightbody?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Malcolm Lightbody /

Tutorial purgatory is a miserable place to be. You don't know if you're heading in the right direction and learning to program can feel hopeless.

But take heart, you don't have to stay stuck in tutorial purgatory. Keep asking questions! Distill your vision so that you're not overwhelmed with having to learn everything. You're heading in the right direction if you're producing results and feeling confident. Time to break out of tutorial purgatory and you'll thank yourself later.

Things I Wish I Knew Before Working with Electron.js

freeCodeCamp — Thu, 28 May 2020 19:11:55 +0000

By Alain Perkaz

In this article, I'll share how you can avoid some of the mistakes I made when learning about Electron.js ?‍♂️. I hope it helps!

Note: This wont be a coding tutorial, but rather a discussion about my personal takeaways.

A couple of months back, I decided to focus more on building my side product, taggr. I was inspired to build it because of how many photos I have on my computer.

For those of us that keep a backup of their pictures, those collections often get so big and complex that they become a full-time job to manage. A mix of folders and sub-folders may contain instant messaging picture backups, hi-resolution pictures from your trip to Bali, your uncle's wedding, or last-year's bachelor party.

Always keeping such collections tidy is tedious (believe me, I have tried for years). It's also hard to discover the shots that you love the most, hidden deep within the folders.

So taggr is a desktop app that solves that problem. It lets users rediscover their memories while keeping their privacy.

I am building taggr as a cross-platform desktop application. Here I'll share some of the things I've learned about cross-platform app development with Electron.js that I wish I knew from the beginning. Let's get started!

Background

Before presenting my takeaways on this ongoing journey with Electron, I would like to give a little more background about myself and the requirements of taggr.

Every developer comes from a different background, and so do the requirements of the applications they develop.

Contextualizing the choices I made for this project may help future developers select the right tools based on their needs and expertise (rather than what is hyped out there – GitHub ?, I am looking at you).

JavaScript development in a nutshell. Source: [giphy](https://giphy.com/gifs/train-hype-FY2ew2Zii9VOE" rel="noopener).

As mentioned earlier, from the beginning I envisioned taggr as a cross-platform application. The app would perform all the required pre-processing and machine-learning computations client-side due to the focus on privacy.

As a one-person show, I wanted to be able to write my app once and ship it to different systems without losing my sanity.

From my side, I am a front end engineer in love with the web and JavaScript. I previously worked with Java and C#, but I enjoy the flexibility that the web provides and its vibrant ecosystem.

Having experienced first hand the pain of using tools like Eclipse RCP to build client-side apps before, I knew I didn’t want to work with that tech again.

In short, my stack requirements for taggr boiled down to something like the following:

It should provide cross-platform support, ideally at the framework level. ?
It should allow me to write the code once, and tweak for each platform if needed. ?️
It should enable access to machine-learning capabilities, regardless of the host environment, without specific runtimes to be installed. It should be painless to set up. ?
If feasible, it should use web technologies. It would be great to leverage my existing knowledge. ?

As you can see, the requirements do not read as: I should use React with Redux, observables, and WebSockets. Those are lower-level implementation details, and they should be decided upon when and if the need arises.

Pick the right tool for the job rather than picking a stack from the beginning, disregarding the problems at hand.

So, after furious googling, I decided to give Electron a try. I hadn’t used that framework before, but I knew that many companies were using it successfully in products such as Atom, VS Code, Discord, Signal, Slack and more.

Open-source and with out-of-the-box compatibility with both the the JS and Node ecosystems (Electron is build using Chromium and Node), Electron.js was an attractive tool for the work at hand.

I won't go too much into detail regarding the rest of the stack, as I repeatedly changed core parts (persistence and view layers) when needed, and it falls out of the scope of this article.

However, I would like to mention Tensorflow.js, which enables running training and deploying ML models directly in the browser (with WebGL) and Node (with C bindings), without installing specific runtimes for ML in the host.

So back to Electron – thinking it was perfect, the fun began. ??

Enough talk about the background. Let’s dive into the takeaways.

1. Start small (and slow) ?

This is not a new concept, but it's worth bringing up periodically. Just because there are a ton of awesome starter projects with Electron available, it doesn’t mean that you should pick one right away.

Wait. What?

Slow is smooth, and smooth is fast. — Navy saying

With convenience comes complexity

While those starters include many useful integrations (Webpack, Babel, Vue, React, Angular, Express, Jest, Redux), they also have their issues.

As an Electron newbie, I decided to go for a lean template that included the basics for ‘creating, publishing, and installing Electron apps’ without the extra bells and whistles. Not even Webpack in the beginning.

I recommend starting with something similar to electron-forge to get up and running quickly, You can set up your dependency graph and structure on top to learn the ropes of Electron.

When the issues come (and they will), you will be better off if you build your custom starter project rather than picking one with +30 npm scripts and +180 dependencies to begin with.

That said, once you feel comfortable with Electron’s basis, feel free to step up the game with Webpack/React/Redux/TheNextHotFramework. I did it incrementally and when needed. Don’t add a realtime database to your todo app just because you read a cool article about it somewhere.

2. Mindfully structure your app ?‍♂️

This one took a little longer to get right than I am happy to admit. ?

In the beginning, it may be tempting to mix up the UI and Backend code (file access, extended CPU operations), but things get complex quite fast. As my application grew in features, size, and complexity, maintaining one tangled UI+Backend codebase became more complicated and error-prone. Also, the coupling made it hard to test each part in isolation.

When building a desktop app that does more than an embedded webpage (DB access, file access, intensive CPU tasks…), I recommend slicing the app into modules and reducing the coupling. Unit testing becomes a breeze, and there is a clear path towards integration testing between the modules. For taggr, I loosely followed the structure proposed here.

On top of that, there is performance. The requirements and user expectations on this matter may vary wildly depending on the application that you are building. But blocking the main or render threads with expensive calls is never a good idea.

3. Design with the threading model in mind ?

I won’t go too much into detail here – I'm just mainly doubling down on what is awesomely explained in the official docs.

In the specific case of taggr, there are many long-running CPU, GPU, and IO intensive operations. When executing those operations in Electron’s main or renderer thread, the FPS count dips from 60, making the UI feel sluggish.

Electron offers several alternatives to offload those operations from the main and renderer threads, such as WebWorkers, Node Worker Threads, or BrowserWindow instances. Each has its advantages and caveats, and the use case you face will determine which one is the best fit.

Regardless of which alternative you choose for offloading the operations out of the main and renderer threads (when needed), consider how the communication interface will be. It took me a while to come up with a interface I was satisfied with, as it heavily impacts how your application is structured and functions. I found helpfull to experiment with different approaches before picking one.

For example, if you think WebWorkers message passing interface may not be the easiest to debug around, give comlink a try.

Sponge Bob knows best. Source: [giphy](https://giphy.com/embed/jV4wbvtJxdjnMriYmY" rel="noopener)

4. Test ❌, test ❌, and test ✔️

Old news, right? I wanted to add this as the last point, due to a couple of anecdotal ‘issues’ I recently faced. Strongly linked to the first and second points, building your custom starter project and making mistakes early on will save you precious debugging time further in the development.

If you followed my recommendations for splitting the app’s UI and Backend into modules with a clean interface between the two, setting up automated Unit and Integration tests should be easy. As the application matures, you may want to add support for e2e testing too.

GPS location extraction ?️

Two days ago, while implementing the GPS location extraction feature for taggr, once the unit tests were green and the feature worked in development (with Webpack), I decided to try it in the production environment.

While the feature worked well in development, it failed miserably in production. The EXIF information from the pictures was read as binary and processed by a third-party library. While the binary information was correctly loaded in both environments (checked with diff), the third party library failed when parsing such data in the production build. Excuse me, ??

Solution: I found out that the encoding settings in the development and production environments set by Webpack were not the same. This caused the binary data to be parsed as UTF-8 in development but not in production. The issue was fixed by setting up the proper encoding headers in the HTML files loaded by Electron.

Funky pictures ?

When manipulating and working with images, you may think that if a JPEG ‘just-works’ on your computer, it is a valid JPEG. Wrong.

While working with the Node image processing library sharp, resizing some JPEG images crashed the app. After looking closely, the cause was incorrect JPEG images generated by Samsung firmware. ?‍♂️

Solution: setting up improved error boundaries in the app (ex. try-catch blocks), tweak the JPEG parsing module, and suspect of everything. ?️

Summary

The Node and JavaScripts ecosystems are blooming, with many powerful tools being created and shared every day.

The amount of options makes it hard to choose a clear path to start building your new awesome Electron app. Regardless of your frameworks of choice, I would recommend focusing on the following:

Start small and add complexity incrementally.
Mindfully structure your app, keeping backend, and UI concerns modularized.
Design with the threading model in mind, even when building small apps.
Test and test again, to catch most of the errors early on and save headaches.

Thanks for sticking around until the end! ?

taggr is a cross-platform desktop application that enables users to rediscover their digital memories while keeping their privacy. Open-alpha is coming soon to Linux, Windows, and Mac OS. So keep an eye on Twitter and Instagram, where I post development updates, upcoming features, and news.

What I've Learned in My First Year as a Software Engineer

freeCodeCamp — Thu, 19 Sep 2019 15:00:00 +0000

By Lekha Surasani

I just completed my first full year as a software engineer and it absolutely flew by.

Along the way, I learned a lot and I wanted to take some time to reflect on it and share what I've learned.

Mentorship

For a while, I downplayed the importance of mentorship in career growth. It takes a long time to find a good mentor, and quite frankly, I still haven't taken the time to find one.

Instead, I opted to learn as much as I could from senior engineers on my team. I was luckily comfortable enough with them to even ask career-related questions. Some examples of questions or advice I frequently asked for included:

What are some good resources to learn x?
What are some things you look for in code reviews?
What are some things you wished you knew at the beginning of your career?
What was your salary at x years of experience?

Be your own advocate

In my experience, when you start a new job as a junior developer, your coworkers will underestimate you at every turn. I've gotten work assigned that's unfortunately simple, uninteresting, and too easy.

This was really frustrating because I felt myself growing bored at my job because I was doing things that weren't appropriately challenging. And, I'm guilty of letting this go on for too long (2-2.5 months).

It took a lot of internal pep talks, but I finally spoke up about it during a sprint planning meeting.

In hindsight, I didn't say much – I said I wanted more complex things to do. Then, I continued actively trying to take on tasks that I thought would be more appropriate, rather than trusting my coworkers to know what was best for me.

Learn how to ask for help

I will admit, I'm still working on this one. I used to ask for help pretty readily early on, but as time passed, I got increasingly self-conscious about it. I was worried that I wasn't showing a better understanding of the code base over time. I was worried that my coworkers might think that I wasn't learning fast enough or that I just wasn't good at coding.

Getting over that insecurity and general imposter syndrome has been difficult. I can't say I've truly gotten over it, but I've taken some steps to mitigate the feeling, including:

Writing down the question that I had or what I was having difficulty with. This showed me that over time, my questions were generally getting "smarter" and that I was asking about more complex things.
Teaching others what I found. If another engineer had a question that I could answer, I'd offer up my help even if I wasn't certain I was right. As you can imagine, my responses were littered with "I think", "Someone please correct me if I'm wrong", "maybe", "possibly", and "it could be"'s. Despite my fears about doing this, I tried my best to remember that it would be better for me in the long run. I could share what I had learned with others while getting feedback of my understanding from other engineers.
Talking about what I was feeling. Another junior engineer started at the same time I did, so I found that talking to her about my insecurities was really helpful. She was able to share how she was struggling as well, and it made me feel like I wasn't alone, or falling behind.

Another reason I stopped asking for help was that often times, I got too much help. I would go to a senior engineer with what I thought was one simple question, and I would leave with all of the interesting parts of the task completed for me. I've been working on trying to ask more specific questions, and speaking up when I think I've got what I wanted, so the help I receive stops right there.

You really don't have to be an expert – really.

"You don't have to be an expert". I heard this so many times while I was considering speaking at local meetups and conferences, and when I started trying to write technical articles. I didn't believe it for a long time – surely that's just what people are saying while they're already really good at said thing.

But one week, work had me diving into a very specific problem – we were upgrading react-router from v3 to v4. This upgrade required a lot of research as some key libraries were deprecated, and there were a ton of breaking changes.

I ended up learning so much about this one specific library. Over the course of many days, I had read so much documentation, github issues, and guides. I took all of the information I found and consolidated it since I hadn't found any one guide that would help explain what was going on in depth.

So, I wrote one myself. It didn't get too much attention, of course. More importantly, I was relieved no one came after me with pitchforks.

Then, I thought about how many "intro to x" articles I read when I first started to learn a new language or framework. They were pretty basic articles, requiring a bit of background knowledge, but overall nothing too technically-controversial.

That's when I decided that React Hooks was going to be the topic of my next article. I wasn't an expert on React Hooks by any measure. It had literally just come out and I'd only used it for some personal projects, but I'd written an article about it. So, really, you don't need to be an expert.

Take advantage of one-on-ones with your manager

And if you don't do them currently, ask for them. I have mine once every two weeks. For me, I found these one-on-ones were a great opportunity for me to reflect on my work, ask questions about things I was confused about, and give general feedback about things that were working well and things that weren't.

Some specific questions and feedback included:

How does this piece of the product work?
Do you see a consistent theme of things in my PRs that could be improved?
I'm enjoyed working on x, but I want to continue exploring other things, so do you think I could start getting work related to y?

Because of these dialogues, I was able to get different kinds of tasks that I was more interested in, learn a lot more about the code base, and generally make parts of my job easier.

Each manager is different, though – so you may not be comfortable with asking the kinds of questions I've suggested, but at the very least, hopefully you can get some useful feedback on your work.

Document

When you're early in your career especially, it's important to document what you're doing on a daily basis. It helps you see your growth, understand your work better, and overall, will help you reflect and understand what you've been working on. As a bonus, you'll be able to come up with points on your resume way easier!

I'm admittedly pretty bad at this. I jot things down in a notebook every week or so, and when I do, I only really take notes of the more complicated parts of our product. Ideally, you'd want to jot down what you accomplished that day and take notes on the code base and general "business logic" more often.

I don't think this is something that's talked/written about enough, but one of the people I follow on twitter, Cecelia Martinez, recently asked her Twitter followers about tools they use to document things, so definitely check it out if that's something you're interested in.

Engage in the community at large

The tech industry is problematic in many ways, but as a woman in tech, it helped me to follow others who had experienced similar things to me. Tracy Lee (CEO of This Dot Labs) has an excellent list of women in tech to follow.

I also joined my city's women who code chapter and I go to a few local meetups. As someone who gets very nervous meeting new people, I found it was a great way to network in a welcoming and friendly environment.

Find non-coding hobbies

When I first started working, I felt a lot of pressure to keep up with the newest tech and to continue learning new things. But, I burnt out quickly because that was all I did.

I took a few steps back and decided to explore doing things I enjoy that weren't coding-related. I starting learning how to play the guitar and how to speak Hindi, I joined a book club, and I started going to the gym more.

All in all, I've learned a lot, and hopefully you've taken away some lessons from my experiences. I'm excited for what this next year holds for me!

How I Built and Shipped My First MVP

freeCodeCamp — Mon, 15 Jul 2019 13:15:00 +0000

By JavaScript Joe

On June 29th, I shared the MVP of mentored.dev on Twitter–my first "real" project that was bigger than anything I'd built before and something I was excited for other people to use.

After sharing this, I received some bits of positive feedback, including a shout-out in the npm weekly newsletter.

I thought I'd share the story behind the whole process.

Origin of the Idea

I can't remember when I first had the idea but a while back when I was introduced to TwilioQuest, I thought to myself,

Wouldn't it be cool to build a "gamified" learning platform that taught you how to code?

Like many other people, I have these ideas at random times throughout my life. I keep a list of these ideas in a Trello board called "IDEAS". Looking here, I can see I notated this on January 21st, 2019.

Trello board with original idea from Jan. 21st

I knew a few things:

I wanted it to be interactive
I wanted it to feel like a game
I wanted it to have quick exercises

Where to Start?

Around that same time, I was wrapping up a freelance project (porting a Jekyll theme to a Gatsby site) so I didn't feel like I was ready to start it just yet. Then, I had a conversation with @signalnerve on Twitter that sparked my motivation:

Screenshot of Twitter conversation that motivated me to start.

Build a small app–a real MVP–validate your idea and then decide if you should keep building.

So I thought, "What the heck, why not start it?"

March 2019

I used a Gatsby/TypeScript starter to kickstart the first and pushed my first commit. Originally, I named the repo "Life of Code" because that's what came to mind but later I renamed it after buying the mentored.dev domain.

Initial Wireframes

After creating the repo, I sketched up some elementary wireframes in Figma

Initial Wireframes in Figma

Once I had all this, I felt over the initial "where-do-I-begin-paralysis" and knew I needed to keep the momentum going.

Taking Input

One of the first things I tried was asking for user input and showing that in a message. This would be useful for the dialog between the narrator and the user.

Basic Dialog Working

Even though it didn't look pretty, the logic for the dialog was working! This felt like a good milestone because most of the hard stuff was done.

Narrator Character Talking

I struggled a lot figuring out the best way to get the narrator talking but after finding [react-keyframes](https://github.com/zeit/react-keyframes), I was able to figure out a solution. This was huge because previously I hadn't done much with animation.

Getting Feedback on Dialog

As stated earlier, I think it's important to get input from others. I don't know if Twitter is the best place to do it but fortunately for me, the people who responded to my request for feedback were kind.

Migrating to TypeScript

I used a Gatsby-TypeScript starter for this project because I had been meaning to learn TS. However, up until this point, I wasn't actually using TS. The files just had .ts or .tsx endings.

Before the 30th, I had mentioned wanting to learn TS and @TejasKumar_ offered to teach me by migrating the mentored.dev codebase over to TS on a Google Hangouts livestream. This was one of the coolest moments of this project. And I learned a ton.

April 2019

Next up after finishing the dialog part of the project, I decided to focus on the Dashboard - or the page after you logged in. I created a simple "Profile Card" that will eventually show your experience, any code-cash you have, etc.

Designing the Dashboard

In hindsight, I may have gotten ahead of myself here because I designed way more than I could implement in the MVP but at least it gave me an idea for the future. I first added it as hard-coded components but later commented out to maintain a healthy UX.

Designing the Campus Map

This took way longer than I thought. I wanted it to feel like a university campus but drew heavily from Pallet Town in Pokemon. The completed version has more but at least I had something I could add to the Dashboard. I designed all of this in Figma and exported it as SVG. Working with SVGs in React has proven to be a delightful experience.

Adding Gameplay Music

I never realized how hard it is to create or find music for a game. I ended up finding this amazing sound artist named Eric Matyas who makes music and sounds royalty-free. I wanted the audio to start automatically (because that's how most games do it) but unfortunately that is not accessible so it does not auto-play.

However, if you turn it on at the start menu or when you're playing the game, it adds a nice touch.

Changing Maps

This has to be my favorite feature I added–being able to change the map. At first, I had no idea how I was going to do this, then I thought, "why not just swap the map with another map?"

So that's exactly what I did and it worked!

I extracted the parts of the map that were clickable (like the buildings) and made it so they open up different maps. I don't know how well my solution will scale but hey, it's working right now and that's what matters.

Courses Page

One of the other challenges I faced was figuring out where and how to show the courses (i.e. the dialog with the narrator).

Same thing–I struggled with this for a bit then decided, "Let's show it in an Overlay component!"

That ended up working out well. Again, I don't know if that will scale well but it works for now.

May 2019

In May, I took a little bit of a break. I was getting married so I wanted to focus on prepping for that rather than my game. I still had ideas for things here and there but I didn't put in nearly as much time as March or April.

Even though it's difficult for me to take breaks and step away, I think it's healthy to go outside, change what you're doing, mediate, etc. As my mother always says,

Everything in moderation.

June 2019

Looking at the Dashboard I created, there was still so much left to do.

I felt overwhelmed.

"How am I going to finish all this?"

A Realization at the Phoenix ReactJS Meetup

I hadn't been to the Phoenix ReactJS Meetup in a while. My two coworkers and I decided to go hear the lightning talks.

Before the talks, we were crowded around a table, chatting about our side projects. I said I wanted to finish the MVP for mentored.dev by the end of the year.

"How much more do you have to finish?"

"A decent amount. Everything on the Dashboard page is hard-coded at the moment."

"Drop all that. Finish the core features and ship it."

Those were the wise words from my coworkers. That's when I realized they were right. I decided to cut scope and implement two last features–the streak tracker and the lesson progress.

Screenshot of the streak tracker

Screenshot of lesson progress

The streak tracker logic was buggy when I first implemented it and didn't work at all. I wasn't sure if I should only increment the streak after 24-48 hours, or just do it by the day, or what. It seemed a lot more complicated than it should have been.

I still don't know if I'm happy with the implementation. But again, it's out the door and the basic functionality works.

The lesson progress (completed - 1/3) is also rudimentary at best. Again, my focus was to get it out the door. I'll style it in the future.

Ship It

June 29th. The big day.

As I say in the tweet thread,

...It's nowhere near complete but I think this is a good stopping point to share the MVP.

A while back, I read Lean Startup by Eric Ries. One thing that always stuck with me was something he said along the lines of, "You should be embarrassed putting your product out there. That's when you know it's an MVP."

And that's how I felt! So much left to do. It's hard to even consider it a "game"–most real gamers probably wouldn't.

But that's the point–it helped lift a burden off my shoulders and step back to hear what people think.

Most people I've talked to think it's a good start and a neat concept. They're excited to see where it goes.

What I Think Worked

Reflecting on what helped me launch this MVP, a few things come to mind.

Accountability - Friends & Twitter Community

As we all know, it's very easy to silo yourself and work alone. This might work for some people and that's fine. But in my case, I think sharing this project with my coworkers held me more accountable than if I hadn't told anyone. Each week on Monday mornings, one of them would ask, "Hey Joe. Did you work on your game?"

Their interest and support meant a lot to me. They wanted to see it succeed as much as I did. That kept me going.

The other part that kept me accountable was sharing it with people on Twitter. Sometimes people would comment and other times they wouldn't. Either way, people were following along. A few would DM me asking how it was coming along.

By sharing it in public, I felt a bit of pressure (in a good way) to finish it.

Using GitHub Projects, Issues, and Milestones

I treated this project like we treat client/company applications at work. I didn't use sprints per se but I did keep a list of tasks in a GitHub Project board and then select a few and create a milestone. This made the work feel more achievable and less overwhelming.

I set up a staging environment at https://staging.mentored.dev (thanks to Netlify, this was straightforward). Then, each issue I finished, I submitted a PR to merge into staging. I reviewed and merged myself (yes, a bit silly, but good practice).

Once a milestone was complete, I merged staging into master and created a new release. This process set me up for success. I kept milestones small (something I could finish in 1-3 weeks).

Having some type of project management in place for your side project I believe will help you reach the finish line sooner.

Cutting Scope

I wouldn't have finished this MVP if I hadn't cut a lot of features. For instance, I really wanted to create a repository called "mentored-dev" after the user logged in and store the lesson progress there. But that was going to take more time than I anticipated so I cut it.

Instead, I store the progress in localstorage. Yes, it's short-term but again, I had to cut scope to ship. If I hadn't, I wouldn't have finished this phase of the project.

Closing Thoughts

Overall, I feel thankful for all the support. I'm proud of the small project I built and the feedback I have received, so thank you. As for the next steps, I've already created the next milestone. The main thing is to finish all the lessons for the basics of the command line and then share that to see what people think.

As far as actual features–I wouldn't promise anything but I'd love to add experience points (XP) which you accumulate based on your score in the lessons or how many times you take each lesson, how often you login, etc.

It would also be nice to give XP for doing things outside the game (i.e. writing a blog post, tweeting something you learned, contributing to open source, helping someone, etc). We'll see what happens though.

Thank you for listening to the journey.

###

If you enjoyed this article or found it interesting, please share it with others or let me know on Twitter.

To stay up to date on mentored.dev or other things I'm working on, I have a newsletter you can sign up for here.

Happy coding!

How I reverse-engineered the Hemingway Editor - a popular writing app - and built my own from a beach in Thailand

freeCodeCamp — Wed, 03 Jul 2019 04:30:00 +0000

By Sam Williams

I’ve been using the Hemingway App to try to improve my posts. At the same time I’ve been trying to find ideas for small projects. I came up with the idea of integrating a Hemingway style editor into a markdown editor. So I needed to find out how Hemingway worked!

A screenshot of the Hemingway Editor

Getting the Logic

I had no idea how the app worked when I first started. It could have sent the text to a server to calculate the complexity of the writing, but I expected it to be calculated client side.

Opening developer tools in Chrome ( Control + Shift + I or F12 on Windows/Linux, Command + Option + I on Mac) and navigating to Sources provided the answers. There, I found the file I was looking for: hemingway3-web.js.

Minified file on the top, Formatted file on the bottom. What a difference it makes!

This code is in a minified form, which is a pain to read and understand. To solve this, I copied the file into VS Code and formatted the document (Control+ Shift + I for VS Code). This changes a 3-line file into a 4859-line file with everything formatted nicely.

Exploring the Code

I started to look through the file for anything that I could make sense of. The start of the file contained immediately invoked function expressions. I had little idea of what was happening.

!function(e) {
  function t(r) {
      if (n[r])
          return n[r].exports;
      var o = n[r] = {
          exports: {},
          id: r,
          loaded: !1
      };
...

This continued for about 200 lines before I decided that I was probably reading the code to make the page run (React?). I started skimming through the rest of the code until I found something I could understand. (I missed quite a lot that I would later find through finding function calls and looking at the function definition).

The first bit of code I understood was all the way at line 3496!

getTokens: function(e) {
  var t = this.getAdverbs(e), 
    n = this.getQualifiers(e),
    r = this.getPassiveVoices(e), 
    o = this.getComplexWords(e);
  return [].concat(t, n, r, o).sort(function(e, t) {
    return e.startIndex - t.startIndex
  })
}

And amazingly, all these functions were defined right below. Now I knew how the app defined adverbs, qualifiers, passive voice, and complex words. Some of them are very simple. The app checks each word against lists of qualifiers, complex words, and passive voice phrases. this.getAdverbs filters words based on whether they end in ‘ly’ and then checks whether it’s in the list of non-adverb words ending in ‘ly’.

The next bit of useful code was the implementation of highlighting words or sentences. In this code there is a line:

e.highlight.hardSentences += h

‘hardSentences’ was something I could understand, something with meaning. I then searched the file for hardSentences and got 13 matches. This lead to a line that calculated the readability stats:

n.stats.readability === i.default.readability.hard && (e.hardSentences += 1),
n.stats.readability === i.default.readability.veryHard && (e.veryHardSentences += 1)

Now I knew that there was a readability parameter in both stats and i.default. Searching the file, I got 40 matches. One of those matches was a getReadabilityStyle function, where they grade your writing.

There are three levels: normal, hard and very hard.

t = e.words;
n = e.readingLevel;
return t < 14
  ? i.default.readability.normal
  : n >= 10 && n < 14
    ? i.default.readability.hard
    : n >= 14 ? i.default.readability.veryHard 
      : i.default.readability.normal;

“Normal” is less than 14 words, “hard” is 10–14 words, and “very hard” is more than 14 words.

Now to find how to calculate the reading level.

I spent a while here trying to find any notion of how to calculate the reading level. I found it 4 lines above the getReadabilityStyle function.

e = letters in paragraph;
t = words in paragraph;
n = sentences in paragraph;

getReadingLevel: function(e, t, n) {
  if (0 === t 
 0 === n) return 0;
  var r = Math.round(4.71 * (e / t) + 0.5 * (t / n) - 21.43);
  return r <= 0 ? 0 : r;
}

That means your score is 4.71 average word length + 0.5 average sentence length -21.43. That’s it. That is how Hemingway grades each of your sentences.

Other Interesting Things I Found

The highlight commentary (information about your writing on the right hand side) is a big switch statement. Ternary statements are used to change the response based on how well you’ve written.
The grading goes up to 16 before it’s classed as “Post-Graduate” level.

What I’m going to do with this

I am planning to make a basic website and apply what I’ve learned from deconstructing the Hemingway app. Nothing fancy, more as an exercise for implementing some logic. I’ve built a Markdown previewer before, so I might also try to create a writing application with the highlighting and scoring system.

Creating My Own Hemingway App

Having figured out how the Hemingway app works, I then decided to implement what I had learnt to make a much simplified version.

I wanted to make sure that I was keeping it basic, focusing on the logic more that the styling. I chose to go with a simple text box entry box.

Challenges

How to assure performance. Rescanning the whole document on every key press could be very computationally expensive. This could result in UX blocking which is obviously not what we want.
How to split up the text into paragraphs, sentences and words for highlighting.

Possible Solutions

Only rescan the paragraphs that change. Do this by counting the number of paragraphs and comparing that to the document before the change. Use this to find the paragraph that has changed or the new paragraph and only scan that one.
Have a button to scan the document. This massively reduces the calls of the scanning function.
Use what I learnt from Hemingway — every paragraph is a
and any sentences or words that need highlighting are wrapped in an internal with the necessary class.

Building the App

Recently I’ve read a lot of articles about building a Minimum Viable Product (MVP) so I decided that I would run this little project the same. This meant keeping everything simple. I decided to go with an input box, a button to scan and an output area.

This was all very easy to set up in my index.html file.

<link rel=”stylesheet” href=”index.css”>
<title>Fake Hemingwaytitle>
<div>
    <h1>Fake Hemingwayh1>
    <textarea name=”” id=”text-area” rows=”10">textarea>
    <button onclick=”format()”>Test Mebutton>
    <div id=”output”>
    div>
div>
<script src=”index.js”>script>

Now to start on the interesting part. Now to get the Javascript working.

The first thing to do was to render the text from the text box into the output area. This involves finding the input text and setting the output’s inner html to that text.

function format() {
    let inputArea = document.getElementById(“text-area”);
    let text = inputArea.value;
    let outputArea = document.getElementById(“output”);
    outputArea.innerHTML = text;
}

Next is getting the text split into paragraphs. This is accomplished by splitting the text by ‘\n’ and putting each of these into a

tag. To do this we can map over the array of paragraphs, putting them in between

tags. Using template strings makes doing this very easy.

let paragraphs = text.split(“\n”);
let inParagraphs = paragraphs.map(paragraph => `${paragraph}
`);
outputArea.innerHTML = inParagraphs.join(“ “);

Whilst I was working though that, I was becoming annoyed having to copy and paste the test text into the text box. To solve this, I implemented an Immediately Invoked Function Expression (IIFE) to populate the text box when the web page renders.

(function start() {
    let inputArea = document.getElementById(“text-area”);
    let text = `The app highlights lengthy, …. compose something new.`;
    inputArea.value = text;
})();

Now the text box was pre-populated with the test text whenever you load or refresh the web page. Much simpler.

Highlighting

Now that I was rendering the text well and I was testing on a consistent text, I had to work on the highlighting. The first type of highlighting I decided to tackle was the hard and very hard sentence highlighting.

The first stage of this is to loop over every paragraph and split them into an array of sentences. I did this using a split() function, splitting on every full stop with a space after it.

let sentences = paragraph.split(‘. ’);

From Heminway I knew that I needed to calculate the number of words and level of each of the sentences. The level of the sentence is dependant on the average length of words and the average words per sentence. Here is how I calculated the number of words and the total words per sentence.

let words = sentence.split(“ “).length;
let letters = sentence.split(“ “).join(“”).length;

Using these numbers, I could use the equation that I found in the Hemingway app.

let level = Math.round(4.71 * (letters / words) + 0.5 * words / sentences — 21.43);

With the level and number of words for each of the sentences, set their difficulty level.

if (words < 14) {
    return sentence;
} else if (level >= 10 && level < 14) {
    return `${sentence}`;
} else if (level >= 14) {
    return `${sentence}`;
} else {
    return sentence;
}

This code says that if a sentence is longer than 14 words and has a level of 10 to 14 then its hard, if its longer than 14 words and has a level of 14 or up then its very hard. I used template strings again but include a class in the span tags. This is how I’m going to define the highlighting.

The CSS file is really simple; it just has each of the classes (adverb, passive, hardSentence) and sets their background colour. I took the exact colours from the Hemingway app.

Once the sentences have been returned, I join them all together to make each of the paragraphs.

At this point, I realised that there were a few problems in my code.

There were no full stops. When I split the paragraphs into sentences, I had removed all of the full stops.
The numbers of letters in the sentence included the commas, dashes, colons and semi-colons.

My first solution was very primitive but it worked. I used split(‘symbol’) and join(‘’) to remove the punctuation and then appended ‘.’ onto the end. Whist it worked, I searched for a better solution. Although I don’t have much experience using regex, I knew that it would be the best solution. After some Googling I found a much more elegant solution.

let cleanSentence = sent.replace(/[^a-z0–9. ]/gi, “”) + “.”;

With this done, I had a partially working product.

Hard sentence highlighting

The next thing I decided to tackle was the adverbs. To find an adverb, Hemingway just finds words that end in ‘ly’ and then checks that it isn’t on a list of non-adverb ‘ly’ words. It would be bad if ‘apply’ or ‘Italy’ were tagged as adverbs.

To find these words, I took the sentences and split them into an arary of words. I mapped over this array and used an IF statement.

if(word.match(/ly$/) &&, !lyWords[word] ){
    return `${word}`;
} else {
    return word
};

Whist this worked most of the time, I found a few exceptions. If a word was followed by a punctuation mark then it didn’t match ending with ‘ly’. For example, “The crocodile glided elegantly; it’s prey unaware” would have the word ‘elegantly;’ in the array. To solve this I reused the .replace(/^a-z0-9. ]/gi,””) functionality to clean each of the words.

Another exception was if the word was capitalised, which was easily solved by calling toLowerCase()on the string.

Adverbs working

Now I had a result that worked with adverbs and highlighting individual words. I then implemented a very similar method for complex and qualifying words. That was when I realised that I was no longer just looking for individual words, I was looking for phrases. I had to change my approach from checking if each word was in the list to seeing if the sentence contained each of the phrases.

To do this I used the .indexOf() function on the sentences. If there was an index of the word or phrase, I inserted an opening span tag at that index and then the closing span tag after the key length.

let qualifiers = getQualifyingWords();
let wordList = Object.keys(qualifiers);
wordList.forEach(key => {
    let index = sentence.toLowerCase().indexOf(key);
    if (index >= 0) {
    sentence =
        sentence.slice(0, index) +
        ‘class=”qualifier”>’ +
        sentence.slice(index, index + key.length) +
        “” +
        sentence.slice(index + key.length);
    }
});

With that working, it’s starting to look more and more like the Hemingway editor.

Getting complex phrases and qualifiers working

The last piece of the highlighting puzzle to implement was the passive voice. Hemingway used a 30 line function to find all of the passive phrases. I chose to use most of the logic that Hemingway implemented, but order the process differently. They looked to find any words that were in a list (is, are, was, were, be, been, being) and then checked whether the next word ended in ‘ed’.

I looped though each of the words in a sentence and checked if they ended in ‘ed’. For every ‘ed’ word I found, I checked whether the previous word was in the list of pre-words. This seemed much simpler, but may be less performant.

With that working I had an app that highlighted everything I wanted. This is my MVP.

All the highlighting working

Then I hit a problem

As I was writing this post I realised that there were two huge bugs in my code.

// from getQualifier and getComplex
let index = sentence.toLowerCase().indexOf(key);
// from getPassive
let index = words.indexOf(match);

These will only ever find the first instance of the key or match. Here is an example of the results this code will produce.

Code with bugs in

‘Perhaps’ and ‘been marked’ should have been highlighted twice each but they aren’t.

To fix the bug in getQualifier and getComplex, I decided to use recursion. I created a findAndSpan function which uses .indexOf() to find the first instance of the word or phrase. It splits the sentence into 3 parts: before the phrase, the phrase, after the phrase. The recursion works by passing the ‘after the phrase’ string back into the function. This will continue until there are no more instances of the phrase, where the string will just be passed back.

function findAndSpan(sentence, string, type) {
    let index = sentence.toLowerCase().indexOf(key);
    if (index >= 0) {
        sentence =
            sentence.slice(0, index) +
            `${type}">` +
            sentence.slice(index, index + key.length) +
            "" +
            findAndSpan(
                sentence.slice(index + key.length), 
                key,
                type);
    }
    return sentence;
}

Something very similar had to be done for the passive voice. The recursion was in an almost identical pattern, passing the leftover array items instead of the leftover string. The result of the recursion call was spread into an array that was then returned. Now the app can deal with repeated adverbs, qualifiers, complex phrases and passive voice uses.

Statistics Counter

The last thing that I wanted to get working was the nice line of boxes informing you on how many adverbs or complex words you’d used.

To store the data I created an object with keys for each of the parameters I wanted to count. I started by having this variable as a global variable but knew I would have to change that later.

Now I had to populate the values. This was done by incrementing the value every time it was found.

data.sentences += sentence.length
or
data.adverbs += 1

The values needed to be reset every time the scan was run to make sure that values didn’t continuously increase.

With the values I needed, I had to get them rendering on the screen. I altered the structure of the html file so that the input box and output area were in a div on the left, leaving a right div for the counters. These counters are empty divs with an appropriate id and class as well as a ‘counter’ class.

<div id=”adverb” class=”adverb counter”>div>
<div id=”passive” class=”passive counter”>div>
<div id=”complex” class=”complex counter”>div>
<div id=”hardSentence” class=”hardSentence counter”>div>
<div id=”veryHardSentence” class=”veryHardSentence counter”>div>

With these divs, I used document.querySelector to set the inner html for each of the counters using the data that had been collected. With a little bit of styling of the ‘counter’ class, the web app was complete. Try it out here or look at my code here.

The completed app

7 important lessons about programming that I’ve learned at 17

freeCodeCamp — Thu, 23 May 2019 17:58:30 +0000

By Alec Jones

Hey there, I’m Alec, I’m 17 years old, I’ve been learning web development since I was 12. I’m far from an excellent developer, but I’ve definitely learned some things about being an average one. ?

Here are some lessons I’ve learned that I think every developer, especially new developers, needs to know.

No one knows everything

No developer knows everything and you don’t need to know everything.

There is so much more to being a developer than knowing by heart, for example, the methods of manipulating arrays in PHP version 5.6. It doesn’t matter if you know the little things, they are a google search away if you forget them.

There are far more important things you can do as a developer to improve yourself than learning these tiny insignificant details like,

Improving your problem-solving skills
Improving your teamwork and communication skills
Increasing your knowledge of programming concepts and languages
Creating awesome projects to showcase your work
Focusing on writing clean efficient code

The great thing about being a developer is that you don’t need to know everything. You only need to know how to solve problems.

Having bugs is essential to learning

_Source: [imgur](https://imgur.com/gallery/HTisMpC" rel="noopener" target="blank" title=")

If you’re programming something and you’re not coming across any bugs, it means you’re learning nothing.

Not running into bugs does not mean that you’re somehow a great developer because you’re too smart to make a mistake. It means that you’ve already developed something similar, so many times, that you already know how not to run into the bugs.

When you’re solving bugs you are becoming a strong developer. There are endless bugs in development, so the faster you can learn to handle them, the better off you’ll be.

Formal education is not necessary

At 17, I’m currently grappling with this topic. Should I attend university so I can acquire a computer science degree?

That’s a tough question for me to answer. But, most people reading this are probably not 17, in fact, most of you probably already have a job.

If you have already attended college or university, you definitely do not need a computer science degree. You also don’t need to do all of these coding boot camps either.

A GitHub profile with some interesting projects on it speaks volumes. If you can demonstrate that you can program, it doesn’t matter what background you have.

It’s simply a question of how do you learn best.

I didn’t have the choice, I had to learn to code on weekends because I couldn’t take 6 weeks off of high school for a boot camp. ?‍♂️

If you want to go back to university to get a computer science degree or attend an 8-week boot camp, go for it. But it’s nowhere close to necessary.

Googling is a legitimate skill

If you want to be a great developer, you will need to enhance your googling ability. It’s essential to be able to find solutions and code that you are looking for.

There is frequent googling, especially when you’re learning a brand new technology.

There are many different ways to improve your search results through little “hacks” and tips Google has set up.

Coding projects can take down weird rabbit holes of things you need to add to your code. Sometimes, you need to find a solution to a problem you don’t even understand. But thankfully, Google has the answer somewhere.

Try thinking rather than coding

When you’re coding, do you ask yourself, “what’s the best way to write this code?”

I know I usually don’t until after I’ve written a subpar solution. Far too often, I find myself writing the solution that first popped into my head. Most of the time, the first solution to the problem isn’t the best.

The act of typing out the code is short. Anyone can write code quickly that will be sloppy. You need to take the time to come up with a good stable solution.

Though it can be tedious, test driven development promotes this greatly as you have to think about what functionality you expect and how it’ll work. You can’t freehand the code when you have to plan it ahead of time.

Of course, there are exceptions to every rule. I’m not saying you should sit quietly and think about every line of code.

But, with anything, save yourself the time of refactoring and bug fixing by thinking about your code.

Be careful with tutorials

Following along with a coding tutorial is great for starting out, but I think these tutorials are not the only resource you should use for learning.

You’re not actually learning when you follow a coding tutorial. You may learn a little, but you’re not truly learning what you’re doing and why you’re doing it.

Additionally, these tutorials can also quickly skip over important parts of the code, as illustrated in Quincy’s tweet. It’s so easy to just copy and paste and not ask questions from the tutorial.

A far better way to learn to code is to set out on a project you’d like to build. Then, just get started. Find little pieces of code, write your own code, solve the bugs, read explanations and posts.

The most effective way to learn is to piece the puzzle together until you have a program that works.

Tabs are better than spaces

_[image source](https://www.youtube.com/watch?v=V7PLxL8jIl8" rel="noopener" target="blank" title=")

I know. While you reading this article, you were thinking, “he’s got to be a spaces guy, it’s obvious.” I’m afraid not, everyone should be using tabs when they code.

I get it. Tabs can look different from other people’s computers. But, it’s so nice to just hit the tab, rather than smacking that space bar again and again. Treat yourself to tabs people!

Thanks for reading these short, but important, lessons that I’ve learned. If you disagree with any points I make, I’d love to hear why!

What I Learned from My First Contribution To Node.js Core

freeCodeCamp — Wed, 26 Dec 2018 18:44:36 +0000

By Yael Hermon

A couple of weeks ago my very first PR for Node.js core was merged! A few days later, I decided to tweet about it and share how positive this experience was, hoping to encourage others to contribute as well.

Later, Uri Shaked suggested I share my experience in a short blog post. Uri always has great ideas. Thanks, Uri!

How did I end up with this PR?

I’m glad you asked. Let me start with a little background. I love Node.js, and contributing to it was actually on my bucket list for a really long time. I never got around to doing it because I always told myself that I didn’t have the time for it, or that I might not be qualified enough, or other lame excuses.

The plot twist happened when I was working on a talk for a JavaScript-Israel meetup about the V8 Garbage Collector. Benjamin Gruenbaum, a Node.js core collaborator, asked me if I would like him to connect me with V8 engineers to review my slides. Umm…obviously I would.

So he did, which turned out pretty awesome. Benji also asked me if I was interested in contributing to Node.js core. Again, I said yes. No more excuses. Stuff just got real.

Setting up the environment

I first had to build Node.js on my machine. It was surprisingly easy, thanks to the great docs Node.js has. Next, I decided to play around and start debugging it.

I’d be lying if I said it was smooth sailing from the start. The last time I worked with C++ was back in 2012. I was rusty. Moreover, back then I had a completely different environment than I have now. I had a Windows PC with Visual Studio on it, while now I am running VSCode on a Mac.

I love VSCode so I wanted to setup VSCode for this project too. I soon found an extension and configured things to work. For my debugging configuration, I ended up setting up a node debugger and a lldb debugger to attach to the Node process. That worked great.

Working on an actual issue!

So Benji connected me with Anna, who’s the Node.js core collaborator who implemented ‘worker_threads’. Benji also pointed me at this issue. I looked at the issue and tried reproducing it with as little code as possible, just to get rid of the noise.

I struggled with creating a test case that reproduced the issue, since it was caused by a race condition. The code that failed when running inside Node.js wouldn’t fail in my testing environment. Eventually, I found something that failed on all of my runs. Although it might not fail on every machine, or every time, Anna confirmed it was good enough. Next, I started debugging it to see what was actually happening there.

If you’ve never heard of ‘worker threads’, that’s probably because they are quite new and are currently in an experimental state. Workers let you create multiple environments running on independent threads. They are useful for performing CPU-intensive JavaScript operations, without blocking the main thread.

The main thread and the worker thread can communicate with each other through a message channel between them. In addition to this message channel, there is another message channel where internal messages are sent, such as stdout of the worker. When you console.log inside the worker, it arrives to the main thread through this internal message channel and the main thread handles it by pushing it to its stdout stream.

The problem was that we were calling the kDispose function in the JS worker class before waiting for all messages from worker’s stdio to be processed by the main thread through the internal message port. So when the worker thread finished, we lost the references for the parent side stdio streams, and a message to the parent could possibly arrive after that.

At first, I tried lots of different approaches to getting this fixed, including setting a promise to be resolved when the message port was done, awaiting it before disposing, and passing JS callbacks to the C++ layer.

Chatting with Anna about it revealed to me that a drain method existed for the MessagePort and it emitted all its incoming messages synchronously. So in the end, all the messages from it would be processed. In fact, drain was already called for the external MessagePort. How hadn’t I seen this function all this time? ? I added a call to drain also on the internal MessagePort. The fix was that simple.

An important thing to remember is — it’s totally fine trying out weird approaches along the way. That’s how you learn. And after debugging lots of worker_threads code, I can say that I know some of its codebase pretty well now :)

Benji and Anna were so welcoming right from the beginning. This was a great experience. I learned a lot from Anna and from the code, which was very challenging. It’s definitely not something I usually deal with in my day-to-day.

I can’t wait to work on my next issue!

The unforgettable lessons I’ve learned from 100 boring conferences

freeCodeCamp — Thu, 28 Jun 2018 19:17:05 +0000

By Daniel Burka

I’ve been to many conferences over the last twenty years. Mostly the speakers droned on about their topics, which were easily forgotten. Thinking back, only a few big ideas really stuck with me. These are three ideas I’ve come back to over and over again in my career.

There is a big difference between designed well and well-designed.

Graphic design legend David Carson gave a tedious presentation at one of the first conferences I ever attended. However, fifteen years later, I still clearly remember a pair of slides from his talk that looked something like this:

_(photo credits [Bernard Hermant](https://www.flickr.com/photos/stml/3947231477/in/photolist-71NAp8-wSwLaQ-BTHab-mjzdvc-57nyDQ-oU1YMo-7RewhE-6D7qMk-6kfL4o-69XaF-6j8Nkf-bKFqj8-65RPHK-s94ZWv-8z8pYS-6EqKew-6VsTUn-9zYac8-iaRSMQ-dHQqFh-dzKeKM-4zdjFS-6QbtXK-pv9icm-6MSt5M-6gaaae-59T7WL-7HG2uA-9zCa75-78mVco-ban3Wk-6KNV9h-cZFmQh-dpPcsC-VQzu4u-Vkbu3b-5RFCC1-AvRuS-dmLia3-ahdrAT-bQh6LR-SfygU9-9wfKvR-fEqwDw-dKRVsu-9qhz2x-26JPXgA-7GihBU-3KkkXa-HYHfEe" rel="noopener" target="_blank" title="">STML and Take PowerPoint design seriously.

Yeah, you read that right. Over a decade ago, I heard a design executive from Adobe talk about how she got her start. She explained how, during the first few years of her career, she was bored to death designing slides for her bosses. Regardless, she took to the task with an open heart and poured her energy into designing the best damn PowerPoint slides.

In the process, she developed communication skills that served her well later on…and more importantly, an attitude that every design challenge is worthy of her effort. Amen.

PS: I wish I could remember her name or at least where I saw her speak. If you know who she might be, please share. I’d love to credit her and personally say thank you.

Don’t take advice from speakers at conferences.

To put it politely, TechCrunch founder Michael Arrington is loud. When he waltzed onto the stage five minutes late with a talk on “15 Important Lessons for Entrepreneurs”, I was ready to dismiss whatever he was about to say. But to my surprise, the first important lesson held a lot of truth.

Mike addressed the sea of heads: “If you’re going to start the next big thing, don’t listen to anything that I’m about to say.” Out of context, that sounds extreme. However, the way I interpreted Mike’s comment is:

Conference speakers confidently dole out lessons based on what worked well for them. What worked well for them is only ONE path, not the ONLY path. Your way may be fundamentally different, and that’s GREAT. Few people accomplished great things by copying what others have done.

In short, take every damn thing you hear at a conference with a huge shovel-full of salt. Then go find your own path.

Which lessons actually stuck with you from presentations over the years? I’d love to hear your story in the comments…

lessons learned - freeCodeCamp.org

What I Learned from Maintaining a Repo During Hacktoberfest and Merging 356 PRs

Stats on Oct 1, 2022

Stats on November 1, 2022

Table of Contents

How it All Began

Preparing for Hacktoberfest

Step 1: Adding the Hacktoberfest topic and labels

Step 2: Creating issue templates

Step 3: Updating the contributing documentation

Step 4: Creating well-defined issues

Sample issue

Step 5: Adding Saved replies

Step 6: Opening up GitHub Discussions

Lessons I learned during Hacktoberfest

Lead with patience, empathy, and kindness

Don't get worked up over spam

How to gracefully close PR's that will not be accepted

Conclusion

How I Developed My First Adventure Game

What We'll Discuss in This Article

How I got Into Adventure Games

First adventure game attempt

Second attempt

Third and Final Adventure Game Attempt: Occulto

Intro to the game

Tech I Used to Build My Adventure Game

Unity vs WebGL

Pros of WebGL

Cons of WebGL

Pros of Unity

Cons of Unity

What I learned While Building Occulto

Someone needs to lead the project

Have the right attitude

Work in your spare time

Remove as many obstacles as you can

Focus on developing the game

Release a one scene version of the game

Final Notes

How to Recover from Deployment Hell – What I Learned After My Discord Bot Crashed on a 1,000+ User Server

What Went Well with Deployment

Avoid Feature Creep At All Costs During Development

Abide by the Principle of Least Privilege

Other Observations from Deploying My Bot

What I Needed to Fix

Fatal Crashes

New Features for Usability

Future-proof Logging

Scalability

From Tutorial Code to Production Code

What Makes a Great Side Project

5 Mistakes Beginner Web Developers Make – And How to Fix Them

We Were All Beginners

Mistake #5: Adding Spaces in File Names

Mistake #4: Ignoring cAsE sEnSiTiViTy

Mistake #3: Not Understanding File Paths

Mistake #2: Not Naming Your Default Page Index

Mistake #1: Not Taking A Break!

Conclusion

How I Escaped Tutorial Purgatory – and How You Can, Too

How I Broke Free from Tutorial Purgatory

Meetups Changed My Life

This is What Freedom Feels Like

Your Keys to Success When Learning to Code

Things I Wish I Knew Before Working with Electron.js

Background

1. Start small (and slow) ?

With convenience comes complexity

2. Mindfully structure your app ?‍♂️

3. Design with the threading model in mind ?

4. Test ❌, test ❌, and test ✔️

GPS location extraction ?️

Funky pictures ?

Summary

What I've Learned in My First Year as a Software Engineer

Mentorship

Be your own advocate

Learn how to ask for help

You really don't have to be an expert – really.