DEV Community: Nat-Reid

What is Pseudocode?

Nat-Reid — Mon, 01 Apr 2019 23:35:23 +0000

We’ve all heard of it, and we’ve all probably done our fair share of it as devs. But what exactly is pseudocode?

Pseudo code is the freeform bridge between syntax and our human thoughts. It’s how we can communicate and form the concepts of an algorithm or program without writing it completely. The way I think of pseudocode is as a tool that we use to communicate ideas, and like with any tool, you have to learn to use it.

Writing out pseudocode with pen and paper is an invaluable tool for clarifying ideas. But when first trying out pseudocode sometimes what makes total sense in your head is total gibberish to someone else.

This frustration lead me to a question: Is there a standard way of writing it per language, in general, or at all?

The short answer that I found was: no. Pseudocode a loose term to describe a free form type of organization - a standard pseudocode would be like a standard brainstorming process, one probably exists, but that sort of defeats the purpose of expressing your individual thoughts.

The long answer I found was that there is no explicit syntax/language for it, but there are some conventional rules that can improve your pseudocode and increase it’s efficacy as a communication tool.

Pseudocode exists on a spectrum between syntax and human language. Generally this means you want to avoid writing in plain english because that leaves too much room for (mis)interpretation.

Another rule that is obvious, but can be broken unconsciously, is flavoring your pseudocode with disparate syntax from multiple languages. If you use multiple languages regularly, your pseudocode might become a javascript-ruby swirl.

I know that swirl is the best soft serve at McDonalds, but this

def occurrences (array, substring)
    let count = 0
    array.each do |x|
        x => {count += the number of times substring  appears in x}
    end 
    return count
end

is anything but tasty.

The things that you shouldn’t do with pseudocode are generally intuitive. So if you’re writing pseudocode and it’s starting to feel too abstract or funky - it probably is.

Avoiding those issues is usually obvious once you've experienced pseudocode a few times, but writing concise and effective pseudocode isn't always as easy.

Here are a few rules that I follow to keep things consistent:

Write function calls and basic operations in raw syntax: This makes pseudocode much easier to translate into real code, letting you focus on the difficult parts.
Use proper indentation and brackets for structure and easy translation
Use reserved words of the language wherever relevent: Structure structure structure.
Like with your actual programs (hopefully) Use descriptive variable names: This is just good practice for absolutely any programming, and because pseudocode is explicitly for human brains, using names that your human brain can easily recognize is especially important.

What it comes down to is that pseudocode quality is mostly dependent on how clearly it's structured. Writing pseudocode that is well structured can give even an inexperienced dev an immediate (if cursory) understanding of of really complex programs.

Beyond visually structuring your pseudocode and using the fundamental syntax of the language you’re translating to, good pseudocode has a wide range of strong implementations. Take these two examples of insertion sort pseudocode:

One of these is mostly plain english, but can be understood quickly and by even beginners, the other of these is mathematical pseudocode that is heavy in syntax. Both of these are valid and useful pseudocodes of the same algorithm for different purposes. The first one is an introductory teaching tool, and the second one is a more specific guide for implementing insertion sort. Whether you lean towards more semantic vs more syntactic pseudocode is just a product of how you think and what you think about, both are great!

In some cases your pseudocode might be very syntactic and close to the final product, and in others it will be more semantic and freeform - and sometimes it will start loose and get refined with more syntax as the idea develops.

Or you're pseudocode will be light on syntax and still close to the final product because you're using Python!

If you don't write pseudocode often, practice it just for yourself, and see how accurately you can describe your potential or existing programs with different amounts of actual syntax.

your teammates will thank you for saving so much time with your handy pseudocode skills, and you'll thank yourself for improving how you think about code, so write some pseudocode today!

Looking Into Scratch a Decade Later

Nat-Reid — Mon, 18 Mar 2019 22:29:12 +0000

Scratch, the programming language for kids!

As someone who used scratch as a kid starting in 2009, it was my introduction into computer programming, and only exposure to it for almost four years. Most of my memory of it in its early days are about making silly video games and stories that moved. Now over a decade later, at the very beginnings of what will hopefully be a career in code, I’ve decided to take a trip down memory lane to see what scratch taught me, and what kind of language it really is.

What makes Scratch so great to use as a kid is that all of the programming is organized around sprites which are self contained objects that have a visual representation. Once you understand the basics of running a program, you can immediately, by dragging one of the “move” blocks, see something happen on your screen as a result of the code you have written. This kind of concrete objectivity immediately demystified what computers do.

Now that I’m done reminiscing, let’s look at the scratch IDE where instead of writing text you drag literal “blocks” of code that attach to one another.

In scratch, sprites are both the subject of all of the code - where it is written, and the object - what displays the code’s behavior. Sprites can be created and deleted in the development phase, but are permanent in runtime, acting as their own scope.

When I was using scratch in 1.3 and 1.4, sprites acted as single instance classes. All of their code was confined to them, and they could not be replicated. This lead to a lot of painstakingly copying sprites and slightly adjusting their code or “costumes” (their set of visual representations). But when scratch 2.0 came out, the “create a clone” block came out, making sprites now essentially classes that could instantiate new sprites. In this way, scratch is entirely object oriented. In an abstract way it is possibly the most object oriented language out there, with objects that are almost entirely self contained that correspond to objects that you can actually see and hear on your computer.

In scratch code blocks come in 9 (it used to be 8 before the introduction of the block type) types: Motion, Looks, Sound, Events, Control, Sensing, Operators, Variables, and Blocks.

The most fundamental of these blocks are the Events. These are what determines when a chunk of code starts. Most of the time when I was using it, we only used the “When flag clicked” button, which tells a chunk of code to run from execution (which happens by hitting the flag).

The next most fundamental, and definitely most important, group of blocks are the controllers. These are logical expressions the control the workflow of a program: Looping with repeat and forever, conditionals with if and if-else, waiting, and now instantiation with cloning logic!

Now you might have noticed that blocks come in different shapes. These shapes define what a block does. The three that we've seen so far are the start blocks, which can be built under but not over; logic controllers, that can be coded above, below, and within; and general action blocks which can cause behaviors or modify the environment based on the inputs that you give them.

Looking closer at the controllers you might notice that the conditionals have empty spaces for diamond shaped blocks, and that the looping controllers have spaces for rounded blocks.These two shapes are data in scratch, and are best described by the “operators” group:

Here in operators round shaped blocks perform operations on other data to output new data. Data is passed into action blocks and loopers wherever there's a round space for them, to determine the block's behavior. Data in scratch can either be numbers or strings, and the action blocks themselves are responsible for parsing this data.

There are many different data blocks available, most of which output the current state of the sprite.

The diamond blocks that conditionals take are… you guessed it: Booleans! These blocks produce either true or false, sometimes based on input like in the operators group, and sometimes based on program state like with the sensors group:

What is so incredible about the design of these code blocks, is that only now, over ten years later, am I realizing that these diamond blocks are conditionals. As a kid, everyone who used scratch intuitively knew that the diamond shaped blocks go in the diamond shaped spaces that conditionals have, and that when they were true, the conditionals did things. We were never even taught that ‘if’ was called a conditional and that it controlled the ‘workflow’ of our program. Or that ‘booleans’ have two values, true and false, that conditionals use to determine said workflow. It was all intuitive.

That design has been with scratch since day one, and is a testament to the incredible genius of MIT media labs and Mitch Resnick (the creators of scratch). They were able to take something as scary and confusing as logic and computing, and make it so intuitive, that elementary school kids could learn it without having to know anything about computers.

One thing to notice about scratch, is that cannot be ‘truthy’ or ‘falsey’ like we know and love in most modern languages: Conditionals can only evaluate on boolean values, and because of that there are specific blocks designed for conditionals which are strictly boolean.

The groups we have covered so far are the events, controllers, operators, and sensors. The next one to look at is variables, which can either be just ‘variables’ with single values, or ‘lists’, which are arrays with indices (starting at 1). The blocks available are just getters and setters, which are data blocks and action blocks respectively.

The last group of blocks is actually four groups: motion, looks, sounds, and the modifiable green blocks(which can draw things, play music, interact with hardware input, etc (in my day this was just called pen and it could draw things)). These blocks drive the most common behaviors of sprites, and are what make scratch such a great tool for education. Most kids, including me, are immediately drawn to these blocks, because they actually change what your sprite does on screen and what you hear. These are the actual behavior of your program, and they’re why scratch both a code and an art platform for kids, because you can create scratch projects without any logic that are still really cool and amazing to watch.

To recap, there are five block shapes in scratch:

Start blocks, which have a curved top and a hook at the bottom to execute what comes below them
Controller blocks which can be put anywhere in the execution of a chunk and can evaluate code inside of them (note that the forever loop can have code added below it because it continues to evaluate, well forever until the code stops)
Action blocks which cause behavior, i.e. “do things”, or change the state of the sprite / program
Data blocks, which can (to my knowledge), only be strings or numbers, that are passed into loopers and action blocks to modify their behavior.
and Boolean blocks, which are strictly true or false, and exist to evaluate conditionals (note these can also be passed where data is wanted, and I believe they will just evaluate to the strings ‘true’ or ‘false’)

**(there are also now definition blocks which are used to create your own blocks. These are analogous to methods)

This post was mostly a trip down memory lane for me, not a proper guide to scratch. But I hope that it can shed some light on the functionality of scratch from a developers perspective.

In truth, Scratch is not a very useful language for adult developers - it has only two scopes (clones of sprites share variables with each other, i.e. no instance variables), it’s only recently received functions, which don’t support recursion, and dragging code a round is much more difficult than just writing it. But the way that the blocks fit together intuitively, and how well it engages kids makes it one of the best educational resources of any kind.

So if you have kids, or know kids, introduce them to scratch - there is no doubt that it's why I am becoming a developer today.

Ergonomics for Devs

Nat-Reid — Thu, 07 Mar 2019 21:03:19 +0000

When it comes to ergonomics and self care around using my laptops, I used to think that there are two kinds of people: the people with their exercise ball chairs, standing desks and other gizmos, and us normal folk who crack our necks and keep coding.

The truth is, though, that absolutely everybody could benefit from any number of changes large or small to their workspace and laptop usage. Posture related pain might not always be the biggest problem, but being sore and uncomfortable is a good way to write worse code.

If you have soreness and pain from working at a desk there are three main things you can do: change your posture, stretch, and change your desk setup.

Posture

The answer is that as developers, or laptop users in general, there are four main areas that are stressed when we work: The lower back, shoulder, neck, and wrists. With your spine and shoulders, the key problem when you use a laptop at a desk is that you hunch. More specifically hunching involves having a curved lower back, shoulders rounded forward and probably tense, and your neck bent to face your screen.

I definitely hunch, especially when I’m intensely focused or stressed. As soon as I started thinking about it I would try to un-hunch myself, sit with a perfectly neutral spine, shoulders back, neck straight, and wrists flat. I essentially tried to force myself into perfect posture.

Sitting this way felt like much needed relief, but it honestly wasn’t much more comfortable, often felt strained, and I would be back to hunching as soon as I stopped focusing on my posture. This brought me to the realization that sitting with “perfect” posture wasn’t the answer, improving my posture was.

Figure out which spot is bothering the most, and improve that part of your posture.

For those with lower back pain (which is so common, it is known in the health world as LBP and up to 25% of desk workers have it!): move your lower body further back in your chair and lean back as well until your lower back is slightly curved inwards.

For those with shoulder pain: lean your upper body back and roll out your shoulder when you find yourself hunched over.

For those with neck pain: lower your seat as much as you can so you aren’t looking down as far, and think about lifting the back of your head upward to elongate the neck.

Generally, just being more focused on posture is the key to improving it over time. So whenever you remember to adjust, take a moment to reinforce that memorization and feel how you change your posture.

Stretching

There are an infinite number of online resources about at-your-desk stretches to improve mobility (some of my favorites are here and here ) but generally any movement that stretches and relaxes your tense muscles is good for you. When you’re feeling sore, the key to any good stretch is that the muscle that your stretching is as relaxed as possible, and you are only using the weight of your body, not the force of other muscles, to stretch.
Some of the most simple and unobtrusive stretches are: tilting your ear towards your shoulder with the weight of your hand, and holding your hands behind your back then lifting them while arching your back.

Changing your desk setup

The two main things that I try to optimize are having a higher monitor, and having a lower keyboard that is the right distance away from me.

Having a monitor at eye level is the best position, because it forces your neck to be straight and supported by the rest of your back all of the time. The three things you can do for this are:

If your workspace has monitors available, use them whenever possible
Have your chair as low as possible so that the monitor is relatively higher
Tilt your monitor back so that it is easier to look down at it without bending your neck

For your keyboard, the goal is to always keep your elbows at a greater than 90° angle resting close to your side. This keeps your wrists neutral and also makes it easier to relax your shoulders down. The best place for your keyboard to be takes a bit of fiddling, and is different for people of all shapes and sizes, but generally lower is better (so don’t go too far down in your chair!) and further away is better (your elbows might even be on the table!) until your wrists start tilting upwards.

Conclusion

There are tons of ways that you can improve your posture, and most of them are super simple, totally free adjustments that you just have to remember.
But if you’re anything like me, you can often feel both guilty about your bad posture and hesitant to start fixing it.

So don’t be overwhelmed by how many different things you’re supposed to do to have perfect posture, just make little adjustments here and there whenever you remember, and eventually those things will become habits. Suddenly you might realize that your posture is actually pretty good and you’re in a lot less pain if you stick with it!

Also don’t forget that nothing can replace taking regular breaks to get up and walk around - movement is the best cure for stiff muscles!

Active Record Aliasing

Nat-Reid — Fri, 22 Feb 2019 23:12:16 +0000

A Step by Step guide to Active Record Relationship Aliasing

The entire third week of the Flatiron software engineering course is dedicated to building a command line interface which uses a domain model that we implement in ActiveRecord. With my similarly overambitious partner Jessica Betts, we produced this hunk of a domain for our Game of Thrones CLI:

I love UML, and as soon as we were introduced to domain modeling and relational databases at flatiron, I went crazy for it (as you can probably tell), but what I didn’t know going into this, is that relationships can get more complex than just has_many, belongs_to, and has_many, through:

Most of this model that we designed consists of just those relationships, which took all of 5 minutes to implement with Active Record. But at this point, I was only familiar with using one argument in a has_many statement (or sometimes two with the through: keyword), but that pattern soon proved to not be enough for the complexity of our model.

If you’ve used ruby Active Record for any amount of time, you know that having consistent names throughout your project is very important.

When I was first starting with AR, I learned very quickly that your class names, table names, foreign key names, and relationship symbols all had to be perfectly spelled and formatted by Active Record standards (class names are PascalCased singular, table names are snake_cased plural etc.) for the relationships to work. On a deep level this made sense; how else is AR going to write code that correctly accesses all of these things? But until the system stopped working, I never appreciated how much those symbols that you pass to the relationship macros (e.g. has_many :dogs and belongs_to :owner) are responsible for.

This single symbol argument pattern stopped working when we tried to implement the Murder model (This example is quite morbid... but Game of Thrones wouldn’t be Game of Thrones without murder). Let’s look at this model more specifically:

What you're looking at here is a self join table, a slightly more complex relationship that breaks the typical relationship calls.

This relationship is an example of a self join table; self join tables function exactly like join tables would between different classes, but for one class. That is to say that instead of joining two objects of two different classes, it joins two objects of the same class. At first this seems very intuitive, but working through it, we see that the most basic Active Record conventions fail to describe this domain.

But fear not, Active Record gives us more tools than even the most seasoned developers could ever use, and one of the most simple ones: aliasing will solve all of our self join problems!

Let's do it:

Let's start by thinking about this relationship in plain english: For a Murder to exist, it has to have a murderer and a victim, both of which are Character instances. This makes total sense intuitively, and is easily implemented in the Murder class:

But when we test this code (by manually creating a Murder object) we get an error!

pry(main)> Murder.first.victim NameError: uninitialized constant Murder::Victim from /Users/nissenadam/.rvm/gems/ruby-2.3.3/gems/activerecord-5.2.2/lib/active_record/inheritance.rb:196:in `compute_type'

The relationship is looking for a Murderer class to match its :murderer method, but the murderer is just a Character object. The solution to this problem is that the ActiveRecord association macros can take more arguments to alias the various things that they are responsible for matching (The foreign key, class name, and table name)

NOTE: In ActiveRecord 4 there is another method for this using the alias_attribute method, but in my opinion it makes code more confusing. ¯\_(ツ)_/¯

Going back to the Murder class with this knew knowledge, we were able to tell the belongs_to method that both the murderer and the victim were actually Character objects using the :class_name keyword argument:

The :class_name argument updates the class name that it is looking for (duh) so that it knows that the murderer and the victim are both Character objects. This also makes it compatible with the database, because it looks for the foreign keys in the database that match the class name, which we’ve just set to ”Character”

Moving on to the Character model, we first need to think about its relationship to the Murder model: it actually has 2! We want our characters to know about who they’ve murdered, and who murdered them. Thinking of Murder objects, we can think of these different relationships as deaths and kills respectively (I told you it gets morbid). Lastly we need to remember that both of these methods actually point to a Murder object, so we have to alias them, which would look something like this:

But when we try to test this we get this error:

pry(main)> Character.first.death ActiveRecord::StatementInvalid: SQLite3::SQLException: no such column: murders.character_id: SELECT "murders".* FROM "murders" WHERE "murders"."character_id" = ? LIMIT ? from /Users/nissenadam/.rvm/gems/ruby-2.3.3/gems/sqlite3-1.3.13/lib/sqlite3/database.rb:91:in `initialize' Caused by SQLite3::SQLException: no such column: murders.character_id from /Users/nissenadam/.rvm/gems/ruby-2.3.3/gems/sqlite3-1.3.13/lib/sqlite3/database.rb:91:in `initialize'

Here the has_many/has_one macros are looking for the foreign key “character_id” in the murders table, which it gets from the name of the class, but as we know, the foreign keys in the murders table are murderer_id and victim_id. Lucky for us, we can alias the foreign keys in both has_ statements to get this working too!

Now a Murder is able to access its murderer and victim, and a Character is able to access all of its kills and it’s death.

All that is left is for characters to know their murderer and victims - which they can get through their death and kills respectively. These relationships translate pretty seamlessly from plain english into ActiveRecord code, so let’s write them:

And with that, our code is working! characters can know their victims and murderer, their kills and their death, and the Murder model functions successfully as a join between the two and can be expanded on.

That's cool I guess..

This was just an intro to Active Record aliasing and modeling more complex relationships.

While self join tables and foreign_key aliasing are super rad, they're really only the tip of the iceberg! Looking through the source code for these relationship macros here, we can see that the aliasing patterns we just used are just some of a host of different options that they can take. Also if SQL doesn't give you a massive headache, using the .to_sql command after relationship methods can show exactly how Active Record implements these relationships (e.g. Character.first.victims.to_sql)

A quick example of another very common option (which is also for aliasing) is the :source option in the has_ macros, which can modify the foreign key it is looking for (the same way the :foreign_key option does for belongs_to.

Even if you can't imagine any domains that would need these options (aliasing or otherwise), looking through these options and trying to figure our what they do has deepened my general understanding of active record by a huge amount. Active Record is a crazy powerful tool that will support all of your rails applications, so lifting up the hood and becoming an Active Record master will take your back-end skills to a new level.