Maria: Behavior, Strategy, Implementation, 3 weeks

[MMikhailova]

Learning Objectives

Priorities: 🥚, 🐣, 🐥, 🐔 (click to learn more)

There is a lot to learn in this repository. If you can't master all the material at once, that's expected! Anything you don't master now will always be waiting for you to review when you need it. These 4 emoji's will help you prioritize your study time and to measure your progress: - 🥚: Understanding this material is required, it covers the base skills you'll need to move on. You do not need to finish all of them but should feel comfortable that you could with enough time. - 🐣: You have started all of these exercises and feel you could complete them all if you just had more time. It may not be easy for you but with effort you can make it through. - 🐥: You have studied the examples and started some exercises if you had time. You should have a big-picture understanding of these concepts/skills, but may not be confident completing the exercises. - 🐔: These concepts or skills are not necessary but are related to this module. If you are finished with 🥚, 🐣 and 🐥 you can use the 🐔 exercises to push yourself without getting distracted from the module's main objectives. ---

1. Remix

Practice studying and remixing other people's solutions to coding challenges. Create your own solutions by mixing and matching pieces from other people's code.

• 🐣 Reconstructing: You can reconstruct a variety of solutions to the same challenge when they are presented as parsons problems.
• 🐣 Analyzing: You can analyze a function written at your level. This includes:
  • [x] Behavior: Write documentation, test cases and use cases to describe the function's behavior.
  • [x] Strategy: Describe the function's strategy using plain english.
  • [x] Implementation: List the language features in a function and explain how each one is used.
  • [x] Small Changes: You can think of 2+ changes to the function's implementation that would not change it's strategy.
• 🐣 Remixing You can analyze several solutions to the same challenge then ...
  • [x] Write: Your own solution by remixing the ones you studied.
  • [x] Explain: How the other solutions inspired yours; what ideas did you take from them? what ideas did you not take?
  • [x] Analyze: Complete a write-up your own solution as though someone else wrote it.

2. Write

• 🐣 Function Design:
  • [ ] Writing Tests: Given a working function, you can write passing test cases to describe it's behavior.
  • [ ] Writing Functions: You can design multiple solutions to the same code challenge, keeping notes about different experiments you tried along the way.
• [ ] 🐣 Generating Documentation: You can write a JSDoc comment for your solutions and run a script to generate markdown documentation.
• [ ] 🐣 Fuzz Testing: You write solutions that pass randomly generated test cases.
• 🐣 Test Driven Development: You can solve open-ended, ambiguous coding challenges at your level:
  • [ ] Reading Docs: You can understand what the function is supposed to do by reading it's JSDoc description.
  • [ ] Writing Tests: You can write test cases before there is a function to test.
  • [ ] Writing Functions: You can write one function that passes the test cases you have prepared (even if it's just 1 test case!).
  • [ ] Refactoring: You can improve your function's implementation without failing any test cases that were passing.
  • [ ] Iterative Development: You can repeat the TDD process until you are satisfied with your test cases and solution.
• [ ] 🐔 Code Golf: Write your solutions with the fewest characters possible! This won't help you write readable code, but it will make you think deeply about JS, your strategy and implementation.

3. Review

• 🐣 Continuous Integration: You can check your code's quality before pushing so your CI checks all pass.
  • [ ] Formatting
  • [ ] Linting
  • [ ] Testing
• [ ] 🐣 Code Review: You can use a checklist to give a thorough, positive and constructive review of your classmates' solutions.
• [ ] 🐔 Code Coverage: You can explain what code coverage is, why it's important, and can write unit tests with 100% code coverage.

---

[MMikhailova]

Week 1

I Need Help With:

What does new operator do? Are we going to learn about it throughout the HYF classes?

if (array1.length !== array2.length) throw new Error();

I would like to know more about exception and testing the specific type of exception thrown.

What went well?

Solution write-ups! I have written up three solutions for add-arrays and remove-exclamation-marks challenges.
Here are they: https://github.com/MMikhailova/solution-write-ups

I had fun writing tests and I refreshed my knowledge in markdown by filling README.md 😆

Writing tests helped me understand how function should work. I also added some checks to given solutions so as function behaviour doesn't change.

What went less well?

Expecting a function to throw an exception in Jest is still not fully clear for me.

[danielhalasz]

Expecting a function to throw an exception in Jest is still not fully clear for me.

yes, this is a bit tricky, as you need to wrap it into a function..

so instead of the usual: expect(solution([1, 2], [1, 2])).toEqual([2, 4]);

you have to have: expect(() => solution('jest is weird')).toThrowError();

[danielhalasz]

What does new operator do? Are we going to learn about it throughout the HYF classes?

it has to do with something in JS called a constructor..which in related to classes..that was used in JS before, but we will not cover it..you can take a peek if you want though here: https://www.w3schools.com/JsrEF/jsref_constructor_class.asp

[danielhalasz]

Here are they: https://github.com/MMikhailova/solution-write-ups

excellent work with the write-ups, was super happy to see your work! 🙂

[MMikhailova]

Thank you 😊

[MMikhailova]

Week 2

I Need Help With:

I keep working on the quizz where I am trying to apply whatever new I have learnt during the class about JS and practice HTML/CSS. Therefore I have a question, what is better to write more code in html and display it by changing property "display:block/none" or the better way is to write more code in JS and then display in inner html?

What went well?

First I have spent some time writing and rewriting tests to make them "smarter" and more logical. I have 445 tests combined by profession and base salary. My function finally passed all of them (Whooo!).

Second, I was curious to find the solution that would be more flexible. "if loop is the easiest one, but if you want add more employees in your data base, you have to add more code (more if's) and it gets huge.

So I finally found the solution that works for any employee in data base. I spent hours on it though...:cold_sweat:
I pushed my work here. I would be grateful for any feedback.

What went less well?

It is very difficult to return to html after being fully focused on JS. I really recommend to refresh your knowledge in HTML/CSS from time to time.

[danielhalasz]

I have 445 tests combined by profession and base salary. My function finally passed all of them (Whooo!).

💟

[danielhalasz]

So I finally found the solution that works for any employee in data base. I spent hours on it though...😰

wow, first of all, great effort!!! please give me some time to check it more deeply

[danielhalasz]

Therefore I have a question, what is better to write more code in html and display it by changing property "display:block/none" or the better way is to write more code in JS and then display in inner html?

it is a great question that is very hard to answer straight. are you referring to hard-coding the questions into the HTML versus the JS file? try to think about the life-cycle of the app. how often do you want to update it? who is going to update it, if necessary? which is the easiest way? personally, I would probably opt for using an external file to store the questions and the answers..and then import this file, where necessary. this way, the page loads fast and new data is loaded gradually when needed. of course, we have not really covered this yet, but potentially for now you can just use a data.js file and store everything there. later on, we will learn about formats such as JSON and YAML there are widespread in web apps.

[danielhalasz]

It is very difficult to return to html after being fully focused on JS.

I have to agree, I had a similar experience, but once you will write a few projects, HTML will become more natural and automatic..and then you will only have to struggle with CSS and JS ;)

[danielhalasz]

I pushed my work here.

on line 76 this looks funny, but is of course correct: ((exp) => workExperience <= exp) on line 78 you do not really need a break I think

[danielhalasz]

you could also look at Ali's solution: https://github.com/alihaidermalik20/docker-example-bsi/blob/master/doctor-example.test.js

[MMikhailova]

Week 3

I Need Help With:

I would like to know more about npm (node.js), JSON and YAML files, but to be honest I haven't spent time yet on studying this on my own, so, I believe, I just need to read, watch about it more. I'm practical person therefore it's more difficult for me to get concepts without exercising them.

What went well?

I have finished all exercises in "practice-code-review" and have written tests for them. Here are my PR's.

I feel confident about:

• 🐣 Function Design:
  • [X] Writing Tests: Given a working function, you can write passing test cases to describe it's behavior.
  • [X] Writing Functions: You can design multiple solutions to the same code challenge, keeping notes about different experiments you tried along the way.
• [X] 🐣 Generating Documentation: You can write a JSDoc comment for your solutions and run a script to generate markdown documentation.
• [X] 🐣 Fuzz Testing: You write solutions that pass randomly generated test cases.
• 🐣 Test Driven Development: You can solve open-ended, ambiguous coding challenges at your level:
  • [X] Reading Docs: You can understand what the function is supposed to do by reading it's JSDoc description.
  • [X] Writing Tests: You can write test cases before there is a function to test.
  • [X] Writing Functions: You can write one function that passes the test cases you have prepared (even if it's just 1 test case!).
  • [X] Refactoring: You can improve your function's implementation without failing any test cases that were passing.
  • [X] Iterative Development: You can repeat the TDD process until you are satisfied with your test cases and solution.

I am currently trying not only write a function that works but a smart on with fewer code that makes more sense. I noticed that writing tests first helps enable to write smarter code.

• [ ] 🐔 Code Golf: Write your solutions with the fewest characters possible! This won't help you write readable code, but it will make you think deeply about JS, your strategy and implementation.

What went less well?

Formatting wise, I am still figuring out how to avoid Prettier and VS code (or other formatting) conflicts.

[danielhalasz]

I would like to know more about npm (node.js), JSON and YAML files

We will learn a bit more about storing and accessing data in later modules and it is important to know these formats. Basically they are just two ways of storing and transferring data between functions, applications, databases.

A simple example of a JSON:

{
  "students": [
    {
      "id": 101,
      "name": "Rizwan Hasan",
      "age": 21,
      "department": "CSE",
      "sex": "Male",
      "paid": true,
      "cgpa": 2.13
    },
    {
      "id": 102,
      "name": "Faria Hasan",
      "age": 20,
      "department": "BBA",
      "sex": "Female",
      "paid": true,
      "cgpa": 3.56
    }
  ]
}

YAML is a newer standard, less wide-spread, often used for configuration files and for example internationalization files for multilanguage websites..and so on..

# This is a comment
title: This is some YAML
publisher: ConvertSimple Books
pages: 250
chapters: 21
time_to_read: 12 hours
descriptors:
  - fun
  - entertaining
  - exciting
contributors:
  author: Mark Templeton
  editor: Cindy Johnson

[danielhalasz]

Formatting wise, I am still figuring out how to avoid Prettier and VS code (or other formatting) conflicts.

what conflicts do you have between Prettier and VSCode?

[MMikhailova]

@danielhalasz To be precise it was the conflict between Prettier and "npm lint:js". See the example below:

According to npm lint:js:

error: '||' should be placed at the beginning of the line (operator-linebreak) at src/sort-numbers/sort-numbers.js:10:40:
   8 | export const sortNumbers = (arrayOfNumbers = []) => {
   9 |   if (
> 10 |     typeof arrayOfNumbers !== 'object' ||
     |                                        ^
  11 |     arrayOfNumbers.includes(NaN) ||
  12 |     arrayOfNumbers.includes(Infinity) ||
  13 |     arrayOfNumbers.includes(-Infinity)

When Prettier put this expression in one line. So I had to disable eslint for this line to solve the conflict, but I suppose it makes more sense to configure npm script accordingly.

[danielhalasz]

hm..looking a bit more into this it seems like there is a discussion ongoing for YEARS on how Prettier should deal with trailing operators..and while most devs seem to prefer to use operators at the beginning of the line (like ESLint), Prettier does not have this option..

as someone wrote there:

// Please do this - read vertically down :)
const foo = barValue
            && checkBazValue()
            && qux.isTrue()

// Please stop doing this - scan entire line :(
const foo = barValue &&
            checkBazValue() &&
            qux.isTrue()

https://stackoverflow.com/questions/61952529/eslint-and-prettier-conflict-on-operator-linebreak-rule

sadly, there is no good solution to this..as it can not be disabled in Prettier..