Ironhack Days 8 and 9

As you can guess, the journey into the deeper reaches of JavaScript continues without stops or breaks (well, aside from ten minutes every hour, just so you don't get screen fatigue).

Shortly before the lesson on Day 8, when I pre-prepared the labs - this time the context was a fight between soldier-types we needed to somehow conjure out of nothing - I encountered the first concept I was not familiar with. Something that hadn't been covered in the Odin Foundations (but, as I then later saw, in the first lessons of the Odin JavaScript course): the Class object creation template and the constructor method.

The theory in the lessons materials were straightforward enough - you create a template for an object including the spots available for certain parameters and what these parameters mean in the context of such an object - essentially, you write a mould for an object, so you don't have to bake it from scratch all the time. In that context, the constructor also made sense - with it, you determine which things go into your object.

Then, an example dealing with cats. And "extends" - something extends a class.

What I realized time and time again, in rapid succession and at every turn when coding: my brain needs prosaic English context. I can't just look at a line of code an be like "yeah sure that okay" - since I do 'hear' my thoughts out loud when I read (not really, but sort of), I do need a 'storyteller' in my mind. Basically, my mind runs on pseudocode and comments.

Class 2 extends Class 1 - that's nice and all, but I didn't fully get what that means until I expressed it as "Class 2 has or is an extension to Class 1" - like a plugin that does something on top of the original stuff. And that's exactly what it does - it can do all of the old stuff and some new on top. Or, it changes some of the old stuff, or does not use ALL of what the old class can do. Any extension or plugin can add or block or add some and block some. Makes perfect sense.

Then they super-stealthily snuck in the "super" keyword used as a superclass constructor - yeah, exactly. I was a bit confused as to how that worked- but only briefly. The theory was easy enough to grasp - by invoking the superclass constructor you can skip writing out the code which determines how parameters are used in an object if that had already been done in the original class. You basically just say "okay, we take over that that and that and then some of our new stuff here." All in the word 'super'.

As with all things, repetition makes better - I really don't like the expression 'practice makes perfect' because there's no such thing as perfection. Practice makes better, eventually, that much can always be said.

Repetition and practice don't necessarily have to be the same, but I design my repetition in a way that afterwards I will definitely have learned something. And that's why, at least right now, I am giving 110% in the labs, the exercises, anything optional is non-optional. So, I checked out the homework on Classes and OOP, and it had to do with designing a little fighting game (purely CLI) between Vikings and Saxons. I just LOVE it when there is a little backstory, a little lore for stuff. I have never bin a maths-person (or at least, not a maths-class person. For me, it always was history, languages and that kind of stuff. Which is why I need a story, ideally, to grasp a concept). I had Vikings fight Saxons and vice versa, and at the end of the lab I daresay I understood the whole Class and extends and thing.

Since the lessons that are actually passing on the labs always include at least half an hour to work on labs in pairs, I was able to talk to a classmate about the labs (since I had already done them with a head start.) That gave me the opportunity to explain what all of the Class-stuff meant, how to translate the code to English and back and what this actually is used for and is useful for - thus just giving me another learning opportunity. I just love it.

In the classes after that we basically repeated and repeated all of that - making up new games, creating different scenarios which then brought new questions to life, or brought the opportunity to just go more in depth or into different details. We got some more time to check things out, and so I sat there and designed a few "templates", I might call them - classes for a player, monsters, wizards, what have you. Come up with a spell! they said. What do I come up with? Acid Tears. I had that in my mind from somewhere as the "least helpful super power " (Family Guy or something), and I thought that'd make a great spell!

What other "great" super powers are there? Glad you asked.

Obviously the Acid Tears will subtract health points - but there's a 50/50 chance (cause I was lazy with the maths) that the spell will rebound and you melt your own face off. Like I said, I like the lore, and it makes coding easier for me if I have a little story.

acidTears(target) {
    let rnd = Math.floor(Math.random() * 2)
    console.log("The Boss will cast Acid Tears - there's a 50-50 chance he will hit himself")
    if(rnd !== 0) {
      target.hp -= 30
      console.log(`${target.title} was struck with Acid Tears and they are melting their face. ${target.title} loses 30 hp and now has ${target.hp} HP left`)
    } else { this.hp -= 30
    console.log(`The curse rebounded and the Boss is now melting their own face! He has ${this.hp} HP left!`)}
  }

Like I said - certainly not the most complex or complicated code, but with a little but of backstory it encompasses quite a few coding principles - and in a fun way!

The last day before the "winter break" was - aside from recounting some concepts of OOP -  a day for assessments - you know, these kinds of tests to show where you stand, how you grasped the curriculum's materials and such; basically everything that's wrong with a one-size-fits-all educational system. Except for that we have three teachers to 25 people, so I don't actually know what would happen if those assessments showed that you don't get it.

By which I mean to say that I definitely got it, the assessments were easy enough to understand, and after an initial nervousness that always comes with "test anxiety", I was able to complete them in a matter of minutes (and not the allotted hours). After that, we could do with our time as we please; I opted to spend the full time I had planned for the class (which goes from 10am to 5pm) on some code wars and either solved or almost solved one of them. Keeps you sharp - but in my case, it also let's me get rusty in other areas of coding, like DOM manipulation. But more on that later.

Winter break will be the only such break we will have during the rest of the bootcamp - if we had a break for every holiday in all of the countries we originate from, we would never have class, and I don't need to pay money for that. And, to be honest: I enjoy it way to much to not have class. Thankfully my partner and I made a good plan to make this work, and we are in a very privileged situation to not be completely overwhelmed but the extra workload (in fact, we both take on a lot of work voluntarily. Crazy, right?). So, what I'm saying is: I really like this class, I like that I can basically set my own pace and follow a strategy of learning as fast and as much as I can, and I can always fall back on human resources if I encounter a problem - namely, my class, the Slack channel and my instructors. Making a career of coding couldn't have a better kickstart, I think.

jmc

In this series of blog post I write about my experience at Ironhack bootcamp. The material is available to anybody and free to use on the internet - I do not work for Ironhack (I paid to participate in a bootcamp, so...). These posts are not supposed to be deep-dive anything, just reflect what I learned about various programming techniques. If anybody finds them while googling, cool. If anybody finds them helpful, even cooler! If nothing happens - also fine.