Live On Purpose.

Blog

24. Let's Get Technical

codecode.jpg

In previous posts, I’ve attempted to make convoluted coding problems understandable to most people. This is because in general, I want my blog to be mostly-readable to most English-reading people, which means I tried to speak generally about learning new skills and changing career paths. But at the end of the day, I am studying software engineering, and not everyone has a background in that, so to talk about it, I'll have to get into the weeds a little bit once in a while. This is one of those times.

Bloc’s Software Engineering Track starts you off slow. It assumes that you have no coding experience other than some of the prep work the course has you do before you really start working through their curriculum, so you start with the fundamental concepts of coding. The first unit of the course, Ruby on Rails Back End development, was therefore focused on the basics. What’s a variable? What are strings, integers, booleans, loops, arrays, and hashes? How does model-view-controller (MVC) test-driven development work? What in the world is Rspec? What is Ruby, and what is Rails?

What I looked like pretty much every day when I started my coursework at Bloc (I have fewer laptop stickers, though).

What I looked like pretty much every day when I started my coursework at Bloc (I have fewer laptop stickers, though).

The Front End section focused on front end web development. Since all modern web browsers support JavaScript code out of the box, this meant I was learning JavaScript and some of the frameworks and libraries associated with it. There are dozens of these, like the super-popular jQuery library and AngularJS framework that I used to build Bloc Jams. There are more recent and obscure frameworks, like Meteor, which I have so far used to build the foundations of my personal project, Moneytracker. And there are many technologies that I have not yet been exposed to, like React or Express.

Because it’s so ubiquitous, JavaScript has a gigantic community. In fact, it’s the most popular language on GitHub (more than double the popularity of Java, the runner-up, which is closely followed by Python and Ruby, according to GitHub's 2016 statistics). So it was great learning about such an essential language in the programming world for this section.

The tricky thing for me was readjusting from JavaScript back to Ruby for the third unit, Software Engineering Principles, because Bloc’s course uses Ruby and some inspiration from Rails to teach me about algorithms and complexity, object-relation maps (ORM’s), and framework architecture.

The foundations of BlocWorks.

The foundations of BlocWorks.

I am now nearing the end of the third unit. It does not have any big personal projects at the end for me to show off like the first two units, but it is significantly harder coding, and in the end I wind up with a functional (if somewhat basic) Ruby framework and ORM that could theoretically replace Rails and ActiveRecord. I noticed today, while struggling through a framework architecture assignment question (“Support instance variables in your framework that can be called in a controller method and accessed by its respective view”) that in order to even solve that problem, I had to know how to do a bunch of little things that would have stumped me all on their own a year ago.

To develop BlocWorks (the Rails-like Ruby framework I am working on), Bloc has me not only building the framework, but also integrating the ORM I built earlier, BlocRecord, and building a web app that utilizes the two, BlocBooks (which will allow users to make their own personal “libraries” full of books they can track, a bit like a simpler version of Goodreads). So to attack this assignment question, I had to:

  1. build some Ruby controllers and Embedded Ruby views (files ending in .html.erb, which are basically HTML files that can compile Ruby code rather than JavaScript) for BlocBooks, passing some instance variables to them (like `@book`),
  2. make sure the controllers rendered the views in question by inheriting a `render` method from BlocWorks’ `Controller` class, which I tested using (Rack-test), and
  3. finally get to the part where I solve the problem, which I did by looping through all of the instance variables available to the controller method, and using the Ruby `instance_variable_get(instance_variable)` method to pull the values of each variable. In other words, once everything was set up properly, my solution was a modified `render` method for the BlocWorks controller:
def render(view, locals = {})
      klass = self.class.to_s
      klass.slice!("Controller")
      controller_dir = BlocWorks.snake_case(klass)

      filename = File.join("app", "views", controller_dir, "#{view}.html.erb")
      template = File.read(filename)

      self.instance_variables.each do |iv|
        locals[iv] = instance_variable_get(iv)
      end

      eruby = Erubis::Eruby.new(template)
      eruby.result(locals)
end

To someone who has been coding in Ruby for years, all of that may sound somewhat unremarkable for them to accomplish. Customizing a framework (or not even using a framework) is not all that out of the ordinary, even if building a framework from scratch might be.

But for me, partway through solving this assignment problem I was reminded, quite vividly, that I had come so, so far since starting with Bloc. A year ago today, I could not have even told you what a view or a controller was, let alone written a functioning one. And that was just a very small part of the problems I’m solving now.

I don’t say this with the intention of bragging–far from it. I still struggle with new coding concepts on a pretty regular basis at Bloc. But I am now at a point where I feel confident that I can find the answer if I don’t know it offhand, and I can say with some confidence that I can code in Ruby. Not bad for one year of bootcamping!

There is still a lot for me to learn, to be sure; there are plenty of coding concepts I don’t quite grasp, and an endless ocean of languages, frameworks, and libraries I have never used. No coder can do all of it, of course, but I am excited to be at a point now where I can write about code (without feeling out of place), develop full-fledged web applications, and start getting more involved in the development community.

Now I just need to take it full-time!

Dan Rice2 Comments