DEV Community: Alex Kharouk

Book Club: Eloquent JavaScript - Chapter 3

Alex Kharouk — Tue, 10 Aug 2021 16:31:10 +0000

The World of Functions

Quick update

It's been almost a month since I published the first part of the Eloquent JavaScript Book Club series. I enjoyed the feedback I received from the Dev.to community and was happy to see folks wanting to join the book club and read along. However, as it has been almost a month, I'm sure many of you continued and finished the book without me. It's cool; I get it. Personally, a lot has happened in my life.

I quit my current job and am very happy to have accepted an excellent offer at a great company. I received an unconditional offer for a Masters in Computer Science & Artificial Intelligence, where I'll be studying part-time for the next two years. I learned a heck load of data structures, algorithms, systems design, and everything in between.

It's been a wild month, but I'm ready to sit back a bit. Drink a nice cold brew. Open up the dusty textbook and get into some eloquent JavaScript. Before we start, I want to quickly mention that I also completed the Just JavaScript book/workshop/mini-course by Dan Abramov. I've already seen some parallels between eloquent JS and that course. I would wholeheartedly recommend getting into both. It helped solidify my mental model of how things like variables (and functions) work. There should be a blog post to analyse the two texts.

Right, functions.

People think that computer science is the art of geniuses, but the actual reality is the opposite, just many people doing things that build on each other, like a wall of mini stones.

Donald Knuth

Without functions, our code wouldn't function well. It will still do its job. Expressions and statements will continue to execute whilst our bindings (variables) will continue latching onto data. But without some order or a way of keeping related code together, it'd be complicated to manage.

We can create functions with a function expression. It's similar to how we have defined variables.

const addTwo = function (num) {
  return num + 2;
};

The num is a parameter, whilst the curly braces encapsulate the body of the function. The code above creates a constant called addTwo and binds it to a function that takes in a number and adds two to it.

Some functions have a return statement. Others return nothing at all. Yet just because it seems like it returns nothing in the code, in reality, all operations with no explicit return statement return undefined. Another example is to open your browser's console, and type in console.log('hello'). You'll see hello being printed, but you'll also get the type undefined returned. That's because the .log() is a function that doesn't return anything. It just runs a side effect, which is the printed message.

Side note, the same thing happens when we execute an expression like let x = 42; as variable declarations do not produce a value but returns something.

Understanding Scope

A crucial advantage that a function has is being able to have it's own scope. It's a mechanism that allows a function to deal with its internal state and prevent other functions from manipulating state. It creates separation of scope, where you have the global scope (outside the function), and the inner scope. Global scope is like setting some variables at the top of your file.

let time = 9;
let closingTime = 11;

Functions have the ability to read those variables, and even manipulate them (we will discuss why this is not necessarily good). However, we can't reach into functions and control the variables.

const personalSchedule = function () {
  let doctorsAppointment = 12;
};

console.log(doctorsAppointment);
// doctorsAppointment is not defined

These variables are known as local variables (or local bindings). They only exist for a limited amount of time, when the function is called. Then, once the the function has finished executing, they cease to exist. It's quite melancholic.

A key thing to note is that variables declared with let or const are local to the block they are called in, and therefore can not be called outside the block, unlike var. A great example is a for loop:

for (let i = 0; i < 5; i++) {
  // execute code
}
console.log(i); // undefined

for (var i = 0; i < 5; i++) {
  // execute code
}
console.log(i); // 5

Notice the difference in the highlights

Another thing to note is that whilst we can't look inside a function to get its variables, we can look outside the scope of the function.

const x = 10;

const halve = function () {
  const divided = x / 2;

  const print = function () {
    console.log(x); // 10
    console.log(divided); // 5
  };

  print();
};

halve();

The print function inside halve can interact with both the x variable in the global scope, as well as the divided variable within the scope of the halve function. This is also known as lexical scoping, where each local scope can also see all the local scopes that contain it. On top of that, all scopes can see the global scope.

Declaring Functions

We've seen functions declared as an expression. We can also assign them in a shorter way through what is known as function declarations.

function booDeclare(name) {
  console.log(`BOO! Did I scare you ${name}?`);
}

// how we would write it before
const boo = function (name) {
  // ...
};

There is a difference between the two, and it's primarily due to something called hoisting (we won't get into this right now). If you were to call booDeclare before it was declared, you would see that it still works. However, we can't say the same for the other function. This is due to function declarations being hoisted up to the top of the conceptual page, and thus is able to be used anywhere in the code.

This kind of makes sense, as the second function is more like how we declare a variable, and that we are unable to know what the variable binds to before it is declared.

console.log("I am walking through a haunted house", booDeclare("Alex")); // works
function booDeclare(name) {
  return `BOO! Did I scare you ${name}?`;
}

console.log(boo); // Cannot access 'boo' before initialization
const boo = function (name) {
  return `BOO! Did I scare you ${name}?`;
};

console.log(ghost); // Cannot access 'ghost' before initialization

const ghost = "nice ghost";

Arrow functions

You might be familiar with arrow functions as well. They are newer syntax, and they provide us a way of writing small function expressions in a (my opinion) cleaner manner.

const owedMoney = (sum) => {
  return sum;
};
// can be written as
const owedMoney = (sum) => sum;

The code is less verbose, as it now implicitly returns the value that sum is bound to, and there are no curly braces. There is another difference between the arrow function and a function expression, and that is regarding the keyword this. We will talk about it more once we get to Chapter 6 (can't wait).

Optional Arguments

The beauty of JavaScript is that it's quite lenient in what you can do (compared to other languages).

function ages() {
  console.log("I have no args");
}

ages(11, 23, 52, 59, 32, 53, 99, 29, 48, 75, 49, 23); // I have no args

No errors! What happens here is that JavaScript will ignore all these arguments if they're not being used. Simple. Even if you specified the arguments, and didn't provide any parameters, JavaScript will still not error out.

function ages(person1, person2, person3) {
  console.log(person1, person2, person3);
}
ages(19); // 19 undefined undefined

JavaScript assigns missing parameters to undefined (similar to when you declare let x;). It also dismisses any parameters provided if there's no explicit use for them. As you can tell, this is not so beautiful. The downside here is that you can accidentally pass the wrong number of arguments, or none at all, and you might not realise that you have a bug.

One way to assign a value to an argument even when it's not passed is to use optional arguments.

function ages(person1 = 23, person2 = 99) {
  console.log(person1, person2);
}
ages(22); // 22 99

Again, this is not the ultimate solution as it will only assign the parameters in order. So if you don't pass anything in the second argument, person2 will always default to 99. That's why it's common to see code like this (albeit this is very contrived).

function fetchPosts(url, method = "GET") {
  const data = fetch(url, { method });
}

Functions and Side Effects

As we've seen, functions can be split into two types. Functions that execute other functions or side effects, and functions that have return values. At times, you will have functions that do both. Each have their own use cases, and their own advantages. Functions with return values will almost always be called more often, since we rely on the values returned to execute more code.

There are pure functions, that have the pleasure of always being reliable. The purity comes from:

relying on global variables whose values might change
always returning/producing the same value
can easily be replaced with a simple value:

const return5 = () => 5;
let total = 5 + return5(); // 10
total = 5 + 5; // 10

They are easily testable, making unit tests a breeze to write. They usually are quick to understand, as you don't need to scour other parts of the codebase to see what's being called. In essence, they're great. Yet, that ease comes with a bit of difficulty. Whilst you can write primarily pure functions, you'll realise quickly that some side effects are needed. So unless you're a total purist who despises side effects, I'd say it's fine to have a mixture of both. Like the author says:

"There'd be no way to write a pure version of console.log, for example, and console.log is good to have."

Summary

So, functions. A brilliant addition to our JavaScript tool-belt that allows us to manage multiple kinds of scope, separating code logic, not repeating ourselves, and understanding side effects. The chapter gave us a lot of information, and I think it's an important fundamental to really grasp. The author also brings up concepts like the Call Stack, and Recursion. I decided not to include that in this chapter as I felt it deserved a separate snack-esque post. You can read more about it on my website, although the blog post is still "growing."

Thanks for reading! The next chapter will be about some rather essential data structures, Objects and Arrays.

If you'd like to attempt the exercises for the chapter, you can find them at the bottom of the chapter. Let me know how you get on. I definitely recommend going through them, to help solidify your knowledge.

Book Club: Eloquent JavaScript - Chapter 2

Alex Kharouk — Tue, 06 Jul 2021 07:31:12 +0000

There is joy in reading about JavaScript. It's like catching up with an old friend who is sharing what they've been doing. Lots of cool new ideas; super popular. Yet fundamentally, they haven't changed. They're the same, weird, sometimes awkward friend. That first friend, for some of us. In the end, we're just happy they're doing well.

That's the sensation I'm getting with reading Eloquent JavaScript. Last time, I began reading the book after a difficult interview. It opened my eyes that I know Javascript, but do I really know JavaScript? I've received comments that I should read Kyle Simpson's YDKJS (You Don't Know JS) books. I do own them. I suppose I didn't want to start with a series. I wanted a beginning-to-end kind of story. That said, I wouldn't be surprised if I decide to pick it up after Eloquent JavaScript.

On to Chapter 2, Program Structure.

And my heart glows bright red under my filmy, translucent skin and they have to administer 10cc of JavaScript to get me to come back. (I respond well to toxins in the blood.) Man, that stuff will kick the peaches right out your gills!

-_why, Why's (Poignant) Guide to Ruby

First of all, what a great quote. I read Why's guide a long time ago. It was humorous and showed me how diverse programming language communities are. Okay, back to the chapter two.

Expressions and Statements

We begin with understanding what expressions are and what are statements. Anything that produces a value is an expression. Anything that is written literally is also a value. 22 is an expression. "hello world" is an expression. Within a line of code, there can be multiple expressions. With that said, the line of code itself would be a statement. 1 is an expression, 1; is a statement.

Notice the difference?

I like to look at expressions as nouns — statements as verbs or actions. The action can sometimes be implicit, however. In JavaScript, you don't always need to add the ; to denote the end of a statement, so sometimes, you can omit explicit statements for implicit ones.

Statements can be simple, like 1;. But these statements aren't interesting; they are useless. Interesting statements affect something. Have an impact on its world. They could display something on the screen or update the state of a program. These statements can impact other statements, creating what is known as side effects.

Side effects might sound familiar to you if you use React Hooks. I've encountered that description due to learning about useEffect. I always thought side effects were something that the React developers referenced. It's much more than that. A side effect is simply a statement containing an action or result that could impact other statements.

Bindings

Marijn uses bindings to describe a way to store data and keep an internal state. If that sounds familiar to you, it may be because you know what variables are. However, Marijn seems to insist and call them bindings. I suppose it has something to do with their definition of a variable.

A variable is labelled as "not consistent" or having a fixed pattern; it is liable to change. This is partly correct with JavaScript variables. Using keywords like let or var makes sense with this definition. Using the keyword const does not fit this definition. Another way I was taught variables was by thinking about them as boxes. You are designating boxes for data you want to store and use later. If you need that data, you open up the box.

The author asks you to think a bit differently. Think of variables, or bindings, like tentacles rather than boxes. Think of them as pointers to values rather than containing values. Here's an example:
let ten = 10. ten doesn't unpack and reveal the data 10. What it does is it returns you the number 10 that it references.

It's a curious way of thinking about variables, and maybe a bit too much time was spent thinking about whether they're more like boxes or tentacles. I believe the author to be correct. Variables are references to data in memory. If we look at the code, we see that they are equal when comparing the two bindings. Why? Because 10 is saved in memory once, and both ten and anotherTen variables reference the number. Same with the string example.

let ten = 10;
let anotherTen = 10;
console.log(ten === anotherTen); // true; they are equal

let word = 'hello';
let anotherWord = 'hello';
console.log(word === anotherWord); // true

Again, something as simple as variables creates a discussion! It's fascinating how, when I first studied Javascript, I essentially skimmed through why things were the way they are. The rest of the chapter discusses loops and conditional execution (if-statements). If you are unsure about these topics, please make sure you read the chapter. Otherwise, I've noticed two things that I was not familiar with when using loops.

Do, while loop.

let yourName;
do {
  yourName = prompt('what is your name?');
} while (!yourName);

The difference here is that we always execute the block at least once. We always prompt the user for their name.

If they don't enter an accepted value, we will be in a loop until we get the name. I usually don't use do, while loops, but it's good to remember as a reference. Another thing about loops, specifically traditional for loops, is that they must contain two semicolons. I write the usual syntax so frequently that I never contemplated why I needed the semicolons in the loops. Well, the statement before the first semicolon is an expression or variable declaration. After the first semicolon, we have the condition, an expression that is evaluated before each loop iteration. Lastly we have the final expression, which will be evaluated at the end of each loop iteration.

//Notice empty space  v -- we don't set a condition so it can run forever if we let it
for (let current = 20; ; current = current + 1) {
  if (current % 7 == 0) {
    console.log(current);
    break;
  }
}

var i = 0;
for (;;) {
  if (i > 3) break; // we need the break statement, and still need the two semicolons!
  console.log(i);
  i++;
}

So that's it for Chapter two of the book. What did you think of it? Do you think I focused too much on the theory rather than explaining other aspects, such as loops or if-conditions? Are you enjoying the book yourself? I thought this chapter was a bit of a slower pace compared to the first chapter. A minor spoiler, but I have also read the third chapter Functions, and things pick up. By far my favourite chapter, so it's worth getting through chapter two.

Big thanks for the comments from the dev.to community. If you'd like to see some additional resources recommended by the community, check out the thread for the first chapter here.

Until next time.

Originally posted on my personal blog website, which you could see at alex.kharo.uk

Extra Exercises:

Chapter 2 introduced some exercises, which included a FizzBuzz exercise. My first attempt was the traditional way:

// print fizzBuzz from 1..n
function fizzBuzz(count) {
  for (let i = 1; i <= count; i++) {
    if (i % 15 === 0) console.log('FizzBuzz');
    else if (i % 3 === 0) console.log('Fizz');
    else if (i % 5 === 0) console.log('Buzz');
    else console.log(i);
  }
}

However we were told to think about a cleverer solution, combining the printed text together:

function fizzBuzz(count) {
  for (let i = 1; i <= count; i++) {
    let word = '';
    if (i % 3 === 0) word += 'Fizz';
    if (i % 5 === 0) word += 'Buzz';
    console.log(word || i);
  }
}

Book Club: Eloquent Javascript - Chapter 1

Alex Kharouk — Sat, 03 Jul 2021 16:19:27 +0000

I recently did a technical job interview that was for a frontend position. It was for a company that specialised in cybersecurity technologies, but they were looking for React developers to create better UI dashboards for clients.

I expected the interview to ask some algorithm questions, maybe talk about some JavaScript data structures or optimisation. Instead, I was taken aback by the questions I got. What is prototypal inheritance? Can you explain, fundamentally, what are promises? What are some differences between a function declaration and a function expression?

My first thought right away was, how simple must their codebase be?! I thought the company was looking for React devs! I now see that they were looking for competent Frontend Engineers, not people who can quickly spin up a Next app and boast about how they understand static generation. They wanted engineers who have mastered the fundamentals. These fundamentals can help solve any complex bug in the JS ecosystem. That's the beauty of being a master of the language.

Every error message in any framework is just because something was grinding against the way JavaScript works. However, JavaScript is complex. So how does JavaScript work?

The Interview didn't go so well.

I realised I have a good gist of what's going on with JavaScript, but I struggled to explain the basics simply because I never looked inside the JavaScript engine. It was a fantastic lesson; I didn't want to feel resentful or upset with how little I know. Instead, I am using the experience as a way to learn. I want to be able to answer these questions. I always enjoyed looking underneath the hood; now it's time to seriously focus my direction towards the language that kick-started my career.

I want to start a book club. For myself. Potentially for you, too, the reader. I searched online (and my dusty bookcase) for an up-to-date, renowned textbook around JavaScript. I decided to start with Eloquent JavaScript, highly regarded as an excellent JavaScript text. Also, I have skimmed through it before, and the author, Marijn Haverbeke, has a great voice.

I was a bit nervous to begin because it might be too basic at this point in my career. Starting with sections that explain what a string is will quickly lose my interest. At this time of writing, however, I am pleasantly surprised with what I read so far.

This post will focus on chapter one. The series will focus on my notes and observations. It will be around the content I didn't know about JavaScript. I strongly recommend you read the book yourself. It's free, available for most devices, and possibly covers everything you need to know to get started with the language and programming in general.

Chapter One

Below the surface of the machine, the program moves. Without effort, it expands and contracts. In great harmony, electrons scatter and regroup. The forms on the monitor are but ripples on the water. The essence stays invisibly below.

Master Yuan-Ma, The Book of Programming

Numbers and Memory

Dealing with types in JavaScript costs memory. If you need to store values in a variable (or bindings as the author calls them), the variables need to occupy space on your computer. In typical modern computers, we have more than 30 billion bits in volatile working memory (think RAM). Nonvolatile storage, like SSDs or hard disks, have much, much more.

JavaScript's number type has a fixed number for bits. 64 bits to store a single number value. That's fascinating because, at first glance, it doesn't sound like a lot. When you begin understanding bits, you realise that what that means is that we have around 2^64 (2 to the power of 64) potential numbers. That equates to approximately 18 quintillion options.

That is a lot. Issues usually arise when dealing with massive numbers. Let's talk about all the grains of sand on our Earth. If we stored that value in a variable, we would still have around ten quintillion bits left to do whatever we want.

Some caveats include negative numbers that use an extra bit to signify the - sign and non-whole numbers like floats. If we consider all of that, we would still have 9 trillion combinations for whole numbers. Unfortunately, not enough to store all the grains of sand...

Operators and Types

We have unary operators, rather than just binary operators. A binary operator would be something like 5 + 3, where the plus symbol takes two values. A unary operator takes one value; hence the name. typeof is a unary operator that returns the value type.

There's only one ternary operator called the conditional operator. You might have seen it before: true ? 1 : 2.

null and undefined are peculiar types. The author says they are used interchangeably and are more or less the same thing. I can't entirely agree, as I see undefined as values that could exist later, whilst null symbolises the value's absence. I'd instead stick to just using undefined if I can, but it's always best to secure your types wherever possible. The author also mentioned that:

The difference in meaning between undefined and null is an accident of JavaScript's design, and it doesn't matter most of the time.

Exploring that a little bit, I found this quote on a Stack Overflow post explaining a bit more about the accident.

Quote from the book Professional JS For Web Developers (Wrox): "You may wonder why the typeof operator returns 'object' for a value that is null. This was actually an error in the original JavaScript implementation that was then copied in ECMAScript. Today, it is rationalised that null is considered a placeholder for an object, even though, technically, it is a primitive value."

Captain Sensible (great name)

In JavaScript, we also have automatic type conversion:

console.log(8 * null);
// → 0 (null is converted to 0)
console.log('5' - 1);
// → 4 ('5' becomes 5)
console.log('5' + 1);
// → 51 (1 becomes '1')
console.log('five' * 2);
// → NaN (can't use *, /, or - on strings)
console.log(false == 0);
// → true (false becomes 0)

A neat tip is if you ever find yourself with NaN errors, keep in mind that further arithmetic operations on NaN keep producing NaN, so look where you might be doing any accidental type conversions.

It's also best to use the strict equal operator === as that allows you to precisely test for equal values and avoids automatic type conversion.

End of Chapter 1

That's it! As I get into the groove of writing these chapter recaps, I'll hopefully also learn to connect my notes. Currently, it's a little bit all over the place. I do hope you might've learned at least one thing. If anything was confusing here, please let me know, and I can try to explain further. Otherwise, you can check out chapter one on the author's website here.

Have you read the chapter? The book? let me know your thoughts in the comments, and if you think it's a great book to really master the fundamentals in JavaScript.

The next chapter focuses on Program Structure. We just learned about the nails; let's master swinging the hammer.

Originally posted on my personal website, which can be found at alex.kharo.uk.

When is your code 'good enough'?

Alex Kharouk — Sun, 12 Aug 2018 07:42:53 +0000

When do you decide your code is good enough? Is it after refactoring a dozen times or when you've check marked every task you had to do?

Is it when there's not a single error or are you just happy that it doesn't crash your terminal when you run it?

I ask because I've been reading Katrina Owen's and Sandi Metz's book titled 99 Bottles of OOP and they talk about what they think is good code.

As a beginner, I fall into the write the code; run it; pray category.

So tell me Devs. When do you decide your code is good enough?

Yesterday's Work Rewards Me Today

Alex Kharouk — Thu, 09 Aug 2018 17:45:18 +0000

I’ve been coding now for almost three months. Small change, little steps, I know. However this week marks the next step of my life as a software developer. I was accepted into a bootcamp in London. I’ve begun the pre-course work yesterday and am already making tidal waves of movement in my learning.

There are many posts about life as a web developer, or one’s process of getting that first job. I’ll be submitting this into the category of “the developer’s journey via bootcamp.” I think these are important posts. Bootcamps are expensive. So is your time. But you might want to go to a bootcamp. Hopefully I can give you some context of the journey.

First Two Weeks

I think a common trait that is shared amongst eager learners is ‘rapid passion.’ Passion that builds so fast that you just don’t know what to do with it. Maybe you write a song about it, or you build a project. You need some kind of outlet for all the passion. When I first started to code, I had the case of the rushin’ rapid passion. I created a simple website to display what I learned from a quick workshop at General Assembly. Then I moved towards a blog created on WordPress, where I posted about this HTML tag or that CSS attribute. I felt like I was learning enough to talk about it. Which is fine, even if I read it back now and think of how little I knew back then; the irony will be outstanding when I read this post a year from now.

Then as the first two weeks pass, there’s that dipping point. Many don’t make it back. That’s when you realise there’s more to programming than just HTML. There’s JavaScript and other languages. Front-end; Back-end. Full-stack or node stacks with a sprinkle of dated MEAN stacks. Keywords start to emerge, as if bidding you to come with them. Learn that framework or this language. This framework gets the $$$. That language is older than the person who wrote it!

All these words. They can overwhelm you. And it’s at this point the dipping occurs. The overwhelming world of software development comes at you, like paparazzi after a leaked affair.

During my first two weeks I thought I could do it all. Bought many Udemy courses, believing in those 99.999999% discounts they always claim to offer. Signed up to all the online courses. Even considered to enrol into a remote bootcamp right then and there. Luckily I took a step back. Since I already purchased the Web Developer Bootcamp for ten quid, I decided to only play with the thought of attending a real in-person bootcamp once I finish that course.

First Month Passed, Enter Month Two

Next thing I know, I’m out of that dipping point and into month two. At this point I’m really happy with myself. Six months ago I used to be the kind of guy who’d thankfully join the dipping crowd. Not this time. I stuck through it.

I’m even making great progress on the Web Developer Bootcamp. However I was going through the JavaScript material and it was tough. Terrifying. The instructor then introduced jQuery and I started feeling that overwhelming pressure of Imposter Syndrome. The whole time I was thinking damn, I have an english degree. Why am I even doing this?

Oh no. A second dipping point! This time I stepped back. Not to quit (although I contemplated the thought), but to try another language out. Now I doubt this is recommended by the pros, but it worked for me. I decided to try out Python. I even went to a workshop titled Python 101. Funnily enough it actually helped me grasp the things that confused me the most about JavaScript.

I started to see what Object Oriented Programming actually meant. And why everything is an object. I began to understand context, as well as scope. The clicks clicked. Later on, this will allow me to understand the Ruby fundamentals faster.

Now, whilst I have a better understanding, it’s not the perfect understanding. I don’t have enough experience with OOP, but at least I know the keywords to search for in Google whenever I have a question.

So Python helped me get back into JavaScript, and allowed me to continue the journey. Both languages went on hold as I begun to learn Ruby for my bootcamp.

Month Three is Just Around the Corner from Today

So I finished that course with a basic understanding of front-end and back-end. How APIs work and what are libraries and frameworks. Honestly, I’m really thankful for the course. It gave me a kind of TL;DR of what the Web Development World looks like. I didn’t absorb 100% of it, but it left me curious. Which leads me to why I’m writing this.

I never really thought about my future until last week. There was a time where I was in a rough spot, before I decided to make some healthy life-changing choices. It was during this transition that I discovered to code. Once I began feeling well-adjusted, with this ‘coding’ thing in my toolbox, I realised: Wow. I love this. I want this to be the thing I do for the rest of my life.

I finished the online course curious. I then finished a few other courses, still curious. Then I decided to take the step to join a bootcamp. Because I’m curious. Not only of code, and what languages can do, or what apps I’ll make, but I’m curious about the future. What I will see and do. Who I’ll become.

What do you think?

Do you agree with all the dipping points and high passion rates? Let me know if you think I’m terribly wrong. Or let me know if you want to mix it up, by reading my blogpost about Ruby Modules and Mixins on Medium.

Thanks for reading! I'm still new to this, but I hope I will continue.

Using Ruby for projects that are not Rails related.

Alex Kharouk — Sat, 28 Jul 2018 11:53:07 +0000

I'm currently learning Ruby in preparation for a boot camp I'm applying to. What can I create with Ruby that doesn't involve Rails?

As a beginner, I'm also curious what people use Ruby for nowadays when they're not using it for Rails (or Sinatra). Would love to work on a project this weekend!

Thanks and enjoy your day.