Forem: mnivoliez

Hello, I'm a junior and I suck at organizing my work, how do you do?

mnivoliez — Fri, 07 Jun 2019 05:55:20 +0000

Hello, I have started a new job some months ago and it appears that I have serious difficulties to organize my work and speak about it. Often I can't give a reliable answer at the question "where are you at in your task?". Do you have any advise or method I could try to improve this aspect?

I am a developer, got a new job, and I'm afraid to take it

mnivoliez — Mon, 03 Sep 2018 17:54:58 +0000

Hello!, I'm Mathieu NIVOLIEZ. Recently (about 1 month, maybe more) I sign up in a company. The job is starting the 1er of October in a city called Grenoble. My wife and myself went there to find a new "home" and the city... let say have yet to convince us. To be honest my wife is scared to go there (the city seems pretty hostile) and I'm not sure either about it. Moreover, she's afraid she will not find any job there. I'm hesitating to end the trial period even before the start of the contract. Have you ever have to deal with this kind of situation? If yes how did you do it? Any advise to assess the situation there?

Thanks in advance.

How do you deploy stuff? And what is the tool you use for?

mnivoliez — Thu, 31 May 2018 09:29:24 +0000

Hello! I would like to open a discussion about how to deploy and the tools use for that.

As context, I have worked at a company which use a "artefact" repo to store artefacts generated by the CI. Then, deployement servers were informed that there was a new artefact and they get them. Personnally, I use gitlab runner to deploy my blog with a rsync command (but honestly it feels dirty, but it work). I know also about the "git push as deploy", but I am not convinced either since you don't want the full repo but only a package solution.

So how do you deploy stuff?

What is your website?

mnivoliez — Tue, 29 May 2018 17:03:48 +0000

Hello! I would like to open a discussion about our website.
I got the idea after the post of dfimbres.

what technology have we use to do it?
what challenge have we come across while doing it?
stuff around it (building, testing and deploy)?

This could lead to some advice that one could give to another about it.

As I suggested the discussion, I will start.

My website is available here. I currently use gutenberg to build it, but I have used cobalt before.

I keep the code on my self hosted gitlab and I deploy it on another server through a gitlab-ci runner.

I have mostly struggle with the design (responsive, css, etc...) as I am not really good at it.

What do you think of it?

Tell me a story I could code #2

mnivoliez — Fri, 11 May 2018 13:00:36 +0000

Originally post on my blog

Hello everyone! It's us again, Gaetan and Mathieu!
This is the second episode of Tell me a story I could code.
At our surprise, the concept worked more than we hope, and you, YES YOU, have been very prolific!

"What was proposed?"

In short, a movement, a dialog and the apparition of a dragon was proposed.
Here is how we have proceed.

First, we have now a dragon, which is still a character but different from a human.
Second, characters can speak to each other.
Third, characters can go to or come from location.

So, let's rename our Character structure to Human:

struct Human {
  name: String,
  money: i32,
}

and then create the Dragon struct:

struct Dragon {
  name: String,
}

Next step abstract the Character behaviour:

pub trait Character {
    fn new(name: &str) -> Self;

    fn says_to(&self, other: &Self, msg: &str);

    fn move_to(&self, location: &Self);

    fn get_name(&self) -> &str;

    fn run_away_from(&self, location: &Self);
}

But as it, the only Location a Charater can go to or run from is another Charater. So let say that we want Character able to do that with a Localisable struct.

pub trait Localizable {
    fn get_location(&self) -> String;
}

We can then adapt the Character struct like that to tell that some metho will use a type T that implements Localizable:

pub trait Character {
    fn new(name: &str) -> Self;

    fn says_to<T: Character>(&self, other: &T, msg: &str);

    fn move_to<T: Localizable>(&self, location: &T);

    fn get_name(&self) -> &str;

    fn run_away_from<T: Localizable>(&self, location: &T);
}

Then, we can implement those traits to Character

#[derive(Debug, Clone)]
pub struct Human {
    pub name: String,
    pub money: i32,
}

impl Human {
    pub fn find(&mut self, item: Item) {
        match item {
            Item::Money(amount) => {
                self.money += amount;
                println!("Oh {} penny! \" said {}.\"", amount, self.name);
            }
        }
    }
}

impl Character for Human {
    fn new(name: &str) -> Self {
        println!("There was a man named {}.", name);
        Human {
            name: name.to_owned(),
            money: 0,
        }
    }
    // Character needs to get back to another
    fn move_to<T: Localizable>(&self, location: &T) {
        println!("{} move to {}", self.name, location.get_location());
    }

    fn says_to<T: Character>(&self, other: &T, msg: &str) {
        println!("\"{}\" said {} to {}", msg, self.name, other.get_name());
    }

    fn get_name(&self) -> &str {
        self.name.as_str()
    }

    fn run_away_from<T: Localizable>(&self, location: &T) {
        println!("{} run away from {}", self.name, location.get_location());
    }
}

impl Localizable for Human {
    fn get_location(&self) -> String {
        self.name.clone()
    }
}

and for Dragon

#[derive(Debug, Clone)]
pub struct Dragon {
    pub name: String,
}

impl Dragon {
    pub fn fly_toward<T: Localizable>(&self, location: &T) {
        println!(
            "{} the dragon fly toward {}",
            self.name,
            location.get_location()
        );
    }
}

impl Localizable for Dragon {
    fn get_location(&self) -> String {
        format!("{} the dragon", self.name)
    }
}

impl Character for Dragon {
    fn new(name: &str) -> Self {
        println!("There was a dragon named {}.", name);
        Dragon {
            name: name.to_owned(),
        }
    }
    fn move_to<T: Localizable>(&self, location: &T) {
        println!("{} move to {}", self.name, location.get_location());
    }

    fn says_to<T: Character>(&self, other: &T, msg: &str) {
        println!("\"{}\" said {} to {}", msg, self.name, other.get_name());
    }

    fn get_name(&self) -> &str {
        &self.name
    }

    fn run_away_from<T: Localizable>(&self, location: &T) {
        println!(
            "How that, {} the dragon is running away from {}",
            self.name,
            location.get_location()
        );
    }
}

Note that we specified that only Human can find Item and that only Dragon can fly, so far.

Also note that the name inside Character was before a &'static str (meaning a String slice with a static lifetime) and have been change for a String. The reason for that it is easier to work with the String and do not require to care about the lifetime (the "scope" in which the variable lives) in case we have to return it in a fashion manner. Also, note that using static mean that the lifetime of the reference is the same as the application lifetime.

Now the output looks like:

Once upon a time...
There was a man named Bob.
Oh 1 penny! " said Bob."
There was a man named Joe.
Bob move to Joe
"Dude! Look what I found!" said Bob to Joe
"You should invest the penny in the Sheriff of Nottingham's Bank" said Joe to Bob
"But I already have invested money in the bank, I want to buy a horse!" said Bob to Joe
There was a dragon named Igorrr.
Igorrr the dragon fly toward Bob
Bob run away from Igorrr the dragon
"The shiny thing belongs to me" said Igorrr to Bob
"Never! Founders keepers, you Reptilebug!" said Bob to Igorrr

The full code is available here.

Tell me a story I could code

mnivoliez — Sun, 06 May 2018 17:57:21 +0000

Originally post on my blog

Hello everyone! Today one colleague and friend of mine, Gaetan, would like to propose you a simple (or not) concept!

It's a code of which you are the story teller!

"Whaaaaat?"

Let me explain! We propose you to tell a story (a little one), sentence by sentence. Each time a sentences is selected, we will try to express the story into code.

An exemple is worth 1000 speech so here is the start of our story:

"Once upon a time, a young knight name Bob found a penny!"

#[derive(Debug)]
struct Story {
    pub time: &'static str,
    pub main_character: Character,
}

#[derive(Debug)]
struct Character {
    pub name: &'static str,
    pub money: i32,
}

fn found_a_strange_penny(character: &mut Character) {
    character.money += 1;
    println!("Oh a penny! \" said {}.\"", character.name);
}

fn main() {
    let mut story = Story {
        time: "Once upon a time",
        main_character: Character {
            name: "Bob",
            money: 0,
        },
    };

    found_a_strange_penny(&mut story.main_character);
}

All the code will live in this repository.

So, it's up to you, reader, to continue the story.
Post a comment with one sentence or two and we will try to code that.
We will choose the comment that appeal us the most!

Start :p

--
Gaetan and Mathieu

Koda: the importance of testing

mnivoliez — Wed, 04 Apr 2018 15:15:04 +0000

Originally post on my blog

Hello everyone! Today we are going to talk about the importance of testing in a game project.

"Are you going to speak about Koda?"

That’s right, I will speak about our experience in developing Koda Kiyomori’s guardian.

I will scope a little the subject, I will speak about play test or testing in real condition.

"What do you mean by test in real condition?"

What I call test in real condition is when you test how well is received, or how behave, the thing you are building into an environment close or identical to the production one.
In our case, we develop a game, so we put people to test it.

"How did you do?"

That’s actually a really great question. We got the chance to have a team member who had worked inside a community center and we were able to go there to put our game to the test with the kids.
To do that, we established a ‘test protocol’.

Children answered a first survey revealing their sensibility toward video games.
We observed children playing the game, noting their behaviors and reactions to the game.
Children took a second survey to get their direct individual feedback.
We organized discussion with children to get deeper into what was globally well received or not.

"Was it successful?"

Yes, it was. We were able to determine several bugs and flaws in our game design. And we validated that the global direction of the game was the right one.

More specifically, we got several feedback about the camera behavior and the difficulty of the different zones of the game.

And everybody loved our mascot Koda :p

"So it was perfect?"

No, absolutely not! First we were very stressed. We had never done that before. Here the biggest elements we could (and will) improve for next time:

The survey design made it difficult to fill it quickly, we should maybe have used something like Google form from the start instead of word document.
We roughly knew the number of children, we should have known the exact number and established test groups beforehand instead of doing it on the fly.
We planned to record test sessions but the camera was not well centred, so many record was difficult to exploit afterwards.

There is certainly a pile of elements I forgot here, but I think it is a pretty good list already.

"Will you do it again?"

Yes, actually, we organise play test on a daily basis to enhance our game. And as for play test at the scale I described, we already have a new appointment with the kids. :)

Overall, making tests like that is really important to at least validate what you are building. The sooner you do it, the sooner you will know if your idea works or not.
In our case, we significantly improved gameplay and mechanics. We also, and that is really important, gain more confidence in our project. It helps us to trust in our project and in our capacity to deliver something at the level of our expectations. And that is the crux of everything, if your team is confident and motivate, you will have better chance of success.

Before you leave this post, I got some news! The team Koda will be present at the Japan Touch in Lyon the 7th and 8th of April, so if you are there, come test our game! More on our Twitter and our Facebook!

-- Mathieu

Getting started with Rust: Enum on steroids!

mnivoliez — Sun, 01 Apr 2018 16:06:28 +0000

Originally posted on my blog

Hello everyone! Today subject was hard to decide on. But as the previous one was pretty tedious, I decided to go a subject more easy to speak of. So, today we are going to talk about enum in Rust!

"Yeah,.... but what is an enum anyway?"

Let me explain this first. An enum (or enumeration) is a type where all possible value are listed.
To give an example, let say that I can take care of different dogs: doggo, doge and pupper.

Then we can define a enum to represent that:

enum DogKind {
  Doggo,
  Doge,
  Pupper
}

Let's decompose that. First we use the keyword enum to express that we are going to define an enum. Then there is the name of the enum, in our case it is DogKind. Then, between { ... } we define all possible value of DogKind separate with comas.

We are now able to use it as this:

fn take_care_of_dog(kind: DogKind) {
  match kind {
    DogKind::Doggo => take_care_of_doggo(),
    DogKind::Doge => take_care_of_doge(),
    DogKind::Pupper => take_care_of_pupper(),
  }
}

Do you remember in the previous posts when I said that it is a good practice to read out loud the code? Enum in Rust are a good practice for that. Let do it for training.
We declare a function fn called take_care_of_dog which take a parameter kind of type DogKind. We know that DogKind is an enum define before. Then we check if which value of DogKind the parameter kind matches. And for every possible match, we define an action to follow. Here the arrow can be read as then, do that, so the match statement can be read as if it match Doggo, then do that.

"Ok, I have use other language before, this is just a switch case, no?"

Fair enough. But it is only the begining. Let me show you something really fun.

Let take again our example from before, upgraded a bit:

enum DogKind {
  Doggo(String),
  Doge(String, String, String),
  Pupper { age: f32 }
}

"What the f... ... Freacking duck?"

That usually the response if you have never used language with tagged union.
Let me explain, for each value of DogKind, we want to have specific values, specific properties.
You can use this like that:

fn say_something_about_dog(kind: DogKind) {
  match kind {
    DogKind::Doggo(name) => println!("Good boy, {}", name),
    DogKind::Doge(such, wow, much) => println!("Such {}, wow {}, much {}", such, wow, much),
    DogKind::Pupper { age } => println!("Oh this pupper is {} years old", age)
  }
}

"Wow, such variant... But are we oblidge to express all possible case into the match statement?"

The match is exhaustive, meaning that you have to describe ALL cases.
Well, there is a syntaxic element that allow you describe the "default case": the _ placeholder.

fn say_something_about_dog(kind: DogKind) {
  match kind {
    DogKind::Doggo(name) => println!("Good boy, {}", name),
    DogKind::Doge(such, wow, much) => println!("Such {}, wow {}, much {}", such, wow, much),
    DogKind::Pupper { age } => println!("Oh this pupper is {} years old", age),
    _ => println!("What is that? it's not a dog... Is it alive?"),
  }
}

But, I cannot stress you enough that the default case is not robust. For example, let say that you add a kind of dogs: the Doggy. Then no match statement with the _ will fail to compile because this new kind will fall into the default case.
Again, the _ is not evil, it is a powerful too that must be use carefully.

"What about doing the same thing for different value?"

We can do that easily with the |:

enum DogKind {
  Doggo,
  Doggy,
  Doge,
  Pupper
}

fn great_dog(kind: DogKind) {
  match kind {
    Doggo | Doggy => println!("Who is a good boy? It's you!"),
    Doge => println!("Wow, such elagance, much raffinment"),
    Pupper => println!("How adorable!"),
  }
}

"Ok, are they other things we have to know about enum and match expression?"

Yeah. First you can use brackets inside match expression:

enum DogKind {
  Doggo,
  Doggy,
  Doge,
  Pupper
}

fn great_dog(kind: DogKind) {
  match kind {
    Doggo | Doggy => println!("Who is a good boy? It's you!"),
    Doge => println!("Wow, such elagance, much raffinment"),
    Pupper => {
      println!("How adorable!");
      println!("I pet the pupper");
    },
  }
}

And you can use match expression as assignment.

"Wait... what?"

Yep! Let say that you got a value that depends of the type of dog, you could write something like:

enum DogKind {
  Doggo,
  Doggy,
  Doge,
  Pupper
}

fn great_dog(kind: DogKind) {
  let action = match kind {
    Doggo | Doggy | Pupper => "Pet the dog",
    Doge => "Pay your respect to the venerable doge"
  }; // note the ";" at the end of the assignment expression.
  println!("{}", action); 
}

"Ok, seems useful..."

Yeah it is, and you want to know something? You probably already use it.
The Result<T,E> and Option<T> are enum themself.
And they are a good example of enum with traits...

But we will see traits the next time :p

So, see you next time for more, do not hesitate to comment any error, suggestion or anything about this post.

-- Mathieu

Getting started with Rust: Reference and Lifetime

mnivoliez — Mon, 05 Mar 2018 22:38:27 +0000

Originally posted on my blog

Hello everyone! You were waiting for it, and now you are going to get it! Ladies and gentlemen, today we are going to talk about reference and lifetime!

Before anything, I would like to point out that my knowledge of lifetime is pretty much incomplete. Yet, I think I know enough to give you a graps on it.

"Ok, so ... reference?"

Yep. So what is a reference? For the time being, I will use a book metaphor. Lets say that I got a book.

struct Book {
  name: &str,  
}

fn main() {
  let book = Book { name: "Clean code" };
}

Now let say that I pass it to you so that you can read and write in it.

struct Book {
  name: &str,  
}

fn pass_to_reader(book: Book) {
  //read book
  //write in book
}

fn main() {
  let book = Book { name: "Clean code" };
  pass_to_reader(book);
}

Now, you got the ownership of my book. Put in other words, I can't interact with the book if you have it in your hand. I can't read, neither I can writte.

struct Book {
  name: &str,  
}

fn pass_to_reader(book: Book) {
  //read book
  //write in book
}

fn main() {
  let mut book = Book { name: "Clean code" };
  pass_to_reader(book);
  book.name = "The Tomb, a Lovecraft story"; //this will fail as I do not have the book
}

But you can return the book pretty easily:

struct Book {
  name: &str,  
}

fn pass_to_reader(book: Book) -> Book {
  //read book
  //write in book
  book //the book is returned here.
}

fn main() {
  let mut book = Book { name: "Clean code" };
  let mut book = pass_to_reader(book); // shadowing, lets keep that for another post, for now it just works
  book.name = "The Tomb, a Lovecraft story"; //this will work as the book as been returned.
}

This is the notion of ownership. To put it simply, it define who is responsible of what. In this example, the book is first passed to the function pass_to_reader which gain ownership of the book. At the end of the function, we return the book so that the main function regain ownership of it. Of course, this limit the interaction with the book. For exemple, what about several readers at the same time?

"Ah, now you will finally speak about reference?"

Yes, but to the ownership was a necessary step to understand the reference system.
So, what is a refence? It is like if I was keeping the book in my hand, opened, so that you can read (or write) in it. In short, I keep the ownership of the book, but I let you read it. To express this, we will use the symbol &.

struct Book {
  name: &str,  
}

fn pass_to_reader(book: &Book) {
  //read book
}

fn main() {
  let mut book = Book { name: "Clean code" };
  pass_to_reader(&book);
  book.name = "The Tomb, a Lovecraft story"; //this will work as main has kept the ownership of the book.
}

As you may have noticed, you can read but you can't write anymore. Lets fix that!

struct Book {
  name: &str,  
}

fn pass_to_reader(book: &mut Book) {
  //read book
  //write book
}

fn main() {
  let mut book = Book { name: "Clean code" };
  pass_to_reader(&mut book);
  book.name = "The Tomb, a Lovecraft story"; //this will work as main has kept the ownership of the book.
}

Ok now, the reference is mutable, so you can write in the book.

The mutable reference is like if, while holding the book, I gave you a pen to write in it.
This system wome with several limitations. First the mutable reference can only exist on a mutable binding. Second, you can have only one mutable reference on a binding, this include immutable reference.
This system of reference is called the borrowing as in "you borrow the book".

"Ok, and the lifetime in all that?"

Lifetime is the third pillar of this system. It assert that one borrow cannot outlive the binding it is borrowed from.
For example, let say that you borrow a book, which is compose of 100 pages.

struct Page(&str);
struct Book {
  name: &str,  
  pages: [Pages], 
}

fn pass_to_reader(book: &Book) -> &Page {
  //read book
  //return ref on a specific page
  &book.pages[50]
}

fn main() {
  let mut pages = [Page("1"), ..., Page("100")]; // I ellisped the page 2 to 99... I'm not gonna write it all
  let mut book = Book { name: "Clean code", pages: pages};
  let page = pass_to_reader(&book);
  book.name = "The Tomb, a Lovecraft story"; //this will work as main has kept the ownership of the book.
  println!("{}", page.0);
}

The problem here is that a page depends on the book. Therefore, the page cannot outlive the book. No book, no pages. The same apply to references: you can't have a reference outliving the book existance. So, you must express the lifetime of the page according to the book's one.

struct Page(&str);
struct Book {
  name: &str,  
  pages: [Pages], 
}

fn pass_to_reader(book: &'book Book) -> &'book Page { // we introduce the lifetime 'book here
  //read book
  //return ref on a specific page
  &book.pages[50]
}

fn main() {
  let mut pages = [Page("1"), ..., Page("100")]; // I ellisped the page 2 to 99... I'm not gonna write it all
  let mut book = Book { name: "Clean code", pages: pages};
  let page = pass_to_reader(&book);
  book.name = "The Tomb, a Lovecraft story"; //this will work as main has kept the ownership of the book.
  println!("{}", page.0);
}

To express the lifetime here, we use the notation ' followed by the name of the lifetime.
I may express here a crucial point, LIFETIMES ARE HARD TO DEAL WITH, so try to not use them to often. They are a powerful tool, and great power implies great responsabilities.

That's all for today, but be aware we will come back to this and dig deeper into it.
See you soon for another post about the wonderful world of Rust.

-- Mathieu

Koda: the year of the Tanuki

mnivoliez — Sun, 11 Feb 2018 10:52:07 +0000

Originally posted on my blog

Hello everyone! I am sorry for the delay, but the begining of the year was kind of a rush!
You mays have noticed some change on the site, including its name.

But the main main topic here will be "Koda, Kiyomori’s Guardian !".

"Ok, but what is it?"

"Kiyomori’s Guardian !" is a game where you control Koda the Tanuki (a forest spirit), who has to fight the corruption of his home, the forest of Kiyomori. It's a 3D plateformer realized with Unity.
We are a team of 15 people including graphist, game designer and programmers. We make it in the scope of a school project and we aim to present it at the Gamagora GameShow which is organized by our school.

I am the blond dancing one in the middle

We got to develop it until end of March and there is a metric tonne of task to carry out. I believe we are motivate enough to carry them out.
Feel free to visit our page on Facebook or our Twitter.

In a few words, stay tuned I shall speak about it again soon.
In the mean time, do not hesitate to ask about the project, I cannot promise to answer to everything but I will do my best.

--Mathieu

Getting started with Rust: Function and struct

mnivoliez — Wed, 06 Dec 2017 11:11:10 +0000

Originally posted on my blog

Hello everyone! Today we continue on our rust serie, we are going to talk about function and struct.

"Seems like a lot? Are we really going to cover all this?"

Yes and yes.

In order to do all that, we are going to need a variable, let's define that:

// We want to buy a fallout boy, so lets define a number of caps.
let caps = 5;

We just define a variable caps of value 5.

"Wait a minute! In the previous post, didn't you said that rust was a strongly typed language?"

I did, and it's true. Let me explain you the beautiful world of type inference!
At compile time, the rust compiler will try to guess the type of caps from its use (assignation or operation).
I said try because, sometimes, the rust compiler will not succeded. For example, if the using of caps not allow to define its type.
The type inference is here to avoid writting types when it can easily be guessed.
You still can define type with this syntax:

let caps: usize /* type define here */ = 5;

That said, a variable can be shadowed. Imagine that you got the number of caps in the form of a string, it makes senses to still call it caps. That's what shadowing is about.
Let me show you:

let caps = "five";
let caps = get_number_from_string(caps); // caps is now 5

Last but not least, the variable created before are immutable by default. Meaning you can't change them after declaring them. To do so, you have to explicitly tell it to the compiler:

let mut caps;
caps = 5;

In the case of shadowing, the variabke itself is not the same. We destruct it and recreate a new one. Sort of.

It may not be intuitive yet, but through practice, it will.

"Ok, but what about this get_number_from_string thing?"

Excellent transition, it's almost like if I was writting your line.
get_number_from_string is a function. Let see how we can define it:

fn get_number_from_string( num: &'static str ) -> usize {...}

"HOLD ON!!!! WHAT IS THIS?????"

Ok, lets cut this. fn is the key word to indicate that we are declaring a function. get_number_from_string is the name of the function, num: &'static str is the parameter we pass to the function, in this case, a reference to a string slice. We get back to it. Then we got -> usize which indicate that we return something of type usize. And finaly the body of the function.
To make it simpler, get the habits to read code outloud: the function get_number_from_string takes a number in the form of string and return an unsigned int value.
I strongly think that code should be readable as a good story should.
Functions are used to divided your code into unit that you can understand.

I could speak for eternity about function but you'll have to practice to understand it.

So now lets talk about struct.

"Struct, is it a shortname for strucutre?"

You are right. And guess what we use tructure for?

"We use it to... Hold things and give something a shape we can relie on?"

Right. And thats exactly what we are doing with struct.

You remember the caps variable earlier? It's this now, feel old yet?

struct CapsPurse {
  caps: usize // unsigned int is all we need. We can't have a negative value of caps.
}

//lets implements some functionalities to it.

impl CapsPurse {
  pub fn new() -> CapsPurse {
    CapsPurse { caps: 0 }
  }

  // we want to add and remove caps to it.
  pub fn add_caps(&mut self, amount: usize) {
    self.caps += amount; 
  }

  pub fn remove_caps(&mut self, amount: usize) {
    if amount <= self.caps {
      self.caps -= amount;
    }
  }
}

So lets recaps what happened here.
First, we define a purse to hold our caps. We define a method to create the purse, we define methods to add or remove caps from it.
As before, read out loud the method signature, it should clearly indicate what it does.
Eventually, you'll encounter two unknowned elements: pub and self. pub tell to the compiler that this method can be seen from the outside of the struct. To explain correctly this concept, let us use our body to do so. Our arms are public, our face too. Everybody can sees them and, in a certain limit, touch it. On the other side, your genitals are private. You keep them from outside world in your pants. Only you can touch and sees them. Of course, there are exception in your life and for you attributes, but not in the code.
So pub means that it's like an arm and when it's not here, it's like genitals: private.
The other symbol, self, is refering to the structure you are calling the method on.
Currently I do not see how to explain the self concept differently.

"Ok, ... Can I have a coffee with that?"

Agreed. This is not a simple matter. But hold on, the difficult part lies ahead.
We will continue this later as this post is long enough like this.

I tried to make this article the more accurate and understandable as possible. If any mistake or inexactitude exist, please leave a comment. I'll be glad to correct it.
Same goes if you have some advice on how I should explain things.

See you for another episode next time.

--Mathieu

Mistakes are needed!

mnivoliez — Fri, 15 Sep 2017 09:17:24 +0000

Originally posted on my blog.

Hello, today we are going to speak about mistakes, why they are needed and how to approach it.
‘Are you going to make us feel bad?’

Not at all. Quite the opposite in fact.

We all endeavour for the better in our project. We want to wipe out mistakes, we want to make it as perfect as it is possible to. And often, we forgot one simple rule. Mistake is fuel to creation. Some of you may follow the YouTube channel FunFunFunction animated by @MPJ. In a relatively new video, he spoke about how he should have left duplication in his code to let a pattern emerge. As he said himself, duplication is bad and should be avoided. But any mistake should be taken care of in a reasonable way. Thus, it leads me to several points I would like to rise.
Mistakes there are and mistakes will always be.

Mistakes are bound to happen. You’re not a machine, and therefore, you are not perfect (hopefully, it would be boring). Denying it will only make mistakes less visible and difficult to manage.
Mistakes will make you better.

Sadly, we rarely learn from success. On the other end, failure teach us a lot. By making mistakes, you force yourself to find new ways to deal with a problem, you exercise your reflection over a difficulty.
‘So, what should we do?’

Here the crafty question. My best advice is to accept mistakes and set up an environment to able to deal with them. Testing is one way, review is another one, and there are many more. Also, lower your initial standard. Let me explain, many organisations require upfront conception, for example UML diagram before programming, and often, it doesn’t work. The goal is to make it perfect in one shot. To get something working at the first try. I assure you, it will most likely never happen, you will work with obsolete tool, you will lack some knowledge about something, a coworker will be less accurate, etc.

So, in four words, leave room for mistakes. They are your safeguard to creation. And to companies, learn not to reprove mistakes. A mistake should be an occasion to learn, not to punish. Of course, this should be adapted in function of the situation, but you got the idea.

That’s all I have to say for now. This article was quite difficult to write for me and I am not sure to have expressed my mind correctly. But, it’s close to my heart: I see so many people being mad about not making mistakes and being stuck by ‘flaws of a perfect design’ and I want to highlight this issue. If you have any comment, advice or stories about this, please tell them.

—Mathieu