Coding

Why I Taught Ruby


Photo by Jonathan Simcoe on Unsplash

In my second year of teaching, I changed programming languages. I previously taught my introductory programming class in Java. I wrote up exactly why I thought that was a good idea. I was wrong.

With the change of language, the class’s content changed along with it. With Ruby, the class moved from basic programming concepts - variables, loops, conditionals - to teaching basic sorting, trees, encryption and random number generation. With Java, the class moved from those basics, but instead was intended to culmination in a OOP-driven standalone application. Again, that was wrong.

Here is why Ruby worked:

Platform Accessible

I said this about Java too, but with Ruby, I decided to leverage Repl.it instead of depending upon the students’ dealing with their own laptops to do development. The platform allowed them to program in class, save their work online, and send me assignments through the Repl.it system. Additionally I could use the same platform to provide code samples and give out assignments.

Theoretically I could have done this with Java as well, but with the focus on Java on being able to spin up real applications and work in a real IDE (Eclipse in my case), running it through Repl.it would have defeated this achievement as they couldn’t actually make a real JAR (at the time).

Compilation and typing are still there

How do you explain compilation - it converts english and symbols to machine instructions. And you have to usually type a command or push a button do this, like printing a document. Done. No need to see the little progress bar on the screen. 

Typing? Even with dynamic typing in Ruby, learning the language still requires the sense that variables are treated differently based upon whether they are a Hash, number, string or object. The lesson isn’t lost by having to explain what a double is.

With those easy topics dealt with verbally rather than struggling through syntax, I made lessons harder

While previously I praised the fact that students had to focus a little more with Java because of curly brackets, typing variables, and just the overhead of running a hello world program, that is a shitty check on student ability. It’s like telling music students that they have to tune the piano before they can play it.

Ruby is extremely easy to get started and has a relaxed transition when moving from basics to OOP. With this in mind, I was able to breeze past variables, conditionals, loops and functions so that we could eventually discuss more difficult topics.

OOP is generally pointless for students

I still covered OOP in my class, but it was more as a demonstration in how to properly uses classes. In this case, the lack of emphasis on OOP in Ruby (as compared to Java at least) and its syntactic focus on elegant short lines of code made me focus on how we could work with really interesting algorithms in a succinct bits of code.

Think about - is it more interesting for new students to see how a binary tree automatically sorts numbers in a few lines or have them build another damn Car class with Wheel objects?

Students new to programming should learn what’s possible out there and see it working, not how to build application stable code.

 

Overall, Ruby took my sights off of OOP and its clean syntax forced me to move past the minutia that students shouldn’t need to concerns themselves with. Instead, they were given the chance to see how much they could do with a few lines and a computer science mindset.

They can learn about doubles versus floats later if they like.

Get over frameworks.

Years ago I was looking for an answer to a pretty simple CMS question, I believe on WordPress, and not surprisingly, I found an answer on StackOverflow related to whatever random query question I had.

One of the comments stayed with me. In more or less words the user said - “I agree with this solution. Though I usually write my own CMS from project to project so I don’t have to mess with this stuff.

Aside from the useless vanity that this added to the conversation, I was and remain still pretty shocked at this response. 

Certainly on the surface, it’s a bit of trying to show off, but it unfortunately fails. At the initial time, I thought, in my inexperience, “Wow, I wonder how you would make a system like WordPress from scratch."

Today, I’m reminded of Joel Spolsky’s article - “Things you should never do, part one” - shaming folks who casually and often with pride throw out “old” code as if it had rusted. In the article, Spolsky observes that, yeah, learning someone else’s codebase is harder than birthing your own, but provided codebases, whether from a legacy project or from a package CMS framework, have one advantage - they’ve been tested and have loads of bug resistant lines in them.

While I was willing to admit pretty early on that it was a waste of my time to write link functions or SQL sanitizers, when it came to the front end I was pretty adamant that I was not only an expert, but my code was better than dealing with a front end framework whether in for JS or CSS.

Of course I used jQuery and CMS provided JS libraries, but I scoffed at Angular, Ember, and particularly Bootstrap. After all, I didn’t want a site like everyone else, and my service connections would be simpler if I didn’t have to write them around a controller and factory object.

Bullshit.

Now look - I love to learn how things work, to get to how a sorting or searching algorithm works, and just feel like I could maybe build something from scratch. I like to think I could butcher a pig if necessary from my years in the kitchen. 

But if you actually are trying to build something - an application with intent, meaning, and users - then there is absolutely no reason to waste your time writing an email validation function or creating your own binding system. If software is about expression, you aren’t expressing yourself. You’re repeating others.

Is there any shame in an architect using a plumber? Does he or she have to design all the pipes? Sure maybe in some cases - but I seriously doubt any architect is crafting their own nails. 

So using front end frameworks like Angular / Ember and Bootstrap as sounding boards let’s dispel a couple ideas (mainly my own) about using frameworks:

I’m cheating myself and not learning because I’m just putting together someone else’s stuff like Legos.

No. In fact the opposite, you are learning how to tackle the problem that your application theoretically solves. Ideally, this is the hard part and unique problem space that you and NO ONE ELSE has. 

Again, if you want to try and make Pac-Man from scratch to learn how a game engine works, by all means, but when you sit down to make your 8-bit art action clone, which is so unique, the thing that you need to focus on is delivering the product. No one is gonna pat you on the back because you wrote an engine from scratch if no one ever plays the game.

I have to undo a bunch of stuff and the framework just gets in my way.

No, just no. If you so chose to use the ‘btn btn-default’ from Bootstrap to style your <button> then you have about 10 CSS rules to override. Furthermore, nothing in the framework is going out of its way to make all buttons do this style. Even if you get an annoying rule like:

strong { font-weight:normal; }  // THIS IS REAL

Just override this. Likewise, you are welcome to not have the application owned by any controllers if you so chose. Even with a server-side framework, you can always plop users into the folder you need and work around routing if so be it. Wanna Drupal site with a Blog powered by Wordpress, and a help section run by Rails then a custom “About Me” page - you can do this.

Oh geeze, there’s always just another framework I’ll have to learn.

Yeah, no shit. That’s called technological progress. Sooner you get over this, the better. There’s a pile of languages to learn, but understand that most languages / frameworks / build tools and so on are related to others and are usually designed to solve a specific problem. They are a tool.

Maybe employers will plaster that you need to know every JS framework under the pale blue moon, but that’s hiring managers trying to cover their asses. You will use the framework that is most appropriate to your problem space, and knowledge in one will most likely support skill acquisition in another.

For example, I worked with Ember professionally for a little bit and ended up loving it. However, when I approached my next spec project, I chose Angular instead as it better integrated with Rails and had a slightly lighter touch than Ember in my opinion. 

What if I need to customize something?

Knock yourself out! You may need some wild form interaction such that Bootstrap isn’t going to cut it. Cool - just use its grid system. Or dont! Need some JS that doesn’t work well with JS frameworks’ Promise system or data binding? Not sure how that would happen - but yeah, go ahead.

One Small Caveat

With a lot of module development particularly with Drupal front end tools, I have seen a giant mess of code that was nearly impossible to undo to make work for my clients’ needs and I’ve had to do basic stuff like Slideshows consistently.

This mainly happens as a lot of modules are created with the following thought in mind: “Hey, I built this really specific tool for my company. Let me make the colors look like Garland, kill the logo and BOOM! open source.”

Totally fair, but where content entry and front end meet, symbiosis is necessary. Often this is what is missing - the front end is provided and then content entry is jammed into there like adding cocktails to a light salad lunch.

Overall

Get over it random guy from StackOverflow years ago - use the tools to save time and customize as you need, focusing on your problem / domain space more than your ability to craft something by hand.

Think about it - a custom car may look cool, but damn, I certainly don’t want to be in an accident in one. Use tested software to make your products survivable in the wild.  

I don't understand why you don't understand my Views

Drupal developers typically follow this pattern when they start to work with layout systems: nodes to blocks to maybe panels to Views. Now these are obviously intertwining and of course a lot of us jump into custom templates and Views-like modules that aggregate and filter content.

As a Drupal dev, looking at these elements the progression seems pretty obvious and is natural to content management. First you create content chunks, then you arrange more specialized content pieces, and finally you start creating lists and contextual filters of content.

Speaking with clients who are actually going to use your system, however, this progression to and use of Views isn’t as natural or intuitive.

For a lot of folks not in web development, pages of content are just that - individual documents that stand alone. They aren’t nodes, they definitely aren’t fields, and from there the concept of filtering nodes to access fields is a conversation that isn’t going to translate well between dev and non-dev. But particularly when using systems like Taxonomy or Nodequeue with Views, where curation is a focus, it’s critical that users understand the basic idea.

So what is the best way to get these ideas across?

Tech terms is obviously a non-starter. Referencing SQL or the index.php query system won’t help. Neither will the name “Views”. It’s just too general, and worse yet if a person has enough knowledge to understand what a “view” is within MVC, as it can be easily confused with templates.

Thus, keep terminology to “Lists” and “Filtered Lists” or whatever wording works best. 

The simplest way to explain Views from there is to explain that these lists are lists of pages that use their parts, and we can set filters to “go get” the pages we want and just get their “Title” for example.

Here again, saying “fields” and “content types” is not very helpful either. Likewise, when discussing filters, if you’re using Taxonomy, “label” or similar may work best since that’s more common in other SaaS platforms to do the same function.

From there, concepts like limit / count, pager and such are a little more familiar to most people involved who use the web.

The key point therefore is to step out of the Drupal lingo and start thinking in terms of what’s more common. If users reach the point where lingo becomes important, then it’s fine to switch over, but until then, communicating the key operational concepts is more vital than keeping things in Drupalesque.

 

Z-index growth

Above is the plotting of the growth of z-indices over time in a project in CSS. Earlier this week I was told that my QA team was discovering websites in our network that had z-indices of upwards of 90,000,000. Hence I have developed a hard observational rule about z-index:

The higher a extant z-index, the greater the increase in the z-index to override it. 

I have no reasoning for why this rule exists, perhaps it's ego or frustration to just be on top, but take some time and observe z-index in yours and other's projects and you'll find it to be true. Around 100, people will jump between 90 and 110, once you get to 500, you're in the realms of 50 increases, and past a 1000, you'll see serious gains. Finally, someone will just say fuck it and start placing 500+ gains. 

I've had the fortune of seeing good style guides, where the developers define actual layers to their application to ensure that items are properly scoped. The joys of a well designed application. Unfortunately, when dealing with CMS structures, embedded iframes and similar black box situations, "fuck it" becomes a definitive answer.

First Time with Chrome Extension API

This is not a tutorial article on the Chrome Extension API. There's plenty out there, so this is more a fun discussion of what I enjoyed about using the application framework. 

For those programmers or soon to be programmers - the Chrome Extension API is a JavaScript / HTML / CSS framework that allows the developer to build essentially websites within the Chrome browser, whether a full page app or pop-up box.

The JavaScript API allows the app to access Chrome-based features and information such as tabs, history, window content and notifications. Other services like accessibility, internationalization and cron-like tools are also available. With that understanding, let's look at what makes this a great framework more generally. 

Let's first start with the API docs, speaking of tutorials. Well, these are tutorials per se, however, I am thoroughly impressed with the accessibility and simplicity they demonstration regarind the extension framework. By the time I got to the fourth API group, I was already intuiting what would be present and what calls would be named, and violia, I find what I need immediately. For beginners, particularly I imagine if you a programming newbie, this is such a blessing. Sure, it'd be great to know how to write JS well beforehand, but even the bare minimum of knowing how event listeners work will get you a long way. 

Which brings me to my second and perhaps biggest gush about the API - it's trimmed down simplicity. I'm reminded of the antipattern I've seen in joking projects like Simple PHP Easy Plus when I see an API like this. This is exactly what developers want most of the time. For basic services, we don't need extreme complexity or minute controls. I just need a couple couple calls to say - do this ONE things at some point. It's refreshing on its own, and empowering, as I believe the really exciting part about extension / plugin services is the combination of services rather than the direct detailed manipulation of those services one at a time. 

While the API calls themselves are mostly what you might guess Chrome would have available, the background app is perhaps the best part. As the name implies, a simple background.js (or whatever name) is a script that runs continually based on event listeners regardless of the state of the front end of the plugin. I found this helpful for not only the listening events, but app bootstrapping on installation as well. 

Simply put - it's nice to be able to quickly spin something up.

I don't know how big or powerful the Chrome Extension market is. I see a lot of popular brands on there, but I'm not sure how much that was motivated by the marketplace being yet another marketplace EverNote and the like need to be in, or if these are really used heavily as plugins. With that in mind, I'd say it's a great place for developers to cut their teeth a little and get something out there to the world. 

On that note - I will soon have an extension in the store called BetterSpent. Check out the gitHub project and let me know if you want to contribute. 

My FPS Engine and Masters of Doom

I really thought there'd be more to it. But running through a quick raycasting coding demo (something new to me, but always wanted to know how it work), I was soon able, after a couple of duh bugs, to get a running Java application spitting out a random wall grouping. 

Reminiscent of my first FPS game I played, Wolfenstein 3D, and the same idea that powered the raycasting technology that's the cornerstone of the book Masters of Doom.

I had thought that doing the coding would provide some insight into the book - like loads of Pernot while reading A Farewell to Arms. In both cases, it doesn't really help. There's plenty of summaries out there in the world of this book, so I wont' waste time summarizing except to tell the uninitiated that it's a history of id Software and its rise and collapse under the watchful and egotistical eyes of John Romero and John Carmack. 

This isn't to disparage either thing. I had a great time and learned a lot about modeling vision within an FPS raycasting system that was not altogether evident just reading through the code (my own Ahaa's found in the commented code). The book itself is well-written and is an adventurous story. Particularly one of young people who have discovered something incredibly powerful and are not sure what to do with themselves. I'm sure I would have been even less mature and more vindictive at their age. While, I'm still obviously less intelligent. 

Consider this - I collect a lot of cookbooks, and there's a moment of discovery in making a recipe you never have or even in making a recipe that puts better flavor into what you already know. There's a connection there too, between the cookbook writer and yourself (except if you're watching Julie and Julia, that is bullshit!). However, in there is labor in that process. You have to earn the work, and, well, sacrifices must literally be made. 

One of my favorite books on computers is The Elements of Computing Systems. I loved discovering how a processor actually works, how memory gets used, and how to build an OS from scratch (yes, yes, start with the universe, ha ha). But I know in reading it that I'm at an elementary school level. It doesn't sap my enjoyment of learning, but I won't be there with the chef as in my cookbook example sharing the same thing. 

Likewise in coding a raycasting FPS engine, I am so far behind, even within the narrative of the book which covers the development of Quake, that while I love the learning, I don't feel empowered. True, I don't need to fuss around with OS/2 memory management anymore, but more importantly, I can make a game like it if I want to using Unity. However, with cooking you can't substitute - you need to learn the recipes, otherwise, you won't be able to cook like the chef ultimately. 

So does the same thing hold true for coding in the steps of the greats? Are we able to say, "Look, learn this, skip Unity for now, and then go ahead." ? Do we respect that type of thinking as coders anymore, particularly within game development?

 

Setting up Rails on Digital Ocean with Dploy.io

Lately, I've been having a good time with Dploy.io. I've also been enjoying Digital Ocean. Combining the two has caused a couple of problems when it came to Digital Ocean's one-click Rails VPS. Following Digital Ocean's tutorial on how to quickly setup a Rails application, I ran into a few details that weren't mentioned therein that I thought it would be best to share in case someone else has the trouble. 

Nothing that came up was really Dploy's problem, so most of these are on Digital Ocean, but there's a couple additional actions that are useful for updating a Digital Ocean Rails VPS.

Okay - now the problem that started it all: My site just didn't work and hung.

This was an out of the box, totally clean rails installation. I put together one controller to make sure I had routing functioning, but aside from that it was as fresh as it gets. Replacing the default Digital Ocean rails application with mine is where my problems began. Here's how I went about fixing it:

  1. You'll need to make sure you have a secrets.yml file and have generated a key for the production environment. My basic 'rails new' didn't do this on my desktop, but this was present in the default DO installation. You can generate a key using 'rake secret' if you like. In this case, I placed this file as a static file for dploy.io to override my local file so that the real key wasn't left in source control. 
  2. Your Gemfile needs to include 'mysql2' and 'unicorn' gems. I was having a little trouble locally with the former gem, and so I created a production gemfile that dploy.io also overwrote after pulling from git. Mysql2 was mentioned in the tutorial, but activating the unicorn gem was not.
  3. Production.log needs to be created with permissions 0666. This does require a unicorn restart. 
  4. As described in the tutorial, you'll also need to set the correct database credentials in your database.yml file. 
  5. Finally, I also added "service unicorn restart" and "RAILS_ENV=production rake db:reset" as post build commands. 

Not end-of-the-world type stuff, but the secrets and missing unicorn gem details were annoying, as was unicorn hanging on a missing production.log file. However, once it's all hooked up, I've got automated deployment, custom config files and hook events running after every commit, which sure does feel nice. 

Making Everything Public

This week I decide to open source all my software on my github account. It's not much, and it's not all there yet. Still cleaning up a few projects. Most of the projcts on there were an hour of goofing off or so more than anything serious, but they will be shortly.

I decided to do this for a couple reasons.

First, as I reviewed candidates at my company, I spent a fair amount of time critiquing their GitHub projects. This gives me an insight into their skill on a couple points - I can see how they code and I can see what they're into. But I felt it was a little unfair that I would also deny that accessibility for the candidates scrutinizing myself. What kind of coder is their future employer? What does he like to release?

Second is the issue of release. By putting software out into the world, you are actually committing to some level of imperative and quality. You start to look at your software differently knowing that other people could critique it, judge it, mock it, reuse it, whatever. 

Third, sharing is just a flat good habit to get into. Even if no one ever looks at your code, most likely the case in my situation, it's going to make it a little easier when you don't want to share code with people. You'll be less shy, you'll be more open, and you'll expect feedback regardless. 

Likewise, connected to most of the projects is a public Kanban board on Pivotal. This might be a bit of overkill, but it provides a further level of sharing and exposure to the world. Call me crazy, but someone might actually want to participate in one of my projects at some point, and to look over an organized board of all the issues, shows them you're on top of the state of the software and ready to share development. For candidates, applying to jobs, I'd just simply be super impressed if they did so since it mirrors a professional production environment. If they can run that and motivate themselves on their own, I'd have no trouble knowing they could do so at my company. 

 

IE11 Reader View

A couple weeks ago I wrote about a number of things in Internet Explorer 11 that I had to learn. Well, since then I've learned a couple more things. 

First off, in reader view, if you have the skip ahead featured enabled, Reader view will actually skip ahead for you and preload the pages in reader view as well. This can be a bit problematic as you may have multipage articles, but you may also have skip ahead to unrelated articles as well, which could be disorienting. But you may want both features implemented at the same time. 

Well, I tried a couple of different approaches to make this happen. 

First, I tried to hook into the event that fired when you pulled up reader view. While, IE11 has a bunch of events tied to pinning sites, I couldn't find any events that fired when launching reader view. They might be out there, so if that's the case, I'd love to hear it. 

So I tried onfocus or onblur events, which weren't firing at the right time. I was hoping that I could follow these events and then remove the rel="next" attributes so the next page fo reader view wouldn't load. I noticed even on sites like MSN that reader view actually removed the ability to swipe ahead anyhow.

Second, I looked around and found a Stack Overflow article that mentioned that <pre> tags prevented reader view, saying this was a bug. I disagree, I think this is intentional as it completely ruins the point of <pre>. Regardless, this led me to realize that if I had a <pre> tag,  I could prevent reader view from working when the reader looked ahead at the next page. Thus, I added a <pre> tag to every page. 

This doesn't break reader view if I remove the <pre> tag as the page loads using JS.

So now I have reader view for the page I'm on, but because the <pre> tag on every page I'm not on prevents reader view, I still get swipe ahead without getting look ahead reader view. 

 

Pages

Subscribe to Coding