First Week

David Clark

Published in

L2Code

9 min readApr 7, 2018

What I’ve already learned, and my intentions with Thinkful.

Listening: My Discover Weekly Playlist on Spotify
Drinking: Mexico Sicobi small-lot coffee roasted by me

Intentions

First off, I think it is important that I clearly define my goals and intentions with taking the Thinkful course.

To learn the fundamentals needed to succeed as a Software Engineer/Web Developer/What-Have-You in today’s workplace.
To obtain a position at a company — large or small — within a year’s time of my start date, by April 2, 2018.
To effectively double my income. This includes salary, bonus, perks/benefits, PTO accrual rate, work-from-home capabilities, etc. Adding all of those up, the total valuation would have to come out to at least $80,000.

How will I do this? I’ve already shown you my calendar and my plan, so give that a read!

I have gone over the basics and somewhat more advanced lessons on HTML and CSS countless times in my year of at-home learning. Before starting Thinkful, I was dreading another set of lessons that felt like a waste of time where I didn’t learn anything new.

To my great surprise, I’ve already learned quite a bit just in the first few lessons with Thinkful!

Semantic HTML

We’ve all heard the term semantic if we’ve been part of the developer community for any significant amount of time. But how many of us truly know what semantic means?

se·man·tic
/səˈman(t)ik/
adjective
relating to meaning in language or logic.

So what does that mean? In the developer community, this means creating something logically and legibly. This has the effect of being more readable, easier for others to jump in on your code and be able to understand what’s going in, and using HTML in a way that it was intended.

The most obvious case of semantics would be that of indentation. One that many newcomers overlook is the appropriate use of theh1-h6 tags. It is accepted that the h1 tag should be used only once per web page. On a Medium article, that would be the title of the post. Despite being able to enter more h1 in a Medium article, you should avoid doing so, and use the smaller ‘T’, indicating Medium’s equivalent of an h2. Along the same lines, one should also avoid styling the h1-h6 tags too much, so as to avoid browser compatibility issues, among other things.

Semantic HTML also refers to the proper placement and labeling of things, such <title>, <header>, <section>, etc.

Thinkful Exercise: Semantic HTML

Beyond strictly semantics, I also learned some other things I hadn’t learned before, such as properly embedding videos with or without controls, autoplay, repeat, etc.

CSS

CSS gets all the glory. Understandably, too. It’s easy to get started with CSS, can become more challenging when you want to do more with it, and is a powerful and ever-growing tool in styling your pages.

In these lessons, I learned how to calculate the measurements for an element. I can’t believe I’d never learned this in the past with the innumerable hours I’d spent learning from other sources.

To calculate an element’s dimensions, we take width + 2x padding + 2x border + 2x margin. The 2x refers to there being two sides of those attributes. So, if we were targeting margin-left we would not multiply that by 2.

Let’s say we have the following:

.foo {
  width: 200px;
  height: 100px;
  padding: 10px;
  border: 1px solid green;
  margin: 30px;
}

To find its width, we: 200 + 20 + 2 + 60, for a total of 282px. This can be confusing, but is the preferred method. There is a way around this, however. We can use the box-sizingproperty, and set it to border-box, as so:

* {
    box-sizing: border-box;
}

This will allow us to use explicit sizing for all elements (the * targets everything). So whatever sizes we set will be the total size. For our foo class above, we would have a total dimension of 200x100.

Check it:

Pretty valuable information that I hadn’t learned from other resources, and explains why I had some issues styling things in the past.

Accessibility

Accessibility is one of those things that so few of us think about, because it doesn’t directly effect most of us. It’s the same thought process that leads to websites not working on some browsers, or an element not displaying properly on in a specific browser or on Android vs iOS. That, however, is more about cross-compatibility than Accessibility, but it is a similar thought process.

The lesson started the Accessibility talks back when it had us put an image inline with the HTML, utilizing the alt="" attribute. If you’re unaware, alt="" is used to give a description to an image, typically used by screen readers. For example, this image

might be written as:

<img src=”https://images.unsplash.com/photo-1458046913496-b049204810ac?ixlib=rb-0.3.5&ixid=eyJhcHBfaWQiOjEyMDd9&s=cefb4fdd42c173623b0a4dce70ab0ba2&auto=format&fit=crop&w=200&q=80" alt=”close up photo of a kitten’s face in black and white”>

Unfortunately, as users of Medium, we don’t have this option. We should wonder, then, what Medium does for Accessibility. Actually, not a lot. As a platform built with mass-reach in mind, Medium has built a platform where Accessibility is effectively null and void. In fact, if you Google search “medium.com accessbility”, you’ll get mostly blog posts such as the one I’m writing. But you’ll also get several posts that show the weaknesses of Medium.com when it comes to Accessibility.

Beyond the alt="" for inline images, Thinkful also teaches us about Accessibility quite a bit right out of the gate. More than I’ve learned over the past year at home.

Meyer Reset
The Meyer Reset is a super simple way of getting started with at least some adherence to Accessibility guidelines. You can read more about it here. I’m going to try to form the habit of including this in all of my future projects.

a11y
Speaking of guidelines, the developer community calls Accessibility, a11y. On the a11y website, you’ll find a super handy checklist. This will definitely make it easier for me to incorporate these standards into my projects.

It’s important to keep in mind that those most effected by good or bad HTML, are those using Assistive Technologies. Over 285 million people worldwide are visually-impaired.

Screen readers allow a user to not only hear what is on the page, but also navigate it. Using ARIA (Accessible Rich Internet Applications) standards makes this possible. One main example of using ARIA standards, is the use of the role="" attribute. This tells the screen reader what to do with this element. For example, role="banner" should be used on the header, while role="navigation" should be used on — you guessed it! — the navbar. The MDN has a great page on this.

For this lesson, we refactored our repl.it from before, in order to make it more a11y-friendly.

Doing all of this made me realize…

I am actually part of this visually-impaired population. I never think of myself in this regard, but with one eye being 20/400 and the other 20/60 (corrected to 20/150 and 20/15, respectively), I am legally blind in one eye, have a corrected lenses requirement for my license, and have a surgical implant in that bad eye to go along with a traumatic event when I was five years-old. If anything were to happen to my good eye, I would easily fall into a much more severe case of needing Assistive Technologies. I had this realization while playing with Apple’s VoiceOver utility. I closed my good eye and tried to comprehend a web page. I quickly discovered that I was unable to get VoiceOver to properly utilize language codes. It would only read in English. What should happen, is that when any element with, and any child of the element with lang="fr", should then be read in French (or whatever language is assigned). This should work even when the language is only applied to, say, a quote.

I tried it using a blank page, and punching in the example provided by Thinkful.

<blockquote lang="fr">
  <p>Tout arrive en France.</p>
</blockquote>
<p>
  <cite lang="fr">François de La Rochefoucauld</cite>
</p>

In this case, it should read Tout arrive en France. in a French accent, as shown here.

I was unable to fix this issue, mostly because I wanted to continue with the lessons, and because quick Google searches didn’t turn anything up.

How can we embed Accessibility into our daily programming?
This is a question that I don’t have an answer to. While there are lots of resources out there telling you how to code with Accessibility in mind, I have yet to find anything that will do it for you. Many of us are familiar with Auto Prefixer for ensuring browser cross-compatibility, and CSS Minifier for, well, minifying our CSS. But I’ve yet to find something that will parse our code and add a11y best practices. I have thus added this to my Projects To-Do list.

I’m not sure if it’s possible, but anything is impossible until it’s not…

Taking Notes

Note-taking is something I’ve gotten good at since I started learning over a year ago. Finding the right way to do so was a bit of a pain, however.

At first, I started taking analog notes, using my trust pencil and a dot-grid notebook. I quickly realized how expensive this would get, however, and that I cannot search my notebook. Bummer!

So then I moved over to Apple’s Notes app, which I love and use daily for work. Unfortunately, Notes doesn’t handle code well or handle links intuitively. I went over to Evernote, because it’s the only thing I’d ever heard of other than Notes. This worked well for some time, until I realized I was spending too much time on formatting and trying to find my way around the UI (even after several months).

Enter Bear.
Bear is an app focused on making note-taking and writing intuitive and minimal at the same time. I friggin love Bear. Immediately, Bear was easy to use and super intuitive.

When pasting a link, Bear immediately formats it using Markdown.

You can see above that Bear formats it in Markdown, but also displays it in a very attractive way. Immediately, I know that this is a link. I can click it and it goes there. Not only that, but when pasting it, all this formatting is magically done for you.

Then there’s the way Bear handles code. Very similarly to other note-taking apps, you can simply type a ` and your code followed by a closing ` to get inline code. You can also easily type three ` to get a codeblock. There’s also the proper syntax highlighting by typing what language is being used in the codeblock.

Because I’m using this a lot in my note-taking, I had to create a shortcut, as it wasn’t inherit within Bear. To do so, simply navigate to System Preferences > Keyboards > Shortcuts > App Shortcuts

And now, anytime I type shift+cmd+v, I’ll be pasting a code snippet into a codeblock with syntax awareness!

Highly recommend it. I haven’t gotten the Pro version, but I may do so in the future to support the developers.

Chrome 65

Just a quick aside, as I was learning about Chrome 65 as well. This update brought several things to DevTools, but what I really took notice was the addition of the Accessibility panel. This panel allows you to see the Accessibility Tree, ARIA attributes, and its Computed Properties.

I most likely would not have realized this if not for the Chrome Extension, Discover DevTools Companion.

To summarize, I’m having fun! I’m exploring the suggested reading materials, and beyond! I’m actually learning. Thinkful has done such a good job at teaching me that I reported a typo in their curriculm where a CSS property was referred to as an attribute. Now, I may be wrong about this, but it was confusing either way.