I passed my Rails Assessment today! It went well and there was only one thing I needed to follow up with after it was over. Now I’m just looking for the check mark on it to turn green!

The next few days are going to be LONG. However, they should be very productive and great networking. They’ll be long because they start EARLY (like be there at 7am early) and I still plan on coding at night once the kiddos go to bed. Music City Code will be a great experience. I found out today that I won’t have to man our Free Code Camp Nashville booth tomorrow which is cool. I’ll be able to just attend a couple sessions. I’m looking forward to Extreme TDD (Test-Driven Development):

Unit testing is one of those things that we all agree is good but, because of the learning curve, unit testing is often put in the back seat or forgotten. As a result, we lose out on the positive benefits that come from unit tests and the process that they lead us through. This workshop is designed to help you destroy the learning curve and become proficient in not only unit testing, but also mocking and test-first development (or TDD). This session might not be able to transform you into a seasoned expert, but it WILL help you get past the common speed bumps and roadblocks that discourage many well-meaning developers. Bring your laptop and your favorite code editor and get ready to go “extreme!”

As I know testing is something that a lot of employers are looking for. Being able to write some unit tests for my projects is going to look good. I did a few for my Rails project but want to do more in the future. I’ve just been shunning learning the DSL of testing libraries. I figure a 4-hour crash course is going to push me past the initial hurdles and get me to proficient enough to find answers to things I do not know past the basics.

I’ve also mapped out the sessions I want to go to for the rest of the conference although I may end up sitting at our table for a large chunk of that time. I’m quite okay with that though. This will allow me time to speak at length with people and/or work on school/read if not busy.

Okay, it’s pushing midnight and I should leave tomorrow by 6:15am to arrive by 7:30ish.

Time spent today: 3:34
Time spent total: 359:00
Lessons completed today: 2
Lessons completed total: 581

I just spent way too much time looking into Mocha, Chai, Jasmine, and I can’t remember what other test libraries. Trying to solve this testing problem we have over in Javscripting that I help maintain. I like the fact that there’s this problem that needs to be solved and it’s something I can learn from. Now I’m trying to figure out how to test against a file that has no functions in it. I think this is simpler than I’m making it out to be. I need to just create a simple testing environment and start playing around. I think that’s what I’ll do.

I’m 5 lessons/labs away from finishing Advanced JavaScript and moving into Rails and JavaScript. I’m officially 77% of the way there! Now bedtime as it’s late enough as it is.

Time spent today: 2:22
Time spent total: 355:27
Lessons completed today: 6
Lessons completed total: 579

So I had a bunch of stuff to say, okay not really, and then I checked my Dashboard on Learn and saw the beautiful sight that my Graduation Dashboard has appeared! That means I’m past 75% done and in the final stretch. Being 75% done in <3 months has me on track to be done before the end of June! I’m stoked.

So something that I had been struggling with is how Ruby is a class-based object-oriented language and JavaScript is a prototype-based object-oriented language. This always confused me. The whole prototype thing in general always confused me in JS. Until now:

There are two primary types of object-oriented (OO) languages: class-based and prototype-based.

In a class-based OO language, such as Ruby, Java, C#, and C++, we must first design the Class, or blueprint, of an object, and then create objects from that blueprint in order to use them.

Imagine a set of instructions from IKEA as the Class, and your assembled Fthugënbøller bookcase as the object.

JavaScript uses prototypal OO. Instead of creating a nonfunctional class definition, we actually create the object, which is then used as a prototype to create other objects.

In the real world, this would be like taking a bunch of laminated wood and assembling a Fthügënbøller, and then using that as your guide, or prototype, for creating other Fthügënbøllers, and Fthügënbøller-like objects.

That real-world analogy did it for me. Of course, then I learned about ES6 JS Classes. However, knowing how something can be built multiple ways is a strong skill to have. Although, I have to admit, after doing a lab testing prototypal inheritance works and is accomplished by using Object.create() among other things. Then doing a lab testing the use of classes. I much prefer classes haha.

I also ran into an issue tonight doing that prototype lab:

function Point (x, y) {
  this.x = x
  this.y = y
Point.prototype.toString = () => {
  return `(${this.x}, ${this.y})`

// In the terminal
> var p = new Point(2,3)
> p
Point { x: 2, y: 3 }
> p.toString()
'(undefined, undefined)'

I couldn’t figure out why this was returning undefined. I finally just removed the arrow function and used a normal(?) function and it worked:

Point.prototype.toString = function () {
  return `(${this.x}, ${this.y})`

This was interesting to me and I need to dive deeper into why this happened. As I read You Don’t Know JS, I find myself no happy with figuring these problems out and moving on. I want to understand the why behind them. Although, if anybody out there knows feel free to fill me in.

Time spent today: 8:45
Time spent total: 353:05
Lessons completed today: 14
Lessons completed total: 573

Yes, I just made that joke. However, I’m in the middle of a Handlebars.js lab so I think it’s fitting.

Handlebars uses the curly brace as a delimiter because if you turn it sideways it looks like a mustache, and Handlebars.js is an extension of the Mustache template language.

Today was a lot of HTML, CSS, and Templating so no new notes on anything. I find that HTML & CSS stick pretty well and until I’m actually using a templating language in a project I won’t take notes just yet. The docs are typically good enough for quick searches through. Like the lab where I had to use Basscss it was easy enough to just use “Find” on the website to get my code to do what I needed.

Spent most of the afternoon at my neighbor’s house for their daughter’s birthday. She’s turning 3 just like my little one will in less than a month.

Time spent today: 5:10
Time spent total: 344:20
Lessons completed today: 13
Lessons completed total: 559

Zero lessons or labs done yesterday. Had an impromptu dinner at the in-laws and when my wife and I got home we decided to spend some time with the neighbors talking. That turned into a great evening or wine, scotch, and conversation until 4am. I did, however, read You Don’t Know JS in the car on the way to and from dinner so I did some learning. I got through the first book, Up & Going, and was able to start the second book, Scope & Closures. If I can keep up the consistent reading I think this book series will really help level up my JS knowledge as I learn and implement things in my learning alongside the book’s teaching. Like, I did Closure labs today and I was reading about Closures in the book. I also decided to read this book series because no matter language I end up being employed to do web development in I’m going to encounter JavaScript. So it makes sense to understand it very well.

I’ve found that I’m moving through JS at a good pace. Things are clicking and I’m not getting too stuck in any one place. We’ll see what happens the first time the “training wheels” come off though. I specifically took notes on two things today.

Arrow Functions

// Arrow Functions
// With multiple arguments
let arrowFunction = (arg1, arg2) => {
  // Do Something
// With one argument
let arrowFunction = oneArg => {
  // Do Something

// All arrow functions are anonymous
function iHaveAName () {}
> iHaveAName.name
> 'iHaveAName'
// versus
> (() => {}).name
> ''

Object Destructuring

let obj = {a:1, b:2, c:3}
let {a, b, c} = obj

I’m still not 100% on Object Destructuring but that’s why I added it to my notes. It makes sense why it was implemented and seems kind of like mass assignment in Ruby. However, I’m trying not to relate things too much between Ruby and JS because they fundamentally work differently. It’ll just end up causing me confusion in the end.

I’m happy with my progress today. Hopefully, I can make it through another 14 tomorrow and be in a good position to hit the 75% mark before the end of the month. We’ll see.

Time spent today: 8:10
Time spent total: 339:10
Lessons completed today: 14
Lessons completed total: 546

The DOM. Forgot to throw in the main info about the DOM I learned yesterday in last night’s blog:

  • The Document Object Model is a representation of the current view of the browser, and can be manipulated without reloading a page.
  • The HTML is the text in a file first used to display the page.

With Javascript we can (1) view a current representation of our Document Object Model. With Javascript we can also (2) select specific portions of the DOM, and manipulate them, which changes what shows up in a browser window.

This small portion of text cleared up what the DOM is after a long time of not truly knowing.

I didn’t get as much done tonight as I had wanted. I started late and didn’t stay focused so it’s all my fault. I spent too much time messing with how my terminal/editor looks. I decided on using zsh with Oh My Zsh and a Powerlevel9k theme. It’s pretty sweet. All sourced from this post I saw on Reddit. Now that I have a solid config at some point I’m sure I’ll mess with it more to make it more custom to me. However, I’ve already done a few minor things like changing the ArchLinux logo and text to Ubuntu. It’s pretty cool though. I can see what branch I’m working on if there are uncommitted files if there are committed files waiting to be pushed, the time, the battery left on my laptop. I can extend these features more too, which I’m sure I’ll do someday.

I also spent a bunch of time implementing “proper” linting for JavaScript. There are so many style guides out there I struggled figuring out what to set up and use. I ended up deciding on an ESLint implementation using JavaScript Standard Style. Turns out WebStorm supports Standard by default these days so it was easy to set up. However, I had to get it installed which was easy. The hard part was finding where the node_modules folder for global installs was on my computer. I ended up running across it as a comment on a Stack Overflow post.

I also got my invite to Cypress today. I have it installed but haven’t done any work with it yet. I think I’ll use it to set up tests for my Rails Portfolio Project. Check it out. It’s definitely slick. I also started reading You Don’t Know JS as I’ve been looking for something to do outside of my computer screen to continue my knowledge expansion. Knowing that I’ll encounter JavaScript no matter what language I end up working in makes me feel like diving deeper into my knowledge of it will help no matter what. I really do enjoy Ruby but I might end up not working in it so yeah.

Time spent today: 1:59
Time spent total: 331:00
Lessons completed today: 3
Lessons completed total: 532

Today I spent 30 mins pairing with one of the Learn instructors trying to work through some issues my Rails portfolio project has. Something I found out is that the project requirement to use a custom attribute writer instead of has_nested_attributes actually removes some functionality from the final app. Because of this lack of Rails magic, one of my problems is harder to fix than expected. The other one is just a more simple if...else statement.

JavaScript is coming along and I’m happy it’s clicking more and more each day. It was definitely frustrating to have a rather solid grasp on a workflow, resources, and a knowledge base and then go back to almost nothing. I haven’t dove back into the Mozilla Developer Network (MDN for short) docs but I know it’s coming soon.

Something that I ran across today in my IDE was a linting error from JSLint stating Missing "use strict" pragma on one of my functions. So, like a good dev, I Googled this (well DuckDuckGo’ed this). I came to a great post and discussion about this on Stack Overflow. My takeaways were that using 'use strict'; enforces things that JavaScript allows to happen or will throw silent errors for. So, it basically forces a person to write their code correctly. However, this can be dangerous in legacy code. A great answer contained this gem IMO:

Where should I use ‘use strict’;?

  • In my new JavaScript application: Absolutely! Strict mode can be used as a whistleblower when you are doing something stupid with your code.
  • In my existing JavaScript code: Probably not! If your existing JavaScript code has statements that are prohibited in strict-mode, the application will simply break. If you want strict mode, you should be prepared to debug and correct your existing code. This is why using 'use strict'; does not suddenly make your code better.

I plan to add 'use strict'; to the top of every new JavaScript file I work on. I see no reason not to at this point in time and it’ll only enforce me writing better code in the end.

What do you think about 'use strict';? Leave it in the comments for me.

I also found out tonight from my Free Code Camp Nashville Co-Organizer Dave that he scored us a table at Music City Code 2017 which is pretty sweet. Not sure what we’re going to do with our table just yet so if you have ideas please let me know!

Time spent today: 3:07
Time spent total: 329:01
Lessons completed today: 5
Lessons completed total: 529