DEV Community: Jeremy Schuurmans

The Questions We're Afraid to Ask

Jeremy Schuurmans — Thu, 16 Jun 2022 21:28:32 +0000

I recently returned to work after taking three months off to welcome a baby boy into my family. During that time, I tried to disconnect from work as much as possible and focus solely on my wife and two (then three!) children. I didn't find that difficult, and so as I returned to work - having thought about software only fleetingly for three months - let's just say I felt a little rusty. And since I've only been developing software professionally for two years, I wasn't terribly practiced to begin with.

If it had been up to me, I probably would have started my new assignment with someone who had far more experience, so I could let them take the reins while I got up to speed. However, my assignment was to be the sole Red Squirrel engineer on a small team at a very large and fast-growing company. The stakes were high. My team was responsible for a critical component of the product, and we had a tight and absolute deadline to complete our work. Failure to roll out the changes we needed to make would be a major setback to the client's ability to serve their users, which simply was not an option.

What that meant for me was that I needed to get up to speed very quickly. Since I was the sole representative of my company on a small team, it was also top priority for me to provide a high level of service to the client, which meant I could not remain a muted face in Zoom meetings. In the past, because of my level of seniority, I would typically be paired with a more senior engineer who I could defer to if I made a mistake or said something stupid. If I wasn't sure about something, I could remain quiet and ask them about it later, and no one had to know.

But with my most recent assignment, that would not be an option. It was just me. My knowledge, experience, and skills were about to be exposed for what they were, and all I could do was prepare as best I could, and hope it would be enough to deliver great results for the client. And because first impressions count, it needed to start on day one (earlier if possible).

Where did I start? Well, if there's one thing I've noticed about software engineers, it's that the best ones are always asking questions. Well before my start date, I asked for information on specific technologies the team would be using, so I could get somewhat of a head start on ramping up.
While I on-boarded, I made a conscious effort to ask as many questions as I could as early as possible. If I needed access to something, I asked for it right away. If something was unclear, I asked for clarification. I asked about expectations (do they see my role as staff augmentation, or are they looking for feedback on technology and process?). Once the engagement was underway, I frequently asked for feedback on my work.

The scary moments came in sprint planning meetings and pairing sessions with other engineers. That's when a question would surface in my mind, and I would hear that familiar inner voice say "Don't ask that. That's a dumb question. You'll look ridiculous." But those sprint planning meetings and pairing sessions are at the heart of the Agile process. Those meetings are where everyone's voice really needs to be heard. Those meetings offer me my best chances at gaining clarity and understanding on requirements. And those were the moments I knew I needed to un-mute my microphone.

So I did.

Here are two things I learned from navigating that experience:

Most likely, the only person who thinks your question is stupid is you

I want to make it clear that I'm not basing that assertion on my experience with just one team. Having worked on quite a few (wildly) different teams over the past two years, what I have come to find is that much of the time, the questions we're afraid to ask are the ones that need to be asked the most. If something doesn't make sense to you, it could be because you don't understand it, in which case finding the strength to expose your ignorance and ask the question can only benefit you and the team as a whole. But it could also be that there is an aspect of the problem that the team hasn't thought out yet, and the reason why you feel like you don't get it isn't because your question is stupid, but because the problem needs more discussion.

Just one example that comes to mind: on my most recent project, I was tasked with writing some raw SQL queries for a database backfill process we were implementing. What I didn't know was where I was supposed to write them. Did a file exist already? Was I supposed to create one? Should the queries go in the code base at all, or are they meant to be run by someone locally at some point in the process? I searched documentation and couldn't find an answer, so I asked. It turned out that no one had thought of that up to that point, and those questions prompted an exchange of knowledge across teams, and resulted in our team having more clarity on the database backfill process we were working on.

You never know unless you ask.

You really do know more than you think you do

What surprised me more than the fact that no one laughed me out of the Zoom when I asked questions was how much I could actually do. It turns out, there is magic in being courageously vulnerable. When you find the strength to put yourself out there, it opens the way for you to showcase your knowledge and skills, and you just might even surprise yourself with how good you really are.

What I found was that when I started talking in my meetings, concepts and ideas would come to my mind that wouldn't have if I had sat silently. (By the way, if you have something to say, but you feel afraid that it might be wrong, I find it helpful to lead with, "I'm just thinking out loud here, but …"). You keep the knowledge that you use most often, and when it comes out of your brain, through your mouth, and out into the world, you almost invariably gain new and greater knowledge, especially in a collaborative environment like an engineering team.

There are, of course, exceptions. Some teams are not healthy or particularly collaborative. Some people will go out of their way to make you feel stupid. Sometimes people feel genuinely unsafe with speaking up and making themselves vulnerable in the environment they work in. If that sounds like the team you work on, may I suggest considering making a change, if only for your own health and well-being. If that sounds like the team you lead, consider getting in touch with us.

I am for sure not advocating talking just for the sake of talking. What I am advocating for is you. On a team, your voice should matter. So don't be afraid to speak up and ask stupid questions. You might regret it sometimes, but what feels worse than feeling dumb, is having a question and staying quiet, only for someone else to ask the very question you had and watching it bring about great discussion or results in a meeting.

Give it a try. I bet you'll be surprised.

How to Effectively Communicate with Clients and Stakeholders, Part 1: Estimation

Jeremy Schuurmans — Thu, 07 Oct 2021 03:07:51 +0000

Being a developer is a job that presents many challenges. For me, one of the biggest challenges I have faced in my career has been effectively communicating with clients and stakeholders. As a developer at a consulting firm, my job requires me to communicate with clients often throughout the day. On my first client projects I played it safe, preferring to let the senior developers do all the talking. When I was asked questions in meetings, I would often defer immediately to others with more experience.

In some situations, because I was either the only developer on a project, or the only one present in a meeting, I would have no choice but to communicate with the client, but my lack of experience was painfully obvious, which could be frustrating both for me and the client. As a result, my impulse was to shy away from communicating even more, simply because it was stressful.

This is something that I still struggle with on a daily basis, but I'm constantly trying to improve because there are so many benefits to gaining effective client communication skills. My personal top three are:

It increases your professionalism. An effective communicator is viewed by clients and stakeholders as reliable, trustworthy, and knowledgeable. When my team receives feedback from clients, the thing they almost always mention first is that they love how often and how quickly we communicate with them.

It maximizes your efficiency. Breakdowns in the development process can often be traced back to a lack of effective communication in the initial stages. When requirements, expectations, and blockers are effectively communicated, problems can often be resolved earlier in the process.

It reduces your stress. In my experience, the stress of proactively communicating is far less than the stress caused by not communicating and being forced to when problems arise.

As I'm learning to be a better communicator, one of the main areas I've been focusing on is estimation.

I'm an optimist. In everything. Especially estimating work. I have often found myself in scrum meetings saying, "No blockers. I should be able to wrap this up by tomorrow." But tomorrow never came. Or rather, tomorrow did come, but the pull request did not. I was frequently telling clients that I was almost done, and genuinely thought I was, until a week would go by and it became obvious that I was nowhere near done.

What I've learned is that estimation is not just about how quickly you think you can get something done. You need to take into account various factors like technical requirements, familiarity with the code base and technology, and demands on time outside the project (such as meetings), before promising to deliver something within a specific time frame. So to help me with this, I came up with a set of questions to ask myself before I estimate something:

Do I understand what needs to be done?

This is most important, and the best way to avoid embarrassment later on when you spend three days working on something, only to show your progress in a meeting and find that you totally misunderstood the requirements. Trust me, if that hasn't happened to you, it's not fun. Ask the client and/or more senior developers lots of questions. Let me repeat that: ask the client and/or more senior developers lots of questions.

I think the biggest thing I've noticed watching senior developers in the initial stages of an engagement is that they ask tons of questions. While asking questions is essential, it's equally important to listen to the answers. Active listening is the best path to understanding.

By active listening, I mean more than just paying attention. I'm talking about a practice of listening that helps ensure that you really understand the information you're receiving. Asking questions is a part of active listening. Other key components are:

Asking for clarification when you don't understand something. It takes courage to expose your ignorance about something, but it is well worth the effort.

Summarizing what is said. The best way to make sure you understand what the client or stakeholder has said is to summarize it. "So, what I'm hearing is …" This way, any misunderstandings can be immediately clarified.

Do I understand what the requirements are and what steps I need to take to get it done?

If you're lucky enough to have well-written tickets that outline the requirements for your tasks, before you write any code, read through the entire ticket. Use the requirements to write out a step-by-step plan for how you will complete that ticket. That way you'll never have to ask what you should be doing next. If you don't have well-written tickets, you should write some. Now is also a good time to ask questions, even if it's just to get a second set of eyes on the requirements you've written out on the ticket.

How long will each of the steps take?

Here's where the estimation part comes in. Now that you've taken the time to understand what you need to do, and break it down into steps, write down how long it will take to complete each of those steps. Once you have that worked out, you just need to add those numbers together to get your final estimation. This is a much more accurate way to estimate than thinking to yourself, "Well, that seems like something I can get done in a week."

Is there anything outside of the project that will affect how long this will take?

If you have time off coming up, if you're starting to feel under the weather, if you have other tasks to accomplish on your project, if there is anything you can foresee that would affect your work, now is the time to bring it up. Factoring it into your estimate is much preferable to forgetting about it and having it come up later. The client will appreciate your planning and communication, and it will make your life a lot easier.

Answering these questions will help you not only give a more accurate estimation, but will help you explain to the client why you think you can complete the work within that time frame.

While these suggestions can help you develop better estimation skills, keep in mind that estimates are never perfect. Something always comes up. The problem might be more complex than originally thought, or a technical requirement might have been left off of the ticket - any number of things can get in the way of meeting your deadline. In part two, we'll talk about how to effectively communicate when problems arise.

From Cook to Software Engineer: How Apprenticeship Helped Make My Dream a Reality

Jeremy Schuurmans — Fri, 11 Dec 2020 22:01:59 +0000

"A long apprenticeship is the most logical way to success," guitarist Chet Atkins once said. "The only alternative is overnight stardom, but I can't give you a formula for that." In April 2018, when I signed up for an online web development boot camp, overnight success was exactly what I had in mind. I had hoped to spend three months, six months at the most, learning to code and then land a high-paying job in software development. Reality didn't play out that way, and I couldn't be happier about it.

This story starts around February 2018 in Portland, Oregon, where I was working as a chef. Starting out making fries in a dive bar, I worked my way through culinary school, into fine dining, then restaurant management. For many people, professional cooking is a dream job, but my time in it had strained my relationships and left me burnt out and disillusioned. Low pay, long hours, and working every holiday made it very difficult for me to provide the kind of life I wanted for my family. Then one day I saw an ad for a coding boot camp. I liked computers, but didn't know much about them, and had never written a line of code in my life. The idea intrigued me enough to do a little research. I found that while most people seemed to feel that it would be impossible to be hired in software without a degree in Computer Science, enough people said the opposite that I was convinced coding could be my ticket out of the hand to mouth existence my family and I were stuck in. After learning some basic HTML and CSS, I signed on the dotted line and enrolled in Flatiron School.

Most people in my life thought I was crazy - and for all I knew I was. How could a burnt-out ex-cook with no experience and no college degree possibly hope to get hired by a software company? My faith (and my family's faith in me) was tested often as programming proved itself harder to learn than I imagined. The first three months came and went and I had not progressed very far in the curriculum. Six months passed, and I started to wonder if I had made a huge mistake. Sitting in Starbucks one day, struggling to complete a coding exercise, I saw an email come through from Ruby Central, the organization that runs RubyConf, a conference for professionals and enthusiasts of the Ruby programming language. Several weeks earlier I had applied for an Opportunity Scholarship to attend the conference that year in Los Angeles. Much to my surprise, I read that I was a runner-up and had been put on the waiting list but someone wasn't able to go, so the scholarship had gone to me.

I got off the bus from LAX and walked downtown to the nicest hotel I had ever set foot in. Later that night, they held a reception for the scholarship recipients where I met Brandon, my conference guide. We got along well enough that I felt comfortable opening up to him about my hopes and fears. At dinner one night I told him about wanting to give my family a better life but not knowing if I could do it. I liked writing code but sometimes learning it felt impossible. And if I did manage to learn to code, would anyone ever actually hire me?'

"I promise you," he said seriously, "two years from now you will have a job and your financial situation will be completely different."

"When that happens," he added, "I want to see you tell this story."

He taught me to believe in what I can't see yet and to work for it. To make the most of the opportunities given and always remember that even when things don't work out right away, how fortunate I am to have the opportunity to try at all.

I took a cab back to my hotel, and as we pulled into the parking lot, the driver looked in the rearview and said, "I don't know what it is, but when you got in the car I just felt like the universe was moving in your favor. Like you are headed in the right direction, wherever you're going."

Having the universe on my side was nice, but when I got back to Portland I hit the books harder than ever. My wife and I had been married for seven years, and they were seven years of struggle. I resolved to change our lives for the better and not quit until I had exhausted every opportunity I could find. When I got close to the finish line I started interviewing for jobs. After many applications that went nowhere, many first and second interviews that resulted in rejection emails, and too many days spent jumping at every notification and phone call, I had an offer. I eagerly accepted it, and when I told my wife what my salary would be she was speechless. We stood in our tiny kitchen in silence, sipping whiskey in the afternoon. It was a lot to take in. Almost two years after I wrote my first line of code, our seven years of struggle was finally over.

The next three months were some of the happiest of my life, and then one Monday morning I went to work to find it was all gone. The COVID-19 pandemic had taken its toll on my employer's business and many of us were laid off. I spent the next several weeks trying to figure out what to do next, and it was then that I met Dave Hoover. I liked him immediately, and I was intrigued when he told me about the Red Squirrel Apprenticeship Program. If I were to become an apprentice I would spend thirty to sixty days working closely with a mentor to design and build a passion project while gaining practical experience helping out with client work. Dave's credentials in the apprenticeship sphere lent a lot of credibility to the things we discussed in our initial meeting, and so I eventually decided to go for it.

Before my layoff, I had been working on building an HTTP server in Java, and I decided to continue along those lines for my apprenticeship project. I switched it up a little, though, and decided to build a chat web application using Ruby on Rails, ActionCable, and React. For exposure to client work, I was assigned to GoLogic, an exciting Chicago-based startup working to provide small businesses with product delivery and pick up solutions, which was especially relevant work given the COVID crisis. The API endpoints lacked test coverage and my first assignment was to fix that. In the process, I learned much about building a professional-level API, and also how that specific API functions, which ended up being crucial knowledge when I was given front end tasks later. I worked closely with my mentor Jake, a senior engineer at Red Squirrel. Every time we paired I learned something I had never seen before, and he helped me take my code to the next level. "The quickest way to get better," he said to me once, "is to get your ass kicked in code review over and over again." While that may not be an exact quote, that's the way I heard it, and it proved to be true once I was given features to work on. That can be a frustrating experience for a junior developer who feels like they have a lot to prove, but I found that by listening to and acting on feedback, I improved faster than I imagined I would.

I graduated from my apprenticeship after sixty days, and I've been at Red Squirrel ever since. My assignments since then have consistently pushed me to the edges of my comfort zone, expanding my knowledge and skills. Every day is a learning experience, which I think is the beauty of being a junior level engineer, but I imagine that also applies to being an engineer at any level.

Looking back, I'm grateful for all the people who helped me get to where I am. Looking forward, I'm grateful to go to work every day with a group of people who are not only among the nicest people I know but who are also dedicated and talented teachers with a wealth of combined experience.

But I wouldn't be here if the right people hadn't come along at the right time urging me to keep going. And so if you're reading this, and you're feeling the way I felt, don't give up. Keep going. You may fail or you may succeed, but if you stop too soon, or if you don't start in the first place, you'll never know if your story might have ended differently.

And I want to read yours next.

6 Git commands every beginner should memorize

Jeremy Schuurmans — Fri, 08 Nov 2019 06:46:59 +0000

For people new to Git, it can be confusing and intimidating. If that's you, here are six Git commands for your toolbox. With these, you can become productive with Git and lay a solid foundation for your future Git mastery. Code along with these in order and learn them all!

Just a quick side note: this post is intended to be a quick, accessible breakdown of some of the most common Git commands I use every day, which were also the ones I had to look up most often when I was learning Git. Since it’s geared toward people who are just getting into Git, all my examples are trying to help people get practice using Git locally. I’ll save any discussion about remote repositories like GitHub and commands that interact with it for another post.

My hope is that this will reduce the time it takes for someone new to Git to become productive with it.

It will be most useful to you if you already have a basic understanding of what Git is, a concept of how the Git workflow works (branching, merging, etc.), some command line knowledge, and have Git installed and configured on your system.

I use Ruby in all my examples.

1. git init

git init is how you add Git to your project.

open your terminal, and create a new directory. I keep all my code-related files in a code folder, so I'll put it there. You can put it wherever you like. mkdir code/practice

change to your newly created directory. cd code/practice

create a new project directory named 'git-practice'. mkdir git-practice
cd into it. cd git-practice
run git init

this will create an empty Git repository, a .git directory inside your project directory.

2. git status

git status lets you see the current state of your files.

create a file called "git_practice.rb". touch git_practice.rb
run git status. Git will tell you that you are on the master branch, you have not made any commits, and it will list all untracked files you have, in this case, we only have one, git_practice.rb.

3. git add

git add is how you start tracking individual files.

run git add . adding the space + . tells Git to add all files. You can also add individual files by running git add <filename>. This can be useful if you're ever in a situation where you want to add certain files in one commit, and other files in a different commit.

If you run git status now, it'll show you changes ready to be committed, in this case, that we created a new file.

4. git commit

git commit creates a new commit.

run git commit -m (the -m stands for message), and write "first commit" in quotation marks. git commit -m "first commit"

5. git checkout

You use git checkout to switch between branches.

Note: For convenience, you can abbreviate it to git co I'll use this example for the rest of this post, but you can just as easily skip this and stick with git checkout instead. To use git co you need to set that as an alias for checkout in your .gitconfig file. This file is responsible for your global Git configuration, and lives in your system's home directory, not in your project directory. You can easily set an alias using the command line. To set co as an alias for checkout run

git config --global alias.co checkout

This will create a line in your .gitconfig that looks like this:

If you like, you can alias all these other commands too. For example, if you want to set git st as an alias for git status, you would alter the above command with alias.st status where st is your alias, and status is the command you're aliasing. Feel free to play around with it.

Now instead of git checkout you can run git co If you add the -b option, it will both create a new branch and switch to it at the same time. You can name your branches whatever you like, but descriptive names are best, like so: git co -b add-example-code

running that command will create and switch to a branch called add-example-code.

open git_practice.rb in your text editor of choice.
add some code. Let's go with puts 'Hello World!' Save the file.
let's run git status again to see what happened. Again, it'll show you what branch you're on, and what changes you made that aren't staged for committing yet. In this case, that we modified git_practice.rb.

add and commit this file. git add . then git commit -m "add hello world"

6. git merge

You use git merge to integrate your branch with the master branch.

switch to master. git co master
run git merge add-example-code. This will integrate our add-example-code branch with master, so now all changes made in the branch are present in master.

With these commands you will be well on your way to productivity with Git.

We're barely scratching the surface, however. Many good, in-depth resources for learning Git can be found here.

How to sync your fork with the parent repository

Jeremy Schuurmans — Fri, 11 Oct 2019 19:50:05 +0000

Right now, my fork of dev.to displays this message:

How do I update my fork so that it's the same as thepracticaldev:master?

cd into the directory of the cloned repo

Running git remote -v will display the current remotes

Add the parent repository as a new remote, specifying it as the upstream repository. In this example, we will run



git remote add upstream https://github.com/thepracticaldev/dev.to.git

Verify with git remote -v

Fetch the upstream repository with git fetch upstream

The commits that are different from my fork are now in separate branches in my local environment. Let's merge those. git merge upstream/master

Now my cloned repo looks just like the upstream repository.

NOTE: any changes made locally before the merge are preserved, so you don't have to worry about losing any of your work when you do this.

From now on, whenever I need to sync with the upstream repository, all I need to do is fetch and merge.

At this point, running git push will update the forked repo and display this message:

How to exit Vim

Jeremy Schuurmans — Thu, 19 Sep 2019 19:30:14 +0000

To exit Vim:

If you are in edit mode, first press the esc key.
Then enter :wq + return to save and exit.

To exit without saving, you can run :q! + return

How I keep going when I just want to quit.

Jeremy Schuurmans — Wed, 04 Sep 2019 11:52:24 +0000

I had originally intended this post to be a technical write-up about how I built my second Rails app. Where the idea came from, heroic descriptions of encountering bugs and working out solutions, things like that. But I couldn't write that because my heart wasn't in it. So I'm going to talk about something different, and I'm hoping this reaches someone who needs to hear what I'm going to say.

You see, I've been in a self-paced web development boot camp for over a year and a half. During that time, I've seen a lot of people quit, and a lot of people fly through it in a few months. Most of the people I know who started when I did have graduated by now. Learning to program has not come easy for me.

When I started programming, I had a feeling that I could do it, but I had no evidence to back that up. I had never seen a command line. I had never heard of Python, Ruby, Go, Erlang, Elixir, C, or any of the other languages. I would never have thought that Java and JavaScript were two completely different things. Sudo? Oh, you mean that Phil Collins song?

Permission denied

When I was supposed to build my first program (a CLI web scraper) I was completely lost. I tried and failed multiple times before I found a mentor who taught me how to do it. Learning to rely on other people, and to ask for help despite feeling stupid or embarrassed has been essential to my success. But even after building an object-oriented Ruby program, I still felt lost. I would watch classmates of mine solve coding problems that were impossible for me. I was frustrated, anxious, and thought about giving up almost daily. But then about five months into the boot camp, a funny thing started happening. I was still getting stuck just as much as before, but I was asking for help a little bit less. I was finding more solutions on my own, and things were starting to make a bit more sense to me. I was slowly understanding why I would need to create classes, what attr_accessor does, and as I gained insight into self in Ruby, I was gaining insight into my own self as well. I was thinking about things differently. Logically, systematically, breaking things down and reasoning out outcomes and solutions. I was feeling confident, excited, capable. "I can do this!"

And then I had to learn Sinatra.

Learning SQL, ORM, Rack, ActiveRecord, MVC architecture, and web frameworks made me feel like I was starting all over again. The anxiety kicked in right away, and there was always a voice in the back of my mind saying "you can't do this." But close to a year after I started, thanks to solid mentorship and after many, many, starts and stops and restarts, I had built my first web app.

The best is yet to come, and won't it be fine

Once I had one app under my belt, I felt like it would be smooth sailing. I ran into a whole new challenge as I rebuilt my Sinatra app in Rails. It took a while to learn all the things Rails can do, and get used to how powerful it is. A couple of months later, I had built a full Rails app but still felt like I didn't really understand Rails. Since I rebuilt my first project for my second, I really wanted to do something different for my third, which was supposed to be simply jQuery features added to the Rails app I already built. Anxiety set in, however, and I couldn't do it. I'd break into a cold sweat at the thought of building another app from scratch. A couple more unproductive months followed, and then I had an idea for an app that I really wanted to build. I could see how it would work on the backend right away. I knew how I would set up my database, my associations, my models. I sat down, opened my terminal, made a new directory and ran rails new. You can see the finished product here and the code here.

I found that all the worry, doubt, and anxiety was all for nothing because I knew how to do it after all. And now it looks like I'm actually going to finish this boot camp, despite all the times I thought I couldn't do it.

How have I made it this far? Well, the thing is, I may not have believed in myself, but I believed in possibilities. Whenever I thought I would never be able to learn a technology or complete an exercise or build something, I always thought to myself, "but it's possible that I can do it."

And that's the best advice I can give to anybody who might be experiencing what I have and surely will again. If it's possible that you can do it, you owe it to yourself to try. You just have to start if you have already stopped, or keep going if you're thinking about giving up. It's the only way I know. It can be painful, but you'll learn, and you might just realize that you were about to give up without realizing that you could do it all along.

I still look at apps other people build and think that I'll never be good enough to create something like that. But then I remember that the things that are easy for me today were impossible for me a year and a half ago. So I keep learning, because who knows what I'll be able to do a year and a half from now.

So don't give up.

TDD Basics: How to Write an RSpec Test

Jeremy Schuurmans — Wed, 12 Jun 2019 00:32:26 +0000

Testing can be intimidating, especially for beginners, but it really doesn't have to be that way. With a little practice, writing tests is actually fun. So let's learn RSpec from the ground up and give this testing thing a try. We'll start from scratch and learn how to write a test while solving a basic Codewars challenge using Test Driven Development (TDD). Keep in mind as we do this that the file structure I'm using is overkill for the task of solving a simple code challenge. It is, however, the way you would do it for a larger project, so I'm teaching it this way on purpose so you understand how to properly install, set up, and use RSpec.

Installation

From your project directory, run gem install rspec.

Now run rspec --init

Setup

You will see that this command created a .rspec file in your project directory, and a spec folder with a spec_helper.rb file inside it. These files are for configuration and you don't need to worry about them right now, except to say that we will need to require our spec_helper.rb file in the file we write our tests in. More on that in a moment.

The Codewars challenge we'll be working with today is called Descending Order. Here's the brief:

Your task is to make a function that can take any non-negative integer as a argument and return it with its digits in descending order. Essentially, rearrange the digits to create the highest possible number.

Examples:
Input: 21445 Output: 54421

Input: 145263 Output: 654321

Input: 1254859723 Output: 9875543221

Lets start by creating a descending_order.rb file where we'll code our solution.

Now in your spec directory, create a descending_order_spec.rb file. This is where we'll write our tests.

Whenever you create a file to write tests in, it must be located in the spec folder, and it must follow this convention: [filename]_spec.rb. When you run RSpec, it will look in your spec folder for any _spec.rb files, and it'll run those. If your filenames don't follow that convention, RSpec won't be able to find them.

At the top of spec/descending_order_spec.rb require your spec_helper file and your descending_order.rb file.

require_relative './spec_helper.rb'
require_relative '../descending_order.rb'

Writing the test

Test Driven Development involves writing a test that fails, and then writing code to make it pass, followed by refactoring. Because failing test output is colored red in your terminal, and passing test output is colored green, the TDD process is frequently described as Red-Green-Refactor.

First, we start with a describe block that specifies what we're testing. In this case we'll be testing a method that we'll call descending_order when we write it.

describe 'descending_order' do

end

Next we write an it block with a description of what our method will do when it works. At this point we know what our method needs to do, but we don't know exactly how we're going to make that happen.

describe 'descending_order' do
  it 'takes any integer and returns its digits in descending order' do


  end
end

Now we call our as yet unwritten method, passing in an example argument that RSpec will use to test the code in our descending_order method. Set that to a variable for convenience and organization. This will make it easier to test other values later.

describe 'descending_order' do
  it 'takes in any integer and returns its digits in descending order' do
    ordered_1 = descending_order(1587956342)


  end
end

And lastly we write our expectation. Let's think about this part for a second. This is what we know at this point:

We need to write a method called descending_order that takes an integer value and sorts the digits from highest to lowest.
Our test is going to call descending_order, passing in 1587956342 as an argument.
Our method will need to then return 9876554321.
So, since our method call is set to the variable ordered_1, if our code works, we expect ordered_1 to equal 9876554321.

The beauty of RSpec is that it gives us several methods that we can use to set expectations for working code. In this example, we're utilizing the methods expect, to, and equal.

describe 'descending_order' do
  it 'takes in any integer and returns its digits in descending order' do
    ordered_1 = descending_order(1587956342)

    expect(ordered_1).to eq(9876554321)
  end
end

And we just wrote our first test!

Running the test suite

Run the test by typing rspec into your terminal. Alternately, and this is useful if you have a very large test suite, you can run specific test files like so: rspec spec/descending_order_spec.rb.

Pro-tip: As you start working with larger test suites, it can become overwhelming to run your tests and see dozens of failing examples. Appending --fail-fast or simply --f-f will show you one failing test at a time. Like so: rspec --f-f.

Running your tests should give you output similar to this:

Here we have our first error. Lets break it down line by line.

1) descending_order takes in any integer and returns its digits in descending order

This first line is our it block from our test. It's telling us what the method is supposed to be doing but isn't.

Failure/Error: ordered_1 = descending_order(1587956342)

The next line tells us where in our test the failure occurred, in this case it failed when we assigned the descending_order method to the ordered_1 variable.

NoMethodError: undefined method 'descending_order' for ...

This line here is the actual error that occurred. Here RSpec is telling us that it can't find a descending_order method in the file we're testing, which makes sense because we haven't written one yet.

Pro-tip: Get in the habit now of reading the entire error message, not just the specific exception. The entire error contains valuable information that will help you debug your code. I can't stress this enough. Read the whole error message.

Also, this line here, right underneath the NoMethodError

# ./spec/descending_order_spec.rb:6:in `block (2 levels) in <top (required)>'

might not look too useful at first, but this is powerful information because it tells you the exact line that failed in your test suite. In this case, the failure occurred on line 6 in the file descending_order_spec.rb in the spec directory, as shown here in the first half of that line:

# ./spec/descending_order_spec.rb:6

If you find yourself in a situation where you're working on an unfamiliar application with a full test suite, it's always a good idea to go into the specs and read the tests. They will give you valuable information about how the code works/is supposed to work, and you will understand the tests better when they are run.

For example, in our test we have the line expect(ordered_1).to eq(9876554321). This line is much easier to understand when you read the whole test and see that ordered_1 contains the argument 1587956342. So now we understand right away that when passed 1587956342 the method is supposed to return 9876554321. That's not obvious from the test output itself.

This is probably a good time to mention that it's extremely important that your tests be clean, organized, and understandable to anyone who will read them after you. One of the purposes of testing is to guard your code against regression. When your code needs to be debugged in the future, either by you or someone else, the test suite should be able to be read and understood right away.

So now we need to define a descending_order method. Let's do that. Open descending_order.rb and write the following:

def descending_order(num)

end

And run the test again.

We have a new error now, which is great news! That means we're making progress. At this point in our test, RSpec called the descending_order method, and passed it 1587956342. It expected the method to then return 9876554321, but instead it returned nil. This is because we've only defined the method, we haven't yet given it any sorting ability.

We know that Ruby has a handy #sort method, so lets try that.

def descending_order(num)
  num.sort
end

Another error! It's counter-intuitive because encountering one error after another can be frustrating, but always remember that new errors mean you're making progress toward a solution (most of the time, anyway).

The test output is telling us we tried to call #sort on an integer, and that's not allowed. 1587956342 is a single integer value, and #sort can't sort individual digits like that. How can we get access to the individual digits? Well, we need to split our integer, perhaps into an array. We can do that a number of ways, but the simplest way is to use the #digits method.

def descending_order(num)
  num.digits.sort
end

Running our test again gives us this output:

We're getting closer! In this case, RSpec expected 9876554321, but got [1, 2, 3, 4, 5, 5, 6, 7, 8, 9], a sorted array! The problem (one of them) is that it's sorted in ascending order, and we need it sorted in descending order.

We can do that like so, using one of my favorite operators, <=>, the spaceship:

def descending_order(num)
  num.digits.sort{ |a, b| b <=> a }
end

Excellent! Our array is sorted in the right order, but now we need it to be an integer again. Let's join it.

def descending_order(num)
  num.digits.sort{ |a, b| b <=> a }.join
end

We're so close now! Let's convert that string to an integer and we should be passing.

def descending_order(num)
  num.digits.sort{ |a, b| b <=> a }.join.to_i
end

It works! We successfully used TDD to solve this code challenge. We're not quite done yet, though.

Refactoring the test and the code

It's important to make sure that your tests are simple, but also thorough. Let's add a couple more variables, just to make sure everything still works. Since we're solving a Codewars challenge, we'll use the ones they use.

describe 'descending_order' do
  it 'takes in any integer and returns its digits in descending order' do
    ordered_1 = descending_order(1587956342)
    ordered_2 = descending_order(21445)
    ordered_3 = descending_order(145263)
    ordered_4 = descending_order(1254859723)

    expect(ordered_1).to eq(9876554321)
    expect(ordered_2).to eq(54421)
    expect(ordered_3).to eq(654321)
    expect(ordered_4).to eq(9875543221)
  end
end

The tests should still be passing when you run rspec now.

It's also important to account for edge cases. What does our method do if it's passed a single digit integer, for example? We can guess, but let's find out for sure. Because we're testing a different functionality of this method, we'll write a new test for it.

We'll start with our it block:

it 'returns the original integer if it only has one digit' do

end

Pass in arguments and set to variables:

it 'returns the original integer if it only has one digit' do
  int_0 = descending_order(0)
  int_1 = descending_order(1)

end

And set our expectations:

it 'returns the original integer if it only has one digit' do
  int_0 = descending_order(0)
  int_1 = descending_order(1)

  expect(int_0).to eq(0)
  expect(int_1).to eq(1)
end

So now our full test suite for this challenge looks like this:

require_relative './spec_helper.rb'
require_relative '../descending_order.rb'

describe 'descending_order' do
  it 'takes in any integer and returns its digits in descending order' do
    ordered_1 = descending_order(1587956342)
    ordered_2 = descending_order(21445)
    ordered_3 = descending_order(145263)
    ordered_4 = descending_order(1254859723)

    expect(ordered_1).to eq(9876554321)
    expect(ordered_2).to eq(54421)
    expect(ordered_3).to eq(654321)
    expect(ordered_4).to eq(9875543221)
  end

  it 'returns the original integer if it only has one digit' do
    int_0 = descending_order(0)
    int_1 = descending_order(1)

    expect(int_0).to eq(0)
    expect(int_1).to eq(1)
  end
end

Running rspec shows us that both of our tests are still passing. Congratulations! You just used TDD and RSpec to solve a Codewars challenge. At this point, if we had more than a three-line method, we would refactor the code, in keeping with best practices and the Red-Green-Refactor methodology. This is not necessary now, but it's an important last step that you don't want to forget. Keep these basic principles in mind as we move ahead and, with practice, Test Driven Development will become second nature.

Pass by Reference, Pass by Value

Jeremy Schuurmans — Mon, 03 Jun 2019 03:33:59 +0000

The other day while I was grocery shopping, someone noticed my RubyConf t-shirt and asked, "So do you actually do anything in Ruby, or did you just go to the conference?" I said, "Well, right now I'm just an amateur, but I'm hoping to be good enough to get paid for it one day." Immediately he asked, "What's the difference between pass by reference and pass by value?"

I didn't know.

I mean, I could vaguely remember having heard those terms before, but there was no way I could articulate exactly what they meant. So I went home and set about learning it, and now I can gratefully say that I not only have an understanding of an aspect of programming languages that I didn't before, but I get to pass it along to others who are maybe in the same place I was.

But before we get there, it's important to understand a couple things first: computer memory, and variables.

Memory

Analogically, I like to think of memory as a bunch of tiny labeled boxes inside my computer. When I'm writing a program in Ruby, and I create an object, that object is located in a specific location in memory -- inside one of those labeled boxes. When I need that particular piece of data, it can be retrieved from that location in memory. What is important to understand right now is that different objects will take up more or less memory depending on what they are. An integer takes up less memory space than a string.

Note: This is a purposely oversimplified analogy. Memory, and the way Ruby utilizes it, is a much more complicated topic that I hope to cover in detail at a later date (read: once I feel like I understand it enough to explain it). But if at this point your mind is thinking about heaps and garbage collection, you should find something more advanced to read. If you don't know what those terms mean, don't stress about it right now and read on, my friend. You know what you need to know at this point.

Variables and variable assignment

When we talk about "value", we're talking about something that can be assigned to or stored in a variable, which is a descriptive phrase that points to the value assigned to it. In Ruby, a value can be a string, a boolean, an integer, a float, an array, a hash ... you get the idea. Assigning objects to variables allows us to use those objects in the methods we write. That's called "passing" the variable.

If I create a variable named

best_sandwich_ever

and (controversially) assign it the string object "Reuben",

best_sandwich_ever = "Reuben"

Reuben is the value I'm working with, and my program now understands that when I use the variable best_sandwich_ever, it needs to access the string object Reuben that is stored in my computer's physical memory. As soon as I assign my Reuben string to the variable, my operating system will store the string in a specific, numbered location in memory, so now when I use the best_sandwich_ever variable, I'm using my Reuben string.



best_sandwich_ever = "Reuben"
puts "I love me a #{best_sandwich_ever}!"
"I love me a Reuben!"

If I want to create a method that returns the best_sandwich_ever variable, I will need to define the variable within that method, otherwise it will be outside the method's scope, and the method won't have access to it.



best_sandwich_ever = "Reuben"

def fav_sammy
  return "I love me a #{best_sandwich_ever}!"
end

fav_sammy

# => NameError (undefined local variable or method `best_sandwich_ever' for main:Object)
```
However, I could *pass* the variable to the method as an argument.

```ruby
best_sandwich_ever = "Reuben"

def fav(sammy)
  return "I love me a #{sammy}!"
end

fav(best_sandwich_ever)
# => I love me a Reuben!
```
***Pass by reference***

So what exactly is happening here? When I pass `best_sandwich_ever` to the `#fav` method, I'm passing by reference, meaning that my variable is pointing to the exact location of my `Reuben` in memory. The variable is pointing to the number of the box that currently contains `Reuben`. Why? Because my string could change over time, and thus its memory requirements would change. What if I now want to specify that the best sandwich ever is a Reuben from my favorite pub?

```ruby
best_sandwich_ever << " (but only from The Old Spot)"

fav(best_sandwich_ever)
# => I love me a Reuben (but only from The Old Spot)!
```
That string now requires more memory than just the string "Reuben", so to save memory and processing time, Ruby modifies the string located at the original place in memory, rather than making a copy (which we'll get to as soon as we start talking about pass by value).

The takeaway here is that it is more memory efficient to modify data in its original location in memory, than to make a copy and modify the copy, unless the data we're referring to has low memory requirements, like integers. Accordingly, in Ruby, data types that have larger memory requirements (like strings and arrays) are passed by reference.

***Pass by value***

Similar to the my last example, if I create a variable named 

`albert_einsteins_iq`

and assign it the integer object 160, 

`albert_einsteins_iq = 160`

my computer's operating system immediately places that object at a specific, numbered location in memory. At this point, if I do something crazy like sum 160 

```ruby
albert_einsteins_iq = 160
 # => 160 
albert_einsteins_iq.digits.sum
 # => 7 
```
it might seem like I lowered `albert_einsteins_iq` from 160 to 7 (ouch). However, that's not the case, because as soon as I called methods on `albert_einsteins_iq`, a copy of the data item `160` was made and assigned to a different location in memory than the original `160`, and when I summed the digits *the copy was altered, leaving the original alone.* We can prove this by calling the variable again and seeing what it returns.

```ruby
albert_einsteins_iq
# => 160
```
In Ruby, strings, arrays, and hashes are passed by reference.
Integers, floats, and booleans are passed by value.

**Note:** prior to Ruby 2.4, fixnum is also a data type that is passed by value, but since 2.4, fixnum and bignum became integer objects. Be aware also that pass by reference and pass by value will work a bit differently depending on which language we're talking about, but the basic concept is (mostly) the same.

So how would I have answered my grocery store friend if I had known this before? I would have said that pass by reference is when the actual memory address of the data item is passed, and when modified, the data item itself is modified. And pass by value is when the value of the data item is passed, and when modified, modifies the value leaving the data item at the original memory address unmodified. 

If I pass an array containing my grocery list, what's being passed is the memory address of my array, and that array gets modified as I remove items from the list. 

If I pass the number 1, what's being passed is the number 1, but at a separate memory address as the number 1 I originally assigned to a variable, and that is what is modified if I do arithmetic operations with it.

And then I would have asked him if he knew what aisle the LaCroix water was on.

A Year Ago I Never Would Have Been Able To Do This, But I Just Built My First Web App. Here It Is!

Jeremy Schuurmans — Thu, 22 Nov 2018 03:50:34 +0000

It was almost a year ago when I created an index.html file in my Atom editor, typed "Hello, World!" in it, fired up httpserver, and saw it rendered in my browser for the first time. From that moment until today, I've been spending my time learning Ruby, SQL, HTML, CSS, and JavaScript. I've failed more often than I've succeeded, but I've been happier than I've ever been. And, anyway, today makes up for those past failures, because (thanks to them) I just finished building my first full web app.

CONCEPT

When I was trying to figure out what to build, I took to heart the wise words of

[Deleted User]

who told me once to keep it simple, especially when building something for the first time. "Your goal is to learn," he said, "not impress; besides, simple projects done well are impressive for someone at your level."

Given that, I knew I only wanted my app to have a has_many/belongs_to relationship, nothing more. Two models, no join table, no problems. That meant that I would have a User model and something that belongs to User. So I thought a wine journal would lend itself particularly well to this. User has_many wines, and Wine belongs_to User. The user would input information about wines they like and store them for future reference. It was perfect!

However, I had a hard time getting excited about the idea, despite my commitment to keep it simple. The idea kept popping into my head to allow all users to view every wine entry, not just their own, and before long I had this concept of a wine-centric social media platform in my head. Once I had named it Vino, there was no turning back.

DAY ONE: TESTS

I knew I wanted to build Vino in a test-driven way, which of course meant I would need to write tests first. The problem with that was I didn't know how to write tests. But I knew how to read tests, and I figured now was as good a time as any to learn how to write them.

I started by mapping out the basic structure of my project. I took out a piece of paper, scribbled out the seven RESTful routes, their corresponding views and what each would contain, and then I had a basic idea of how a user would interact with Vino from log in to log out.

As a former chef, I'm used to learning from people who have come before me. A chef, especially in the early stages of development, researches and uses recipes that they alter to fit their needs. With practice, they start to rely on the recipe less and less. This is similar to the way I decided to learn how to write tests. I searched through repos I had forked on GitHub until I found good examples of RSpec and Capybara tests. I copied them into my spec files, and went through them line by line, rewriting them to suit my expectations for the application. In the end, I had 42 tests in my test suite. They consisted of tests for both models, verifying they had the attributes I wanted them to, and the rest were application controller tests, covering everything from a user being able to log in, to not being able to hack a URL and modify another user's data. Writing the tests was a whole day's work, but I gained in-depth knowledge of how tests work and how to write them, and it made building Vino a much more efficient process.

DAY TWO TO DAY THREE: RELATIONSHIPS

Once the tests were written, I felt more confident about building, because I was used to running tests and debugging. I started by running the model specs, defining my classes, and writing migrations for the User model and Wine model. Once that was done, it was time to run the application controller specs and define my routes. I really enjoy databases, but when you start defining your routes, that's when you really get to dig in and figure out the logic. That's the stuff I live for when programming, so I really enjoyed debugging my way to a working app.

Pry was my best friend. Since I was building this using Sinatra, I also heavily utilized a gem called Tux, which, when you run bundle exec tux in your console, opens up an interactive environment that's pretty much like the sexy lovechild of Pry and IRB.

Before long, all my tests were passing, and my data was behaving as it should. My app was working!

Unfortunately, it was also ugly as sin.

DAY FOUR TO DAY SEVEN: ADVENTURES IN HTML

I wanted Vino to look nice. It was really important to me that even though I had kept it as basic as I could, that it was something I could be proud of. Something I could point to and say "I did that" without embarrassment. I came pretty damn close to succeeding.

My design skills are limited, and I still wanted to keep the app simple. So rather than writing all my HTML and CSS from scratch, I decided to Bootstrap it. This was advantageous for several reasons. It meant first of all that I could use a bare-bones Bootstrap template (I didn't use a theme), and write a ton of custom HTML and CSS without necessarily needing to worry about things like clearfix. All the pieces would just fit together nicely, as long as I paid attention to the grid and didn't screw up the size of my rows and columns. It meant I didn't have to worry about making the app responsive because it would be automatically. It also meant that I could give Vino some nice features using Bootstrap's javascripts that I normally wouldn't try to incorporate myself at this stage in my learning. For instance, I used a lot of modals for different features, and I could code those out in HTML, style them in CSS, and they would work.

To learn how to do this, I followed a tutorial on w3schools.com that walked me through adding BootstrapCDN scripts and building out a basic grid for a social media-style website. I altered the grid somewhat to suit my needs, and started styling. I thought it would be fun to make it look like Facebook, so I wrote the CSS to make it happen, Googling around whenever I ran into an issue.

It may sound easy, but my first attempt was a miserable failure. Bugs were popping up like crazy as I tried to do things like create cards for each wine entry, and whenever I fixed one bug, another would pop up someplace else. It was like the worst game of Whack-A-Mole I had ever played. I was getting so far down the rabbit hole with my changes, I knew I needed to start over. So I ran git checkout, started a new branch, and began rebuilding the HTML. After a day or two of work, I had a layout that I liked, and that functioned properly.

git checkout master
git merge revised-layout

When I was as satisfied as I could be with every little detail, I started refactoring the code. I tried to make it as DRY as I could as I started cutting out lines of code that served a purpose in the beginning, but were unnecessary in the finished product. I tried hard not to repeat myself more than necessary. When I was building, all the HTML and CSS for each view was together in each .erb file. I moved all the CSS to a stylesheet and as much repeated HTML as I could to a layout. It could definitely be more DRY, but I did as much as my lack of experience would allow. With a sigh of relief, I arrived at the moment when I couldn't think of anything else I needed to do. At least for the time being.

git add .
git commit -m "done."
git push

With a smile, I opened a bottle of wine, poured myself a glass, and sat back ...

... then looked at the label, fired up shotgun, logged in, and put it in my app.

NEXT STEPS

I'd like to add features like comments which would be a good way to incorporate a many to many, or a has_many through relationship. I would like stricter authentication, flash messages, log in with Facebook OAuth, the list goes on. The next thing I want to do is build a Rails app, so I may rebuild Vino in Rails and add these features.

Programming can sometimes be so frustrating I think about doing something else. And then I build something and remember how much I love it. I hope I always find a way to fall back in love with programming.

If you want, you can check out the GitHub repo.

From Chef to Programmer: Lessons From The Kitchen

Jeremy Schuurmans — Wed, 12 Sep 2018 13:20:28 +0000

Before I fell in love with programming, I was a professional cook. I spent two years in culinary school, and worked in a lot of different restaurants, from dive bars to fine dining. Along the way, I learned some lessons that still guide how I approach my work. Though I'm nowhere close to perfect at any of them, I'm reminded of them when I program and see the scars on my hands and arms from the burns and cuts I collected. I want to share them with you.

Work harder than the person next to you

Most everyone who starts cooking professionally starts in the same place, the bottom. For most people, that's the salad station, known as garde manger, or pantry. In an industry as intensely competitive as restaurants, the only way to move up is by working as hard as you can. This means being willing to take on any assignment your chef gives you. It means constantly working to master your craft. Always striving to be better than you were the day before, always learning, always growing. It can be hard sometimes to find that drive within yourself. It's easy to get comfortable on the station you've been working for several months or a year, and it can be terrifying to do something different. The best way that I know to combat that and push yourself to work harder, go further, and grow faster is to look at the person next to you and try to work harder than they do. Whether you're a junior dev, or a bootcamp student who just finished writing a "Hello World" program, or even someone with years of experience, there is no secret to becoming the programmer you want to be. It takes work. Programming is a craft like any other, and the only way to master a craft is to work at it all the time.

Find a way to love what you do

I learned early on in my cooking career that I was never going to be a head chef. I didn't want to admit it for a long time, but in my gut, I knew it was true. The reason for this is simple, I didn't love cooking. I enjoyed it, sure, but I worked alongside people who lived and breathed to cook and I could sense that they had something I didn't. I saw their passion for their craft push them through incredible obstacles. They were the ones who were seemingly blessed with inspiration from the gods of gastronomy. They always had better ideas, better product, and better technique, because they loved it to the point that they were always working to be better. They read about cooking, practiced their skills, leveled up, cooked outside of work, and as a result they were just better. If you're going to code, if this is your career path, then go all the way. Read as much as you can about programming. Practice your technique by doing code challenges and exercises, and build side projects. Love what you do. The familiar saying "love what you do and it'll never feel like work" is false. At least for most of us. But if you love what you do, you'll love the work regardless. It'll help you keep moving forward when you're tempted to quit.

Show up

Opportunity comes to the people who are there when it arrives. You have to show up. To me, this means two things. The first is don't be lazy. If you don't feel like working on a project, work on it anyway. Every day, I talk to a dozen people who are hungry to make it as developers. I'm one of them. If you've already made it, recognize how lucky you are and make the most of it. The second is don't be afraid. If you don't think you can build a project, build it anyway. If you don't think you can write a blog post, write it anyway. Don't let yourself get caught in the trap of thinking that you can't do something because you don't know how, or you're not qualified. Show up, do it anyway, and you'll be surprised at how much you're capable of. You never know what opportunities you might miss out on if you don't try.

Be organized

The best kitchens are obsessed with organization. Mise en place. Everything in its place. The most common piece of advice I've heard for cooks who were in the weeds, aside from cook faster, was to stop, take a breath, and wipe down your station. When your work area is clean, and your tools are where they should be, your mind is better able to handle complex problems. For a cook, that could be preparing ten different dishes simultaneously. You know what that looks like for a programmer. Our minds need to be clear to debug that problem that has us totally lost, and a good first step is to organize your space, whether that's your physical desktop, your computer desktop, the directories and files in your application, or even your life. Being organized leads to better success.

Plan your work. The best cooks never have to ask what to do next. They have a solid plan of action, written down, that they execute step by step. I have seen so many people fall on their faces because they didn't have a plan (I was often one of them) and so many others kill it because they always had a plan. Plan your day. Write out your projects in pseudocode before you start programming. Sometimes there's no way to get where you want to go without a map.

Never stop learning and teach when you can

Cooking is a lifelong pursuit. Even the best never stop learning new things, and that's one of the reasons why they're the best. Programming is no different. There's always something new to learn. So absorb as much as you can, and help out the next person in line. We owe it to everybody who helped us learn to help the people who are where we once were. It's not just a nice thing to do, we learn more by teaching than we ever could by studying. And anyway, the world seems like it needs more nice people right about now. Might as well be us.

Ruby Method Spotlight: Slice

Jeremy Schuurmans — Sat, 25 Aug 2018 02:21:56 +0000

Just a quick note before we begin: this post assumes a basic knowledge of Ruby data structures, since I can't really think of a reason why you would want to read about this otherwise. Specifically, you should know what arrays and strings are, and you should probably have some understanding of return value.

WHAT DOES IT DO?

#slice is a method that operates on arrays, strings, and (since Ruby 2.5.0) hashes. We'll just focus on arrays for now, since the logic is basically the same regardless, but keep in mind that you can call #slice on strings and hashes as well. #slice allows you to cut into an array and select specific elements.

HOW DOES IT WORK?

Let's say you have an array of fruits:

fruit = ["apple", "banana", "orange", "grapefruit", "tomato"]

You can call #slice on the array, pass it a specific index, and it will return the object at that index. Calling fruit.slice with an argument of (2) will return the string object "orange" because "orange" is at index 2 of the fruit array (note that array elements are indexed starting at 0, so "apple" is at index 0, "banana" is at index 1, etc). Let's drop into IRB and check it out:


2.5.1 :001 > fruit = ["apple", "banana", "orange", "grapefruit", "tomato"]
 => ["apple", "banana", "orange", "grapefruit", "tomato"]
2.5.1 :002 > fruit.slice(2)
 => "orange"

If you want the banana, the orange, and the grapefruit, you can call #slice with a starting index and a length of elements and it will return those objects in an array.


2.5.1 :001 > fruit = ["apple", "banana", "orange", "grapefruit", "tomato"]
 => ["apple", "banana", "orange", "grapefruit", "tomato"]
2.5.1 :002 > fruit.slice(1,3)
 => ["banana", "orange", "grapefruit"]

This selects all elements starting with index 1 and ending with index 3.

Similarly, we can use a range:


2.5.1 :002 > fruit.slice(1..3)
 => ["banana", "orange", "grapefruit"]

Another way to utilize this method is to call the array, and then simply select the elements you want, like so:

fruit[2], which returns
=> "orange"

This is useful if you need to work with specific parts of a specific element. If your baby really wants a "nana", for instance, not a "BAnana", you can select the "banana" at index 1 by calling fruit[1], and chain [2,5] onto it, which will select the string object at index 1 of the array, and then select the letters at indices 2 through 5 of the string object itself. Like this:


2.5.1 :001 > fruit = ["apple", "banana", "orange", "grapefruit", "tomato"]
 => ["apple", "banana", "orange", "grapefruit", "tomato"]
2.5.1 :002 > fruit[1][2,5]
 => "nana"

I hope you're starting to see how powerful this method is. You can do so much with it, especially when you use it with regular expressions, or other methods.
With a chef knife you can take food and change it in so many ways, and the same goes for the #slice method, but without the risk of cutting yourself. Drop into IRB, play around for awhile, and see for yourself what it can do. Ruby is designed to make programmers happy, and so with Ruby,

#slice of cake?

A quick note on hashes: like I said above, you can use #slice on hashes, but only in the newest Ruby versions. You use it like so:


2.5.1 :003 > basket = {fruit: "apples, bananas",  vegetables: "carrots, onions, celery", grains: "rice, cornmeal, quinoa"}
 => {:fruit=>"apples, bananas", :vegetables=>"carrots, onions, celery", :grains=>"rice, cornmeal, quinoa"}
2.5.1 :004 > basket.slice(:vegetables)
 => {:vegetables=>"carrots, onions, celery"}
2.5.1 :005 > basket.slice(:vegetables, :grains)
 => {:vegetables=>"carrots, onions, celery", :grains=>"rice, cornmeal, quinoa"}

For more on #slice, see the ruby docs, particularly look at concepts we didn't cover, like what situations cause #slice to return [] or nil, and what #slice! does.
For more on using #slice with strings, click here
For more on using #slice with hashes, click here

If you have any questions or comments, just drop me an email, or comment below.

Until next time, happy coding!