This article first appeared on dev.to. You can find the original discussion here

It’s everywhere !

Software is everywhere. In our cars, our planes, our computers. Our banks use software. We use it to communicate every single day, every single second. Our governments can’t pass laws without relying on software at some point. Hell, my grandmother even use software! She has a bank account, a car and some insurance! No one escapes it.

Continue reading The Programmer’s Oath

Read more

Introduction

To continue my series on the CRUD (Create, Read, Update, Delete) API in MongoDB, we will talk about the ‘D’, deleting documents.

Note: I will be using the MongoDB shell in my terminal to show some examples. If you do not have it installed, please refer to my Quick start with MongoDB article

As always, MongoDB has explicit methods names to describe its actions. So, to delete documents from a collection, we have two methods: deleteOne() and deleteMany(). Both of these methods take a filter as their first parameter. Let’s see these in action:
Continue reading Removing documents in MongoDB

Read more

In this article, we will go through the different data types that MongoDB supports. Let’s start with the basic types first. We can identify 6 basic types: null, boolean, numeric, string, array and object. If you are familiar with JSON, the representation of data in MongoDB will look familiar. JSON allows you to represent data by using key/value pairs and use those six basic types.
Continue reading Data types in MongoDB

Read more

I recently found out that it’s very easy to get lost in the daily challenges of being a freelancer. The lack of real structure around yourself can make it difficult to distinguish code written for work and code written for play. It has become a bit difficult for me to say stop, my work for today is done, without feeling a little guilty about something. It can be how productive I was during the day, or I perceived the quality of the code I wrote.

Those things can be solved by a different mindset and a strong discipline. Work starts and stops at a certain predefined hour, except emergencies. Whatever code I write after or before those hours, it’s playtime.

The other problem I need to solve is, what do I do in my playtime? I like to learn new things, but I also need to become better. Learning something new is quite different from working on your fundamentals. So I chose two courses of actions in my case:

  • Learn a new language: I chose C#.
  • Choose a engaging side project to work on.

There is not really anything crazy behind the C# choice. I love to learn using Treehouse and they have a course on this language, so that’s really all there is to it. It’s also something quite different from Javascript, which is the language I mostly use. I believe it’s always important to explore new things.

Here comes the real problem: what side project to choose? I thought about this quite a bit. I still haven’t found anything serious yet, only a few ideas. But I think I can list a few things that a side project should have in order to become interesting:

  • Be personal. Solve one of your problems. If the project is something you can relate to, it will be easier to motivate yourself to work on it and/or make it better.
  • Be in the realm of possible. This one is about your current skills as a developer and also about being realistic. I love video games, but I don’t believe trying to make the next World of Warcraft could be considered a good side-project.
  • Have a future. It can scale. If more users get to use your project, that would not be a problem.
  • Be open source. Two reasons: you increase the chance of having other people use your project. And it could become easier to find help if you get stuck at one point. It would most likely help with the scalable issue.

So, that is what I think a side project should have to make me work on it on a regular basis. I decided that I wouldn’t start a side project until I become quite sure that I would spend some time on it and be proud of it in the end.

Let me know if you think a side project should have different attributes. How do you choose your side projects?

As always, feel free to share and comment.
Have a nice day!

Read more

Introduction

The #100DaysOfCode is a challenge that aims at making coding a habit. The concept is very simple. Every day, you spend at least an hour doing non-work related programming. The challenge also insists on building projects, and not spending your time doing only tutorials or following courses. You must put what you learned in practice doing real projects. The projects are totally up to you of course, depending on your current skills and/or needs.

You can find more information about the #100DaysOfCode on Alexander Kallaway’s blog post.

The most important thing, in my opinion, is not the habit in itself, though it is very important. The crucial thing to me is being accountable. Hundreds of people are taking this challenge. You have the knowledge that you are not alone. You are also committing to tweet your progress and encourage at least two people each day. There is a level of accountability and connectivity with other people that just make the whole thing so much more appealing to me, and therefore, I feel confident I will be able to do it.

What to build?

That is the bit question that I had. I finished the FreeCodeCamp curriculum, all three certificates. So, I won’t be re-building any of those projects. In my opinion, in order to succeed, the projects I will choose must follow a few rules:

  • Must not take too much time to realise (the goal is to create several projects in that timeframe of 100 days)
  • Must be challenging, but not impossible. I’m not the best developer out there, so I need to choose projects I an actually do. In the mean time, the goal is to push myself, I must choose something outside of my comfort zone.
  • Must be something I would like to do. There are billions of different things I can code, but not every single one will be appealing to me. This is outside of work. **Having fun **is the number one thing I’ll be worried about.

Every single project I will choose to do will have to follow those three rules.

The brainstorm (!!!)

I spent a little bit of time thinking about this, and I cam up with this, so far:

  • War (Card Game)
  • Make a Diary application
  • Make an app using the NASA’s API
  • Belote (French Card Game)
  • A real-time application (socket.io)
  • Something with Bots ?

Here are 6 different projects that I came up with. As you can see, it is still very vague. I only researched the first one a bit deeper (War). In the holidays, I played a lot of card games with my family. That was amazing and this is why I put two cards game in there. The socket.io application is kinda related to my work, but I always enjoyed working with real-time technologies. The rest are just the scratch your own itch type of application.

Will I be able to do all of this in 100 days? Doesn’t matter. The goal is to build an habit of coding every day. The goal is to make sure that you are use to be outside your comfort zone and learn every day.

In each of theses applications I want to build, there are things I don’t have much experience with. The animations that will be required in the cards games for example, never used that before.

So, this is it! I’m personally starting tomorrow (January 3rd). I look forward to see any of you on this path.

As always, feel free to comment and share.
Have a nice day!

Read more