Front to Back-ish

It’s been just over two weeks now learning to code. Many hours, wherever I find them, have been put to good use. The days/nights have been filled with HTML, CSS, SASS Bootstrap and now Ruby. I have been familiar with the concepts before, but as they say, you learn by doing.


Starting out with HTML and CSS, it has been getting used to the fundamentals and practicing good habits. Like creating classes and ultimately making your code more modular. If found myself leaping into mocking up a website only to find a lot of repetitions. DRY — Don’t Repeat Yourself. A little planning ahead can single out those elements which you may want to reuse, like a nav bar or a container for an article. When I found a class in CSS fully loaded with styles, it was time to pare it down and see where I could clean house.

Along with HTML there was the practiced use of semantic tags, like Section, Header, Aside, Article, etc. All of these make your code easier to group and easier to read. Most modern browsers support them. Take <article> for example. If you’re putting in something that essentially be republished, you group that in an <article> tag. Easy right? So much classier than your standard <div>. The key takeaway is if you want browsers and humans to more easily see the structure of your HTML, use semantic tags correctly.


The one pretty cool thing about writing CSS is the use of SASS. SASS is a preprocessor that lets you do some sweet things you can’t do with plain CSS. Variables are one example. These babies can be used bring some consistency across your projects. Say I have a common font I want to use across sites, I can create a variable like

$my-font: Helvetica, sans-serif;

and use it throughout my code. So next time I declare a font for my article class,

font-family: $my-font;

and voila! This can be handy when you store a lot of variables you want to bring into any .scss file your working on. Plus it can help deliver a consistent product to your audience. Nobody wants to be confused by thirty different navbar colors in a site. Another tool is nesting, where you can structure your CSS to flow more like your HTML.

.navbar-form {
  .form-group {
background-color: black;
  input {
font-size: 22px;

Then SASS does its magic and out comes the .css file…

.navbar-form .form-group {
background-color: black; }
.navbar-form input {
font-size: 22px; }

Another basic example but pretty handy, as long as you stick to the rule of NOT nesting more than four levels deep. Things can get messy at that point.

There’s also mixins, partials, inheritance and more. Check it out if you think you can put it to use.

Coupled with HTML and CSS was starting with Bootstrap. A good way to quickly get responsive sites up and running, so long as you don’t fight the baked in goodness. Bootstrap can be tough to play with when you try to fight the margins and padding. With classes for nav bars, forms, inputs, buttons and the like, you could quickly get things up and running without having to do too much CSS adjusting. That being said, since I’m still green around the edges, I found myself tweaking a lot of things, only to be frustrated. Revert back to ‘not fighting it’ and all was right with the world.

Transform it

There was one aside that I found to be a good solution to some layout issues I was facing. Sometimes you just want to move a specific element without screwing up all your other elements on the page. The way I found to work best was transform. If the parent of the element you’re moving has a relative position, you can try this:

.my-photo {
position: absolute;
transform: translate(20px, 20px);

Making it absolute plays nice with the other elements and makes life a bit easier.

On to Ruby

Now we’re at Ruby. This is where the dive into the back end starts. Let’s say I am still in the kids side of the pool with this one. Maybe still holding the railing.

So working with code in the past, gives me some background on conditional logic and controlling the flow of the code. With Ruby, it does truly make life easier so you can focus on coding and less on what syntax you forgot that will make your program implode. Once I picked up the basics through some online tutorials, I found the best practice was going through solving problems. Project Euler can be a good starting point if you’re looking for some easy to impossible problems to hash out, using our language of choice.

If there’s one thing I learned about solving these problems, is there are so many ways to get to the same result. Some more polished than others and I find my self finding more descriptive solutions. That’s what refactoring is for. Go back through and check for repetitions (DRY) or better ways to get to the solution. There were also times where that obvious solution was nowhere to be found in my book until after I researched the solution. Take this for example. I created short program that takes a word, references a dictionary and checks for the anagrams. After some Googling on regular expressions, I came up with this…

regex = /^(?!.*(.).*\1)[word]*$/
# ... some other stuff 
dictionary_array.each { |k|
if k.match(regex) && (k.length == word.length && k != word)
anagram_array << k
end }
puts anagram_array

So fantastic! It basically worked, but I still had some issues with passing a variable to the regex. But the “Aha!” moment came after I saw the most elegant logic to the problem…

word.chars.sort.join == w.chars.sort.join

That’s the stripped down version above, but come on, that was too easy! Lesson learned and something to keep in mind when reviewing your code to find a neater solution.

And for this week…

So today I am currently creating the game, Tower of Hanoi, with Ruby. Using inputs from the user I’ll be recreating this puzzle game using basic procedural structure, not using at classes just yet. Hope to share some of those insights next week.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.