What is DRY (in programming)?

what is dry blog banner nickang showing weed growing on white wall
Photo by Ben Neale on Unsplash

Ever heard someone tell you that your code is not “DRY”? What’s the deal with that? Are they saying that your code can hold a lot of water…?

Sorry for the bad joke. DRY is an acronym, and it stands for Do not Repeat Yourself. As far as I can tell so far in my short career as a software engineer, this is one of the most revered principles in writing software.

In this post, we’ll explore why it’s important to keep your code DRY and in general, how you can go about doing it.

Continue reading “What is DRY (in programming)?”

Algorithm time complexity and the Big O notation

bite size programming algorithm time complexity and big o notation banner
Photo by Lysander Yuen on Unsplash

Big O notation has attained superstar status among the other concepts of math because of programmers like to use it in discussions about algorithms (and for good reason). It’s a quick way to talk about algorithm time complexity.

While it’s a math concept that applies to various fields, programmers are probably one of the most frequent users of Big O. We use it as a shorthand to discuss how quickly and/or with how much memory an algorithm takes to go from start to finish.

Perhaps the part about Big O being most used by programmers is just my carpal-tunnel-visioned mind speaking, but nevertheless! It’s an important concept and here’s a post dedicated to understanding the Big O notation.

Continue reading “Algorithm time complexity and the Big O notation”

Encoding for programmers

red book with 8 bit bytes carved on the cover
Photo by Hope House Press on Unsplash

I’ve been running into Unicode and ASCII and related encoding/decoding issues recently at work. We had an email that didn’t get sent out and all I got was an error message that said that some character could not be encoded in ASCII as “ordinal out of range”. That set me back for many hours and I only think I’ve managed to fix it (by wrapping u” around every string in the affected module in Python).

Continue reading “Encoding for programmers”

You don’t know everything

By you I mean I. I’m ready to admit, I don’t know everything.

It’s an admission that doesn’t cause me to blush but makes me feel stronger. By acknowledging how little I know, I’m motivated to find out more about a topic.

With a few months of work as a software engineer under my belt now, I have a good sense of my standing among other software engineers in the field. Form a technical standpoint, I’m far from good. I mean on a scale of 1 to 10, with 1 being practically useless, I think I’m at 5 – not completely useless but still having a lot to learn.

Now that’s an admission you won’t see very often, especially if that person is looking to climb the professional ladder…

But I think it’s important and necessary to be truthful to yourself once in a while.

On most days you can “hustle” and pretend that you got your shit together and can do these amazing things. That brings with it numerous benefits, like better team morale, higher likelihood of having the person on the opposite end of a business transaction partially fooled, and an overall sense of self satisfaction. It’s good and it’s necessary, since we’re all imposters in some ways until we are not.

But I deeply believe that in the occasional moments when we are truthful to ourselves, we make the most progress, personally and professionally.

So allow me to admit that I’m not that good a software engineer yet. To be specific, based on my recent experiences at work, I know I need to work these specific areas:

  • Embracing a different language and framework from what I’m used to (Python and Django)
  • Being able to tell in at least half of all decision-making occasions whether Approach A or B is going to be a better decision down the road
  • Bridging the gap between my typing and thinking speeds so I can create features and fix bugs quicker (I think much slower than I can type at 105 WPM)

Now I have a list. Great, another list!

I’m being half sarcastic there. Only half.

I believe in lists and know a few good people who do too. Lists make concrete the floaty “I think”s, which in turn makes it possible for me to break through them.

With this list what I’m going to do is to break it down further into sub-lists. For example, I’ll make a list of things that answers this question: what’s stopping me from embracing Python and Django?

  • The syntax looks different from JavaScript
  • Resentment towards the fact that if we used NodeJS instead of Django on the project, I’d be able to code entirely in JavaScript (this is funny because I once lamented how difficult it is to set up a NodeJS server)
  • Not knowing enough to write code without having to cross- and double-check everything in the documentation and existing code

And then from there I’m going to come up with questions, this time as specific as possible, that would help me overcome this sub-list:

  • Why do you need to import so many basic features in Python? (I have a hunch for this answer, but knowing the philosophy of Python’s creators might offer insights into how I should be thinking about the language)
  • Why are Django controllers called views? That really confuses the shit out of me and I know I’m definitely not alone
  • What mental hacks can I use to convert my mind to thinking in Django’s terms?
  • Why do I need to deal with Serializers in Django when I don’t have to in a similar framework like Ruby on Rails?
  • What does class Meta: do in a Django model?
  • How exactly do you set up a REST API in Django REST Framework?
  • What’s the easiest way to pretty-print things in Terminal when working in Python and Django?

Man, the list is long!

But that’s how you know you know nothing. Jon Snow.

Perhaps it might be helpful to other software engineers looking for answers to these questions, so I intend to share my findings in another post. Enter your email in the box in the right panel to get notified to come read it when it’s out.

What it’s like building app features in 2017

First of all let me admit, I wasn’t there to witness what it was like to build web/mobile app features before 2016, since I only became a web developer last year.

That said, seeing that the open source movement really only picked up amazing momentum in the past couple of years, I can imagine that it was much harder to build full-fledged features from the ground up till as late as early 2010s. That difficulty is also probably exacerbated by the less nimble management practices of tech companies (agile wha-?) and the overall economics of hiring developers to build software.

But this is 2017, and I now have the vantage point of being a developer / software engineer that affords me some insights into what it’s like building app features now.

I’m writing this article on the same day that I created a pull request to submit my last two and a half weeks worth of work. The work was for a drag and drop email editor user interface, built mainly with ReactJS, and I’m really happy to complete my first major feature ever for a live product! Although I was a little overly optimistic and ended up delivering about half a week behind schedule…

Over the course of building this feature I’ve learned a few things about software development, some general and some more specific to current times. Some of the more interesting ones:

  • There are a lot of great open source software that anyone (companies and individuals) can use for free now
  • Using an open source library also means trusting the creators/maintainers enough to make our project dependent (reliant?) on theirs
  • Software developers have to be like surgeons when building features on top of an existing code base

More on the point about free, open source software available out there in 2017. In the process of building the email editor feature, I used three open source libraries that I think are really well made, and for which I’m incredibly appreciative of. QuillJS, react-quill and react-dnd helped me ship the feature in two and a half weeks.

Now I know that I mentioned that I shipped this feature about half a week late, but just pause for a moment and appreciate how short that timeframe is. In less than a month, one person was able to write the code that powers a Wix-like drag and drop editor for composing emails that all users of our product can make use of. While it’s probably still buggy to some degree, it’s definitely ready for use.

This is the environment we operate in now. Regardless of what it was like building software before 2017, I’m grateful to be alive and contributing to the software industry now. The collaborative atmosphere in the software community doesn’t just make me feel warm and fuzzy, it actually helps me do my job better!

The flash of unstyled text

When I entered the web development industry-complex (is it okay to refer to it as such?) in August this year, the first thing I noticed was how fast it moved. This year EJS and HAML is hot, next year it’s testing frameworks Mocha and Chai, and then Angular2 and React. In our industry, there has been a hot new thing every year.

Recently in a bid to give a well thought out response to a student in class, the instructional team did some googling to see if some esoteric library existed to allow developers to recreate poster-esque typography on webpages. And of course we found one, called Lettering.js. It uses jQuery to transform every single letter in a sentence into a <span> tag, and style it accordingly. Kerning (horizontal spacing in between letters) is easy with margins and relative positioning, and alternating colours is also possible with the :nth-child selector. I thought it is really smart but a bit of an overkill.

But what caught my attention most was a paragraph that espoused the values of the creators of Lettering.js:

“Web performance patterns advise that you put Javascripts at the bottom of your page before your </body> tag. There is an unfortunate side effect where you may experience a FOUT (Flash of Unstyled Text) when you’re manipulating your text after the DOM has loaded. Unfortunately, we found the best solution to avoid/minimize the FOUT caused by this plugin is to put your scripts (jQuery, Lettering.js) in the document . On the one hand, your page will load slower. On the other hand, a flash/restyling makes your site feel slow. Users might ultimately feel the site is faster if they don’t see the FOUT.”

FOUT. What an acronym. To FOUT or not to FOUT is one of many design decisions that developers have to make every day. While the implementation is very simple in this case–moving the <script> tag between the top (at the HTML head) position or the bottom (as the last few lines within the HTML body)–what/how we decide ultimately depends on the project.

The most interesting part about having read this is that I never scrutinised the difference between placing the <script> tags on top or below. I just placed it in the head all the team and used a DOMContentLoaded/jQuery.ready inside my scripts to make sure that the HTML page is fully rendered before JavaScript tries to manipulate them on the DOM.

How fascinating…

How to add event listeners without repeating yourself

One of the key principles of good programming is DRY – Don’t Repeat Yourself!

Here’s one way to reduce repetition with event listeners by using an array .forEach iterator that I’ve used a number of times now. If you haven’t done this before, here you go! If you have an even cleaner and easy to understand solution, please share.

The code below uses jQuery selectors and methods to add ‘mousedown’ event listeners to 4 elements #up, #down, #left and #right.

Code used in an in-class lab to move a ball around the page.

The nightmare of coding a node.js server

lion lying restlessly on the ground

Setting up a node.js server is not the same as writing HTML, CSS or JavaScript. It’s much more complicated than that, and honestly, I think it shouldn’t be.

So, HTML handles what is displayed on the page, CSS alters the way these HTML elements look, and JavaScript manipulates these elements dynamically according to user action. While the process of writing JavaScript code, which is the only real programming language among the three, can be at times very challenging, it is almost always easy to identify the reasons you’re stuck. You might be stuck because you were experimenting anyway, or because you used a string method on an array or something like that. After coding (and staring at code I’ve written) for a while, I’d usually recognise a pattern and be able to fix the problem.

On the end of the spectrum as I’ve recently stumbled upon is node.js and its host of libraries. Ok, I didn’t really stumble upon them so much as I was told to use them by my instructors at General Assembly. Anyway, Node.js is an engine that ports the JavaScript language to be used in projects other than those that run on browsers. In my case, I’m learning to use it as a server side language to build a server for my web project, and it’s been a nightmare. Here’s why…

Node.js comes with a slew of external libraries that do things. In practice, these are more like essentials than addons. Express, body-parser, ejs view engine, passport.js, sequelize database handler, and much, much more are almost requirements for node.js to work as a server.

If it were merely about dependencies I would just live with it, especially at this learning stage, but that is definitely not the case with this house of cards. The biggest issue I’m facing with writing code for the back-end (ie. server) using node.js is the acrobatics it requires of me.

I’ll use the example of trying to set up user authentication to bring you through the source of my recent headaches.

The nightmare of setting up user authentication with passport.js

Ok, here goes. To set up a web app with user sign up and login (what we call authentication and, when it pertains to permission to view certain pages, authorisation), we need to use an external library called passport.

A little on what that means. Passport is a package for Node, and Node in turn is the platform on which our entire server is built. It’s called node.js because it ports the JavaScript language, which was designed and built around browsers, to the server side of things. It’s a big, great deal to have something like node.js exist. For one, it saves me from having to learn a server side language like PHP.

Before I can write a line of code that defines the logic for authentication and authorisation, I need to set up my server to “require” these and various other packages. In this case, I also need the express-session package because passport needs that to work.

After writing a bunch of “require” and “app.use” statements, I then have to create new folders to store a few other files that are absolutely necessary for it to function properly:
1. /config/ppConfig.js to set up the behaviour of passport
2. /controllers/auth.js to receive the signup, login and logout routes and control what happens when the user lands on the page

After this, let me see… Oh ya, after this, I’m supposed to create a “hook” to make sure that when a new user signs up, the info passed into the form and into server are sanitised and the password is hashed (ie. encrypted) before they get stored in the database. That requires using–and thus, learning–two more node packages (bcrypt for encryption and sequelize for communicating with a SQL database using JavaScript instead of Structured Query Language), so I think I’m going to take a break first.

Ok, I’m back, and quite frankly I don’t feel inclined to spell out the rest of the process. It’s just mind-numbing! (If you have questions though, I’ll gladly help as I can. Just post your question as a comment.)

What is the point?

Yes, I have a point I’m trying to make, and it’s this: it shouldn’t be this hard!

I’ve read in several places about a particular kind of professional whose main goal is to build systems so that life can be better, less repetitive and mundane, more colourful…

Programmers are not supposed to have to deal with unnecessary complexity, and this is clearly what it is. It should be easier. With a community as lively as it can possibly be, there should be a project to unite these common server tasks (how many websites don’t need authentication and authorisation nowadays?) into a much leaner machine.

Until that happens, I’m afraid the only way out is through.

(image: Joel Herzog)