Forem: Aidi Rivera

Coding with ADHD: How do You do it?

Aidi Rivera — Thu, 09 Jan 2020 22:35:39 +0000

Time to get vulnerable!

I was recently diagnosed with ADHD. There. I said it. And it's been such a huge relief to know. I've struggled a long time trying to figure out exactly why I couldn't just do things that I wanted to do. It's affected me as a student in college barely passing my classes and now as an adult internally fighting to sit down and do my work. I can now finally validate and put a name to that struggle.

I've still managed to get to the point where I am now: excited (and intimidated!) as I search for my first big role as a software engineer. But getting to this point took a lot of managing my ADHD symptoms.

Since I couldn't really find anything as well organized as a basic listicle on how other ADHDers managed their work in tech, I wanted to share the ways that I learned to manage my own, both in front of and away from my keyboard.

But first I wanted to first ask the wider Dev community the big question and get some different advice and perspectives. So:

How do you do it? How do you manage your ADHD as a developer, engineer, or programmer?

But also...

How do you plan out your work to ensure you're focused on the right tasks and not getting distracted?
How do you manage your time to make sure you're spending the right amount of time on tasks?
How do you get past the don't-wanna-work-on-it mental blocker?
How do you prevent yourself from getting hyper-focused on that one little feature and then spending too many hours on it before realizing you've neglected other, more important, things?

Asking for a friend.

5 things you might not realize make your site less accessible

Aidi Rivera — Thu, 02 Jan 2020 16:55:21 +0000

I've been interested in coding and tech that's accessible but never had a chance to really dive deep into it and learn the practicalities of what makes a site accessible.

Working on a portfolio site I've taken the chance to learn the nitty-gritty of some tech I hadn't had a chance to play with before, accessibility design being one of them. It didn't take long for me to learn things I'd never considered, despite my continued interest in it throughout my career transition into programming.

Here are a couple of the things I've recently learned on, plus some of the issues I see come up that people might not realize hurt a site's accessibility.

1. Using `<div>` for everything

I always knew there were other, more semantic tags that should be used besides <div>, but it wasn't until I went out of my way to find some better, more specific tags that I realized just how many there were.

Some useful ones that I don't often see are:

<article> and <section>
<blockquote>
<cite>
<aside>
<time> And so many more!

They're used just like any other div tag but make content much more meaningful. It makes it easier to organize and quickly scan and know what each part of a site contains without having to scan the contents. This makes navigating through content with a screen reader a lot easier and faster, without forcing users to navigate through a hellscape of <div> after anonymous <div>.

Try to get as specific as possible with HTML tags and use the div tag as a last resort.

2. Design that relies on color with no text (or vice versa)

This one can be a little insidious because it feels like it makes a lot of sense, and as soon as you learn about it, it feels like it's something you already knew. But hear me out, because, despite this feeling like common knowledge, it's still something often forgotten about.

Screen readers can't read colors, which means users with disabilities or impairments that necessitate a screen reader won't know what information you're trying to show. Make sure you're using alt text for images that convey information and labels and names for everything else.

For those without screen readers, telling colors apart might still be a problem, so keep in mind what color combinations you're using.

The opposite can be a problem too. If you have a site that relies on text with no visual representation it can be difficult for someone who isn't a native in your language or simply for someone who forgot their reading glasses in the next room.

Obviously there are issues you won't always be able to work around. If your site's main purpose is geared towards English speakers specifically, having text (that can be screen read), probably isn't a problem you should worry about. But it's important to think about who your targeted user is and whether or not some of them might be limited by certain design choices.

3. Using the wrong kinds of icons and fonts

This one can be complicated because there are just so many different options for fonts and icons and icon fonts that it's easy to forget that a lot of these options, though very pretty and easy to use, aren't always very accessible.

One problem is that, for screen readers, certain icons will be skipped over or 'unpronounceable' or, maybe worst of all, actually read aloud. Fonts that are actually text embedded in images instead of being 'real fonts' also won't be read by a screen reader. This is where an alt tag would be necessary.

For users with reading or learning disabilities, certain fonts make reading unnecessarily difficult.

Instead, stick to some tested font guidelines that keep a site readable and look into using SVGs instead of icon fonts.

4. Not having captions or transcripts for anything with audio

For videos, captions are useful for so many reasons:

deaf and hard-of-hearing folks,
people with learning disabilities,
visual learners who need to read information instead of hear it (ironically, since videos are supposed to be a visual medium),
being in a noisy location,
being in a quiet location,
the video's language isn't the user's first and the words are needed to supplement their understanding,
and more!

If you have any video on your site, make sure there are good, accurate captions, or you're very much limiting how many users can interact with it.

Transcripts are good for any other audio files for the reasons mentioned above but are super awesome for people to browse through if there's a lot of info jam-packed in there. If there's a podcast that has some specific information I'm looking for, and I have to somehow try to find it somewhere in a 45-minute audio clip, I'm going to lose my friggin' marbles. Transcripts are good for videos too (even if they already have captions)!

5. Captchas

This was definitely something that never truly occurred to me until recently. Yes, they're annoying for everyone, but they're images. They completely restrict access for people with visual impairments. They can't answer whatever they're being asked to describe or which pictures contain a stop sign because they can't see the picture! Even the simpler point-and-click captchas can be difficult for folks who struggle with fine motor skills.

I know some captchas have a voiced option, which is great, but not all do. This one can be a tricky problem to solve because we do want to maintain site security, but not at the cost of excluding a disadvantaged population. So what are some other ways that won't unfairly restrict anyone's access?

This is something I myself would want to know more about and haven't seen much so far, so I'm interested if anyone has any experience or know-how on this.

This is definitely not an exhaustive list, and some of these issues go way deeper and complicated. These are some of the ones I've recently found most interesting/frustrating. What are some other accessibility issues you often see on the web that most people don't think of?

Signed vs Unsigned Bit Integers: What Does It Mean and What's The Difference?

Aidi Rivera — Sun, 29 Dec 2019 02:51:40 +0000

In my previous blogs, I gave an overview of what it means to work with an 8-bit, 16-bit, 32-bit, etc., number, or binary number, and how you would solve an algorithm problem that requires a certain sized bit integer without the computer science background knowledge to help make sense of it all. This post specifically tackles what exactly it means to have a signed or unsigned binary number. It won't change much the way integers are restricted when solving algorithm sets, but it will change the range you can work with dramatically. Then I'll use the same problem solved previously but accommodated to help solve for a signed binary integer instead of one that isn't.

What Does It Mean?

The biggest difference between a signed and unsigned binary number is that the far left bit is used to denote whether or not the number has a negative sign. The rest of the bits are then used to denote the value normally.

This first bit, the sign bit, is used to denote whether it's positive (with a 0) or negative (with a 1). If you want to get technical, a sign bit of 0 denotes that the number is a non-negative, which means it can equal to the decimal zero or a positive number.

(-/+)	2⁶	2⁵	2⁴	2³	2²	2¹	2⁰
0	1	0	0	1	1	0	1

010011012 = +7710

Note: I'm using the X2 notation for binary integers and the X10 notation for decimal integers.

Most importantly, the first bit used to denote sign means that we have one less bit to denote value. So if we have an 8-bit signed integer, the first bit tells us whether it's a negative or not, and the other seven bits will tell us what the actual number is. Because of this, we're technically working with a more limited range of numbers that can be represented; 7 bits can't store numbers as big as 8 bits could.

What's the difference?

Unsigned binary numbers

To review binary numbers, the ones and zeroes act like switches that metaphorically turn powers of 2 on, and then it's added up to create the decimal value. Normally, we'd "mark" a bit value with a one.

Example 1a:
Unsigned 01012 = 510

2³	2²	2¹	2⁰
0	1	0	1

Example 2a:
Unsigned 10012 = 910

2³	2²	2¹	2⁰
1	0	0	1

Signed binary numbers

Example 1b:
Signed 01012 = +510

(-/+)	2²	2¹	2⁰
0	1	0	1

When a signed binary number is positive or negative it's 'marked' with a 0 or 1 respectively at the first far-left bit, the sign bit. The number above doesn't change at all. It's just more explicitly a positive number.

Example 2b:
Signed 10012 = -710

(-/+)	2²	2¹	2⁰
1	0	0	1

But the above binary number completely changes. And we're now representing a negative!

Negative binary integers

When a binary integer is negative, the zeroes will now act as a "marker", instead of the ones. You would then calculate the negative binary number in the same way you would with a positive or unsigned integer, but using zeroes as markers to turn bit values "on" instead of ones and then adding the negative sign at the end of your calculation.

(-/+)	2²	2¹	2⁰
1	0	0	1

Signed 10012 = -710

Going from an unsigned binary to a signed binary integer changes your end value in a couple of different ways. The first is the more obvious change in value when the first bit is used to denote sign instead of value. You can see between example 2a and 2b above that it means if you had a one at the first bit of your 4-bit integer, you're losing a value of 2³ that would've been added to your end value with an unsigned bit, but is now instead used to represent a negative. With a larger bit integer, that could be an extremely larger value that you lose the ability to represent.

Something else that isn't obvious right away is that you calculate a negative binary integer's value starting at 1, not 0. Because the decimal zero is not included in a negatively signed bit integer, we don't start counting at zero as we would when it's a positively signed bit integer.

To explain that quirk let's compare positively and negatively signed integers. Working with a 4-bit integer, if we had four bits with a value of zero, the number would equal to 0. That's the lowest value we can have. Because a non-negative signed bit means we can have a positive integer, or a 0.

0	0	0	0	= 010

A 4-bit negative integer of four bits of one values (the ones now being the "off switch"), the number would not equal 0, but -1. Which makes sense, since that's the highest decimal number we can represent while still having a negative.

1	1	1	1	= -110

But that means, when we're adding up our values to get our final decimal number, we start our counting from 1, not from 0.

2^x	(-/+)	2²	2¹	2⁰	Total
bit-value	0	1	1	0
2^x x bit-val =	+	4	2	0	*= 610*

So even if I were to perfectly flip the "switches" from the positively signed binary number above into its negative counterpart, it would not perfectly switch to its negative decimal counterpart value in the way one might expect:

2^x	(-/+)	2²	2¹	2⁰	Total
bit-value	1	0	0	1
2^x x bit-val =	-	4	2		*= -710*

Why??

Because we're adding starting with a value of 1! And we're adding up the values that are represented in our bits before adding a negative sign at the very end of our calculation.

Here's a visual comparison of the decimal and binary equivalents that show how a 0 signed bit integer is the decimal 010 or larger, while a 1 signed bit integer is decimal -110 or smaller.

Alternatively:

Another way to calculate the negative is to keep using the ones as 'markers' and use the sign bit as a marker for the value at its corresponding power of two at a negative value. This also illustrates a different way to understand what's going on in binary negative representations.

2^x	(-/+)2³	2²	2¹	2⁰	Total
bit-value	1	0	0	1
2^x x bit-val =	-8	0	0	1	*= -710*

This way of calculating the decimal value might be a little easier when working with smaller decimal numbers, but then becomes a little more complicated to do some mental math when you're working with bigger decimal numbers:

2^x	(-/+)2⁷	2⁶	2⁵	2⁴	2³	2²	2¹	2⁰	Total
bit-value	1	1	1	1	0	0	1	0
2^x x bit-val =	-128	64	32	16	0	0	2	1	*= -1410*

Thankfully, there aren't a lot of situations I can think of where you'd have to interpret between the two without a calculator handy!

Finding the max and min with signed binary numbers

The range of positive decimal numbers that can be stored in any sized bit integer is shortened by the fact that the first bit is used to denote sign. This means that, in the case of a 32-bit signed integer, we are actually working with 31 value bits instead of 32, and that last bit could have stored an exponentially bigger integer. In fact, this completely halves the range of positive integers we can work with compared to a 32-bit unsigned integer. That one extra bit would have doubled our max possible integer, and without it, we lose the ability to store as many positive integers.

On the other hand, we gain the ability to store a bunch of negative integers that we couldn't have before with an unsigned bit integer. In the end, the size of the range we work with is kept the same, but the range moves to account for being able to store both positive and negative numbers.

Let's look at a 4-bit unsigned vs signed integer. Our range might move, but the amount of integers that can be stored don't actually change.

Because of this loss of a bit, our maximum is calculated by 2^{bits - 1} - 1, or, if working with 32-bit integers 2³¹ - 1.
I explained why we have to subtract the one last time, which we still have to do since we're including the zero in the range and not subtracting would cause one extra bit to be needed to store that number.

Our minimum in the range is the inverse, -2^{bits - 1}, or, if working with 32-bit integers, -2³¹. We don't subtract one for our minimum range because the zero is not included and we start counting from -1. This gives us that one extra negative number in our range that can be represented.

Seeing the range above might help visualize why there isn't a subtraction from the lower range while there is for the upper range. Zero is included in the green range, but not in the red range of signed bits. We start at -1 and can have the same amount of numbers represented as non-negatives.

								*	*	*	*	*	*	*	*
-8	-7	-6	-5	-4	-3	-2	-1	0	1	2	3	4	5	6	7

Here we have 8 positive integers.

				*	*	*	*	*	*	*	*
-8	-7	-6	-5	-4	-3	-2	-1	0	1	2	3	4	5	6	7

Here we have 8 positive and negative integers. But still only 8 total integers.

The problem

Going back to the problem solved in the last post, this time the solution will involve creating a restricted range for a signed integer.

Given a 32-bit signed integer, reverse digits of an integer.

We know this is a 32-bit integer with 32 zeroes and ones, the very first of which is denoting the sign.
Working with 31 bits that could represent the value of the number, the biggest positive binary integer we could have would be 31 ones after the first, sign bit of zero, which gives us a positive sign.

This means the largest decimal number we could deal with would be 2³¹ - 1, or 2,147,483,647

The largest negative binary integer (and by largest I mean smallest?) would be 31 zeroes with the sign bit being a one, telling us it's negative.

This means the smallest decimal number we could deal with would be -2³¹ or -2,147,483,648

The solution



const reverseInteger = (x) => {
    let reversed = "";
    strx = x.toString();
    for(let num of strx){
        reversed = num + reversed
    }
    reversed = parseInt(reversed, 10);
    if(x<0){
        reversed = reversed * -1;
    }
    //Setting the range!
    if (reversed > Math.pow(2, 31) - 1 || reversed < Math.pow(-2, 31)) return 0;

    return reversed;
};

The problem is essentially asking to make sure we don't return a number that can't be stored as a 32-bit signed integer. Here we're skipping how to actually solve this problem and focusing on the range since I've walked through the solution previously.

The line right before the return checks whether the end integer contained in reversed is within range. If reversed is greater than 2³¹ - 1 OR less than -2³¹, it returns 0.

If this were an unsigned 32-bit integer, there would've been a range from 0 to 2³²-1, or 4,294,967,295. That upper range is twice the range of 2³¹. You can think of that missing "half" of the range that would have stored those positive numbers as being used to store your negative numbers instead. Same-sized range, just different start and endpoints in that range.

Fin!

That finishes my series on binary numbers for the average non-computer science degree holders!

This was a really fun (and frustrating) learning process. I fully expect there to be holes in my overview as there's just way too much to cover without going unnecessarily in-depth.

I want this to be a good jumping-off point for those who want to know the basics so if there's anything that wasn't clear (or I assumed you knew something that you didn't), let me know!

Happy Coding!

Resources:

Reverse Integer LeetCode Problem
Signed Binary Numbers
Decimal to Binary Converter
Signed Numbers - Watson
Rounding Algorithms 101 Redux - EETimes
Bits, Bytes, and Integers - Carnegie Mellon

x-Bit Integers: Solving With A Range

Aidi Rivera — Tue, 17 Dec 2019 03:42:34 +0000

In my previous article I gave a short introduction to what x-bit and binary integers are for those who might not have a computer science background. I sorta knew what binary numbers were and the whats and whys but I didn't really know. Not enough to do anything with them, at least.

So this time I'll cover how to deal with problems that are asking to account for 8, 16, 32, or 64-bit integers.

Max and Min Range

The most common way I've seen x-bit integers used in algorithms is as a note on the bit range of integers that the function will accept or return. It might look something like this:

the problem

Given a 32-bit integer, reverse digits of an integer.

The first time I saw this, I completely ignored it because - wut?

But as soon as I did some research I realized it's all about the size of the integer. In this case, the integer the function can return will be a 32-bit integer. That means any decimal number whose binary equivalent is larger than 32-bits can't be returned.

Note: This will cover how to deal with unsigned integers, which means every bit we deal with in a 32-bit integer is a binary digit of one or zero. I'll be covering how to deal with signed integers in my next article.

From my previous article, we know a 32-bit integer is a number that's represented by up to 32 different binary values (zeroes and ones).

A 32-bit number with 32 ones and zeroes: 11001001101010010100100001110100.
It's decimal equivalent is 3,383,314,548.

And remember, we get the decimal by adding together the product of each binary value times it's corresponding 2 power.

Binary power	2³¹	2³⁰	2²⁹	2²⁸	2²⁷	...	2¹	2⁰
Binary Digit	1	1	0	0	1	...	0	0
Multiplication!	1x2³¹	1x2³⁰	0x2²⁹	0x2²⁸	1x2²⁷	...	0x2¹	0x2⁰

Added Total!								3,383,314,548

So here's where we begin our range. The biggest 32-bit binary integer we could have would be a binary integer of 32 ones. And the largest decimal number we could deal with would be 2³² - 1, or 4,294,967,295.

Wait. But why subtract the 1?? Here's one way to think of it: when you and I count, we start from 1, so if someone were to tell me to count all 2³² numbers, I would start at one and get to 4,294,967,296. But computers start counting from 0. They would count the same amount of numbers, but because they started at 0, they would stop at 4,294,967,295, or 2³² - 1.*

Here's another way to think of it. The largest 3-digit decimal is 10³ - 1, or 999. If you didn't subtract the one you'd have 1,000, which is now a four-digit number. Same case here, except it's a 32-digit binary number (binary digits) and if we didn't subtract the 1, it would become a 33-bit number.

With all this new-fangled knowledge in hand, let's try to solve this problem!

the solution

const reverseInteger = (x) => {
    //Step 1
    let reversed = "";

    strx = x.toString();
    //Step 2
    for(let num of strx){
        reversed = num + reversed
    }
    //Step 3
    reversed = parseInt(reversed, 10);
    //Step 4
    if(x<0){
        reversed = reversed * -1;
    }
    //Step 5!!
    if (reversed > Math.pow(2, 32) - 1 || reversed < 0) return 0;

    return reversed;
};

Here's a walk-through to make clear what's happening.

Sets up an empty string variable reversed and then creating a variable strx that represents the string of the integer x passed in.
Iterates through all the digits in the string and concatenate each digit to the end of strx.
Turns reversed string back into a base-10 integer. (parseInt will ignore any part of the string that is not a number, so any negatives (-) will be ignored.)
If integer x is negative, turns reversed into a negative.
The important bit! This line checks whether the end integer contained in reversed is within range. If reversed is greater than 2³² - 1 OR less than 0 (which will also surpass the storage limit of 32 bits), it returns 0.

the warning

If you were to actually go to try to solve this problem on Leetcode you might notice there are some differences between it and the problem I set up in this article.

Given a 32-bit signed integer, reverse digits of an integer.

The original problem talks about a signed 32-bit integer. In a nutshell, it means there is a bit in your binary integer that denotes the positive or negative sign of your integer.

This ends up adding a layer of complexity that slightly changes how you'd deal with and solve for bit integers in algorithm sets. It's nearly identical to what I've covered here but just different enough to be worth a third article on the subject.

* In a previous version, I said that to get the range you would calculate '2³¹ - 1' because we're counting from '2⁰', which in a way is true because of the fact that the 32nd bit is calculating 2³¹. But the addition of all those bit values will, in the end, equal to 2³², NOT 2³¹.

Resources:

Intro to X-bit and Binary Integers

Aidi Rivera — Thu, 12 Dec 2019 22:55:31 +0000

Being able to whiteboard a solution to an algorithm problem is still a prevalent gate-keeping strategy for a lot of tech companies, and knowing how to solve them is crucial to getting that job you want.

But for those like me who didn't go through a traditional computer-science or technical degree route, there might be some gaps in knowledge that make solving some of those problems a real struggle.

Binary and 'x'-bit integers is one of those struggles for me. Or, it was. Hopefully, I can give an overview explanation that will help others understand what they are and why they matter.

What does it all mean?

First of all, when you see 'bits' or 'binary,' they're essentially talking about the same thing. 'Bit' is short for 'binary digit.' Bits are the smallest unit of data in a computer and represent a single binary value: a 1 or 0. So that long string of zeroes and ones you see? That's binary. And every single one (or zero) is a binary digit or bit.

So what's a binary integer? It's the binary representation of a decimal integer. And what's a decimal integer, I hear you shouting? Don't worry, it's simply the technical term for the everyday integers we work with. Decimal numbers are base-10 (base10) numbers, meaning they're represented in chunks of ten with numbers 0 through 9. Binary numbers, on the other hand, are base-2 (base2) numbers, represented with 0 and 1.

So taking all that information together:

Decimal10 Number	Binary2 Number
14	1100
125	1111101
2	10

Most computers support integers that are 8, 16, 32, or 64 bits. (Notice that they're all 2 at different exponentials: 2³, 2⁴, 2⁵, and 2⁶, respectively.) If someone says that only 32-bit integers are supported, it means that only integers that can be represented with 32 individual bits (32 zeroes and ones) can be used.

But how do you know what numbers are what bits?

Translating binary numbers

Each zero and one in a binary integer represents a 2 at exponential powers. Starting from right to left, it starts with 2⁰ then continues with 2¹, then 2², 2³, and so on. It could go on forever but let's look at only 8 bits for now. It'll look like this:

2⁷	2⁶	2⁵	2⁴	2³	2²	2¹	2⁰

But because we'll be dealing with math soon let's simplify it to:

128	64	32	16	8	4	2	1

From binary to decimal

Say we have a binary number of 1100010 that we want to translate to a decimal number. We're going to plug in the ones and zeroes starting from the far right.

128	64	32	16	8	4	2	1
0	1	1	0	0	0	1	0

Technically there is a zero in the far left, but, like with decimals, you only really care about that first not-nothing value, which is the 1 at the 64 position.

Here we'll be doing math by multiplying each bit value with its corresponding 2 exponential then adding it all together.

2^x	128	64	32	16	8	4	2	1	Total
bit-value	0	1	1	0	0	0	1	0
2^x x bit-val =	0	64	32	0	0	0	2	0	98

The number's 98!

From decimal to binary

There are a few different ways of doing the math for this one but the one that feels easiest for me is a check-and-subtract strategy.

Say we have a decimal integer (X10) of 112 to translate into a binary integer (X2). Since we know we're working with 8-bit integers (or smaller), we can start from the left and see if we can subtract by the 2^x exponential without getting negative. If you can, that's a bit value of one.

X10 remainder	112	112	48	16	0	0	0	0
2^x	128	64	32	16	8	4	2	1
X10 - 2^x =	-neg	48	16	0	-	-	-	-
bit-value	0	1	1	1	0	0	0	0

Your binary integer is 1110000!

If you want to play around and try to translate between binary and decimal integers, this nifty calculator helps!

Why does it matter?

It's important to get a basic understanding of bits because they are the basis for all data on a computer. All data takes up storage space but using less space when programming is always ideal.

When you're dealing with integers, you want to make sure you have enough space to store any integers you're working with. At the same time, you want to make sure you're not using more space than you need. Efficiency!

If you're working with integers that are never going to go past 100, you won't need anything larger than an 8-bit storage space.

When solving algorithm problems, it's good to know what the time and space complexities are of the algorithm. When you know that, you'll know how fast or slow your program might run and how much space it will need to run.

Because of this, you'll come across problems where you'll have to take into account space restrictions, which might mean you'll want to restrict the bit-size of your integers.

This only really scratches the surface of binary integers. But for those without any background knowledge, this is a good start. To account for space and the bit size of integers when solving algorithms, you'll have to go a little deeper. But with this in your pocket, it should make it a little easier to understand.

I go deeper into bit integers in my next blog: x-Bit Integers: Solving With A Range

Learn From My Mistakes: My First Take-Home Code Challenge

Aidi Rivera — Mon, 02 Dec 2019 07:04:05 +0000

After a successful phone interview, I was given my very first take-home code challenge last week. Listening to my interviewer explain the assignment, I was pretty confident. It was to be a login page with some basic validations on a form that took an email and a password. You say it should take only 2-3 hours, Mr. Interviewer? Oh, cool. Then I'll have plenty of time to get it done in the 2 - 3 days he said it should take. No problem. He even gave me a link to his company's login page as an example to work off of. Awesome. Nice and simple.

After three hours I was still hip-deep in "research" (that is, manically perusing StackOverflow and how-tos) on form validations and only starting to realize that maybe I hadn't approached this take-home in the best way.

In the end, I did have a fully functioning login page with all the requisite validations deployed and sent within the time-frame given, but I learned a lot about myself and about what I would have done differently for the next time around. So here I impart some hard-earned tips to other junior devs just entering the wild jungles of job hunting.

1. Ask questions

I sent a response thanking them for the opportunity and restating what day I'd send them the completed challenge, but I wish I'd taken that chance to include some basic questions about the project. Of course, I'd already asked all the questions I had over the phone -- until right after I sent that email that is. And then I was too embarrassed to tail that email with a "Btdubs I'm not 100% on this one thing" after already sending a super confident email like I knew exactly what I was doing. But I can only imagine how much more confidence I would've had if I'd just sucked it up and asked the questions that I'd had.

After getting the challenge and before you do anything else, prepare some questions to ask about the challenge. Even if you don't actually have any questions, you do. Think about what you need to do and get done, and if there's any doubt in your mind about what's expected of you, ask. At the very least, it's always a good idea to ask some clarifying questions about what you do know of the project to make sure everyone is on the same page. "Just to clarify, the challenge is to have a login page that does [this thing] and [that thing] and sent to you by next Friday the 6th. Is that all correct?

Asking questions is never a bad thing. It shows that you're paying attention and can communicate well with people, which makes you look good*. You'll catch preventable mistakes and learn better*. It even helps you better connect with people by being more likable*. If you take anything out of this list, let it be this one, and apply it to the rest of your career.

2. However long you think it'll take you? Double that

I took to heart the "2-3 hours" that my interviewer guessed it should take to complete. It did not take me 2-3 hours. I was working on it up to the deadline I'd given myself and my interviewer. I severely underestimated how long it would take me, and I constantly wondered whether I'd actually get it done in the time I'd given myself.

If you think something will take a few hours, give yourself a whole day. If you think it'll take you a day, give yourself at least two. And be realistic with yourself. Don't be scared to ask your interviewer for more time; they likely know that you're busy and might not have the time to commit. And, inversely, don't give your interviewer an unrealistic timeframe because you want to impress. It'll be more damaging to your application if you're late on an early-set deadline than whatever gain you might get by setting it early. But it's great if you give a later deadline and send it in early.

It doesn't matter how confident you feel about a take-home challenge, give yourself that extra time just in case. Things happen unexpectedly, and you don't want your first impression to a potential employer to be of someone who can't meet a deadline, even if you have a legitimate emergency. I think there's a good reason why Hofstadter's law is well-known in the programming community:

It always takes longer than you expect, even when you take into account Hofstadter's Law.

3. Hold yourself to a sooner deadline

In contrast to the previous tip, make sure you give yourself less time as well. Though I was working for longer than I thought on my first take-home, I'm glad I gave myself the deadline that I did. I had to finish by that time or else end up looking uncommitted and disorganized, but it also meant that it was done and over with before the start of a long holiday weekend. Instead of worrying and trying to get it done while everyone else was enjoying their time off, I got to send it off and join in without having to think about it again.

I know, I know. I just said to double the time you think you need, but that's only with the company you're interviewing with. Tell them you'll be done in 4 days, but hold yourself accountable for getting it done in 3. Don't cancel your plans to give yourself more time. Use your own busy schedule to hold yourself to an earlier deadline. If you think something will take you a day to do, give yourself two days, but do it in one.

Just as Hofstadter's law says it'll take you longer than you think, Parkinson's law says it'll take you just as much time as you give yourself to do it.

Work expands so as to fill the time available for its completion.

So if you give yourself a whole week to do it, guess what? It'll take you the whole week to get it done. Trick your way into giving yourself a sooner deadline while still giving your interviewer a later one, making sure you're covered in case of emergency (or, more likely, finicky code) and helping you look better by getting it done early.

4. Use examples you're given - Emulate the company's brand

As an example, I was pointed to the company's own login page. It was simple enough in style that I thought I could replicate it. I then went ahead and did. It ended up looking a lot more polished in a less amount of time because I wasn't thinking about what looked good. They'd already done that for me. I just had to prove that I could do it.

If you're given an example of what they expect, then try to get as close to that example as you can. Use the company's brand colors and logos. Try to get your code to behave in as similar a way to theirs as possible.

There is the worry that maybe they want to see how good you are with styling and design, but unless the job is specifically for design or UX/UI, I don't think that'll ever be the case (and if in doubt, ask!).

5. Don't focus so much on the "correct" way to do something

I spent so much time looking for the 'correct' way to validate a form. I constantly threw out ideas from articles and guide-throughs because they were too complicated, or not right for what I needed, or used too many extra packages that essentially did the validations for you (which was not the point of my take-home challenge). In the end, I never did find the "correct" way.

Look at examples if you need it to jog your memory or guide you, sure, but don't try looking too hard for how to make this feature or that. There are so many ways to program one thing, at some point you're going to have to pick a starting point and just start. You'll never find the youtube video that will write your take-home for you. That's not the point, anyway.

Plenty of people on Stack Overflow would disagree, but I will insist, for sanity's sake, don't try looking for the perfect way to code something. There is no perfect way. With take-homes, you're in a situation where you're trying to showcase your skills by making a small, sometimes incomplete project. Sometimes that actually means using a less convenient way to code something. So trust yourself and your knowledge and do it in the best way you know how to.

6. Test your code

This was something my interviewer explicitly asked for in their requirements of the take-home challenge. If he hadn't, I wouldn't have thought of adding a test in at all. I don't have much experience with testing, so I'm grateful it forced me to practice and think more about the way I wrote my tests.

Try to create at least one or two tests for all your take-homes, if time permits. And if you don't know how to just yet, take the time to learn.

Finding a guide to get you started can have you adding some basic tests to your apps pretty quickly. Knowing how to test your code is becoming something employers commonly require, even if it's not something that's actually used on the job. Even when tests aren't expected with your take-home, it's a good opportunity to practice while working with a small project. Plus, though it might not be expected of you, it'll always look better to include them than not.

7. Comment your code

As you code, make sure you go back and leave comments on what a function or component is trying to achieve and if you want to be more explicit, how it's doing it. Be clear and concise in your explanations. Pretend you're explaining to someone who only knows the basics of programming. Things that might seem obvious to you aren't always obvious to others. Don't try to guess what people will or will not understand easily. Assume nothing will be.

Comments aren't just for whoever will see your code but for Future-You as well! This is a good practice to have always, but it's especially important for take-home code challenges. Companies want to know how you code and what your thought process is. Comments make it that much easier for them to see that.

8. Stop doubting yourself

There were so many times I wondered if maybe I wasn't doing things the right way (see #5). I wondered what it meant that I was taking so long to complete the challenge. I wondered if maybe I wasn't as capable as I'd previously thought. In the end, I saw myself struggling and made sure I actually learned how to do what I struggled with. I made it a learning experience for validations. I took it as a chance to practice making forms, something I realized I hadn't done in months. I made sure I got something out of the experience and made something I could hold up and say, "Hey, I made this neat thing", not just a code challenge that would be hidden away and forgotten afterward.

Don't overthink things. Don't doubt yourself. Whether or not your code is good enough isn't up to you, it's up to your interviewer. Don't hold yourself back by judging yourself as inadequate before anyone else even gets the chance to. All you have to do is do what you can, show your best self, and let the interview process decide what your options are. Take-home challenges are a way to judge your skills, but they're also a great way to learn and improve them. Take advantage of that chance.

9. Don't spend too much time on it

This, I definitely learned the hard way. I spent way more time than I needed to, especially considering the 2-3 hour expectation my interviewer gave me. I spent an extra hour or two on styling alone, something I'm not sure was really worth it (unless they were to say it was, then yes, totally worth it!).

Spend as much time as you can to make the code-challenge one you can be happy to send back, but don't sacrifice time on your other commitments (and potential job interviews) to spend all week on this one. Don't expect that of yourself because most (decent) companies won't expect that either.

There comes a point where more time spent on the take-home will not be worth what you get out of it. Consider your circumstances: chances are you're in the middle of the jungle of job hunting. You have other companies that you're looking at, other resumes to fill out, and other people to connect with. There are only so many hours in the day. Sending back the best code you can code is a big factor in the interview process, of course, but it's not the only one. And if a project they say will take you a few hours takes you a whole week, then that's something to consider. You might end up with a job that expects too much more than what you can deliver, or maybe the company isn't organized enough to know what to reasonably expect from someone in a given timeframe. Either way, it's a good tell that something's not quite right.

Some of these lessons are things I wouldn't have ever gotten the chance to learn before my first take-home and some are things I knew but easily forgot to put into practice. Take-homes can be difficult and intimidating and confusing but they can also be fun and a great chance to practice and flex your skills. Plan ahead, expect things to go wrong, and just keep yourself open to learning.

Happy Coding!

*Photo by JEShoots.com on Unsplash

New To React Native? Do It With Expo.

Aidi Rivera — Mon, 25 Nov 2019 01:13:11 +0000

This is a short, basic guide on how to get you started with your React Native app using Expo. Don't know anything about Expo or React Native, but still insist on using it? Perfect, this is for you. I'll explain what Expo actually is and why you want to use it, the whats and whys of installation, and then the practical bits of how to install and create an app. This is your absolute first baby step in this process.

I've lately noticed that every time I go back to visit my old bootcamp, I'm inevitably directed to a student with questions about React Native. They're starting their final project soon, you see, and they're thinking of taking the plunge with React Native. There's always someone with questions and not a lot of people around with answers, until someone like me comes along and suddenly I'm the old crone who's been there, done that and the local expert to boot, because I went through the gauntlet of creating a React Native app for my own final project. I'm not an expert, by the way, but I always try to help where I can. Considering I can't always be lurking around campus, I thought I'd be most useful by writing some blogs about React Native. This is for those students who need a little help getting started, by a former student who was very much overwhelmed by it all the first time around.

What is Expo?

Expo is a framework and a platform that helps you develop React Native apps. A bit like Rails for Ruby and create-react-app for React. It helps you build the basic scaffolding of your app without you needing to understand everything beforehand; great for students with a deadline.

Expo continues React Native's pursuit in creating universal apps that work with both Android, iOS, as well as web apps. All from the same code. That means built-in tools Expo uses, like icons, are also made to be universal.

Expo helps you develop and run your app, whether as a snack, with a simulator or through their client app. Expo comes with a lot of tools at your disposal.

I'll be skipping over all of these tools to focus on what a student with a time crunch would need and only tell you that they're there, in case your specific project needs them.

The good thing about Expo is that it's easy to use and great for those who want a quick introduction to React Native and mobile apps in general. Expo's documentation is excellent, and they guide you most of the way through the setup and creation of an app with Expo. And because Expo is big on creating apps for any device, you can test a simulation of your app through Xcode, Android Emulator or web at any time in the development process and develop from any environment as well. You don't have to do much with Expo.

On the other hand, because Expo does so much for you, you don't always have a concrete understanding of what's going on 'under the hood.' Which might be fine but could be a big crutch if you ever need to develop without it. Heavy libraries and a complicated Expo-specific deployment process might also make Expo not worth it in certain circumstances. My worst complaints were the vague error messages and the buggy live reloading which could force you to rebundle and relaunch your app every time an error caused it to crash. Definitely have a debugging tool at your disposal.

Using Expo

The basic flow of development would include running your app with live reloading, either through the Expo client app, with the Android emulator, iOS simulator, or with your web browser. And you can switch between any of these!

What Is Expo?

Installation

Before you get started make sure you have Node.js installed, which you'll be using to install the Expo CLI. Expo will be creating your app for you, so there is no react-native command to start you with.

npm install -g expo-cli

And that's it!

Creating Your App

To create a new project, run expo init and the name of your project:

expo init ProjectName

Managed or Bare?

This will prompt you to choose a template. There are a few different options, first between a "Managed Workflow" and a "Bare Workflow". The managed workflow is what helps build out the skeleton of your app without you having to do much work. Unless you're an experienced React Native developer, that's what you'll probably want to use.

Blank or Tabs?

Then you'll need to choose between a 'blank' template or a 'tabs' template. The difference is about as you'd expect; one has tabs and one doesn't. But there's more. What it really means is that the tabbed template comes with React Navigation already installed and sets you up with different screens and a tab-style navigation. You may or may not want this option depending on your project. React Native Navigation and screens are, in my opinion, the trickiest difference between React and React Native.

If you know you'll be using different screens in your app, choosing the tabbed template would give you the chance to have the overall setup already done (like below), and all you'd have to do is figure out how to work upon what's already there. But if you know you aren't bothering with screens and React Native Navigation, I'd consider the blank template as shown above, as it would otherwise add a lot of unnecessary complexity to your app.

Some things to note before starting:

First, know that there are different tags used in React Native than what you would use in React. The div tag doesn't exist in React Native but is replaced with a View tag. There's a ScrollView which you would want to use if you want your user to be able to interact with the screen with a scroll. Thankfully, the Button tag does what you would think! But for anything else that you want your user to touch and trigger something that isn't a button, you'll want to use the TouchableOpacity or the TouchableNativeFeedback tag.

You've taken your first baby step! Hopefully, you're comfortable so far and have a good idea of what's going on. From here on out will be the actual building of your mobile app. Good luck and have fun!

Resources:

5 Ways to Keep Going During Your Last Weeks of Bootcamp

Aidi Rivera — Mon, 29 Jul 2019 02:28:41 +0000

You're nearing the end of your bootcamp program. You're starting to slow down, you're feeling pretty apathetic about your code and your projects. How do you keep going when you're feeling burned out?

Remind yourself of where you started.

Chances are, you’ve vastly improved your coding skills during your time at a bootcamp. Take some time to remember where you started and compare that to your coding abilities today. Pretty rad, right? Give yourself a pat on the back, you’ve come far.
Think of how much further you’d like to go.

It’s easy to look at all your progress and have a ‘good enough’ feeling and just coast for the next few weeks of your program. You're thinking: it’s been difficult, I'm tired, I’ve worked my tail off getting to where I am, I need a break. There’s nothing wrong with taking things a little easier if that’s what you need to stay sane, just don’t let yourself label things done prematurely. Every week at your bootcamp counts. As accomplished as you feel now with all that you've managed to learn, imagine: you’re not done learning.
Look at all the baby animals.

Things are getting harder to manage, you’re feeling the strain, you’re stressed. Do whatever you need to keep yourself emotionally and mentally strong and positive. Sometimes you need something to remind you of the world outside of coding, deadlines and tests. To remind you that things are gonna be ok. And a great way to do that is to look at cute things that make you squeal in joy and lift your spirits. Also, the Wholesome Memes on Reddit and Tumblr are pretty great.
Take care of your body.

For all that’s good and holy, I beg of you: get out of your chair and step outside. Go for a walk, interact with people and talk about something that’s not about what you’re working on. Eat food with colors. Stretch. Don’t forget to take care of yourself just because you can see the end on the horizon. That last stretch is long enough, so don't forget about yourself and your health, else you’ll cross the finish line by face-planting through the tape. If you’re struggling with the basics, here’s a how-to to get you started.

Keep in mind that the end of your bootcamp is the beginning of something else. And on that note...
Plan out the day after your bootcamp.

You don’t actually need to know exactly what you’re going to do the day after your last day of bootcamp. But it’s a good idea to have a concrete plan for the days after. Even if those plans involve sitting on your couch in your underwear vegging out on Oreos and Netflix. But if those are your plans, make sure you give yourself a time frame. When will your veg-out be complete? Whether it’ll be a day or a week, plan it out now. You went to a bootcamp for a reason. What were those reasons and what do you still need to do to fully realize those reasons? Knowing this and planning accordingly will help you keep up your momentum.

You've still got some work ahead of you, but at the end of the day, you'll have done something really amazing and difficult. You're almost there so keep it up and, as always, Happy Coding!

The Name's CORS. Rack::CORS.

Aidi Rivera — Wed, 17 Jul 2019 22:41:42 +0000

My latest project required using Rails to create an API backend. Ruby has a nifty --api flag that creates a repo with only the folders you would need. It cuts down a lot of the extra folders you would get when normally creating a new Rails app. It also automatically adds a line into your gemfile to include Rack-CORS.

Following instructions, I uncommented rack-cors in my gemfile to make sure it was "working" and copy-pasted some extra code into my application.rb file "to allow CORS to work". Done. Cool.

As usual, I was absolutely baffled. What had I just done, what was anything actually doing, what did any of it mean and what even was the meaning of life?? I moved on and hoped I'd understand later on.

I never really got that explanation. So I decided to research it myself. I regretted it instantly.

What is CORS?

Anytime you want to bring resources into your web app that come from different origins, you'd implement Cross-Origin Resource Sharing, or CORS for short. CORS has standardized the way we retrieve cross-origin resources. How? …

"...it uses additional HTTP headers to tell a browser to let a web application running at one origin (domain) have permission to access selected resources from a server at a different origin."

What this means is that CORS is going ahead and telling your browser which resources your app is allowed to access when it's trying to access a resource that is not at its original domain (aka cross-origin).

And the only reason CORS even needs to do that is because of the Single-Origin Policy, which states that only resources from a single origin can be requested. Browsers abide by this policy by default for obvious security reasons. But that means we need to somehow figure out how to allow the cross-origin requests we do want to go through.

We do that by including the right CORS headers into our request.

Side note: JSONP (JSON with Padding) is another way to resolve the same-origin policy. Because HTML script tags are an exception to the cross-origin restrictions, JSONP simply turns data into an HTML script tag to bypass the single-origin policy. It's admittedly a bit “hacky” so not really used anymore unless a browser doesn't support CORS. *

What's Rack::CORS?

Rack::CORS is a middleware gem for Rack compatible web apps that helps you more easily implement CORS. It breaks the things down and turns making those cross-domain requests a cleaner and easier process. Plus, the error messages are super helpful.

How To Use It

The documentation for Rack CORS is helpful in explaining what to add where, but if you don't know much about CORS in general, it can be difficult to understand what you're looking at.

First, as the documentation explains, you want to open your config/application.rb file and add something like this into your code:

config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins 'example.com', 'localhost:3000'
    resource '/publicStuff/*', headers: :any, methods: [:get, :post]
    resource '/myStuff/*', headers: :any, methods: :any
  end
end

The first line uses insert_before 0 so Rack CORS can run before any other middleware that might interfere with it.
Line three is where you define which origins your app will accept resources from. This will be the domain name of the origin(s) you want to let through.
Line four is doing the same thing except we're defining the resource(s), or path(s), that we want to allow through.
In the same line you've defined your allowed resource path(s), you'll define which request parameters to allow. Most likely you'll be using the methods and headers parameters. If you want to allow multiple methods, you'd use the bracket notation to list your methods: methods: [:get, :post, :options]

Let's look at the above example again and break things down.

config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins 'example.com', 'localhost:3000'
    resource '/publicStuff/*', headers: :any, methods: [:get, :post]
    resource '/myStuff/*', headers: :any, methods: :any
  end
end

It allows requests from the example.com domain or from localhost:3000.
The paths allowed are:
- any path that starts with /publicStuff/ and
- the /myStuff/ path.
- These possible paths could look something like example.com/publicStuff/records/ or localhost:3000/myStuff/.
For the '/publicStuff/' path it allows requests with any header, but only allows requests with the GET and POST method.
Requests for the '/myStuff/' path are allowed with any method and any header.

If you're creating a small app you'll only ever run on your own computer or localhost, you might not need to worry about defining specific origins and routes:

You might have noticed the '*' wildcard is a sort of 'all things go' symbol. Using the '*' wildcard when defining the origin would allow all requests from any origin. Same would apply when using the wildcard for your resource paths. With resource paths, you can either allow any and all resource paths, (resource '*') or allow any extension of a specific path root (resource '/examplepath/* ').

When defining parameters, you'll instead want to use something like headers: :any and not the '*' wildcard.

So if you were to exclusively use the '*' wildcard for your small localhost app it might look something like this:

config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins '*'
    resource '*', headers: :any, methods: :any
  end
end

That's nice and simple.

There's a lot more to CORS than what's written here, and could be a whole blog post, or two, on its own. So if the concept still feels a little shaky, that's ok! There's a lot going on there that you don't necessarily need to understand to be a good programmer, but if you can understand what these few lines are doing it'll make some of those fetch request errors make a lot more sense.

Happy Coding!

Same-origin policy - MDN Web Docs
Cross-Origin Resource Sharing (CORS) - MDN Web Docs
CORS & JSONP
Rack CORS Documentation

Don't Worry, We're Just As Depressed As Everyone Else

Aidi Rivera — Mon, 01 Jul 2019 23:44:18 +0000

Mental health in the web developing community. There are problems. You might even say it's problematic. Grim. At least, that’s what all the articles I read on it seem to say. I started looking into the topic of depression and anxiety in the industry since it’s something I suffer from myself. After the latest plunge my mood took, I wanted to write about it; a form of self-therapy. So, being the professional (nerd) I am, I did some research first. I was curious to see what the coding community had to say before saying anything myself.

The more I read, though, the more I learned how the coding lifestyle can make depression likely. Coding work is isolating; we’re looking at screens and sat indoors all day. The job is high-stress with constant deadlines. Imposter-syndrome and burnout it super common. There was even a connection between depression and more creative people. And web developing can very much be a creative job.

Saying I felt concerned…would be an understatement. For a good, long moment I was utterly convinced. I’d condemned myself to a career that would ensure the complete ruin of my already-fragile mental health. I would forever live as the isolated, suffering artist with deadlines hanging over my head and a potential breakdown awaiting me around every corner. Yes, there was that one positive article in the list of many dooms and glooms that suggested that maybe, just maybe, web devs weren't as depressed as people made them out to be. I, obviously, dismissed it right away. I’d already moved on to see how bad it really was.

Stack Overflow’s 2018 survey of web developers found that nearly 20% of developers self-reported as suffering from anxiety, depression, or both. Out to prove exactly how bad it all was, I looked for some stats on mental health in the general population. Instead, I found a nearly identical statistical representation of what the rest of America looked like instead. That was annoying.

And that obviously couldn’t have been right, so I kept digging. And I kept finding more blogs like the other, positive one, similarly saying that web devs really aren’t that depressed. In fact, some said, they might be happier than people in other fields of work. But, if that were true, why all the emphasis on this problem?

I might agree with some of the articles arguing it might be a bit sensationalist. But I don’t know if I agree that web devs are actually less depressed than everyone else. I don’t think web developers are any more or any less depressed than everyone else. And here’s why:

Being a developer does not make you lonely. There’s strong research that suggests that loneliness is much less about the environment and more about your genes. There’s a genetic predisposition to loneliness. The same way you can feel lonely when surround by a crowd of people, working alone does not automatically mean you are lonely.

Long screen-time is a problem for everyone, not just developers. With the accessibility of smartphones and computers, it would be unfair to say it's a problem specific to the job. If devs are more depressed because they're indoors all day and spend long hours in front of a screen, then so is everyone else in existence.

There’s a similar problem with saying that the job is high stress, and thus developers are more prone to depression because of it. It sets this expectation that any developer job you may have is going to always be high stress. Except, whether your job is high stress depends on the expectations put upon you by your employer.

Burnout, imposter syndrome, isolation, long screen-time; these are all things affecting plenty of people outside of the tech industry. I was aware of imposter syndrome as soon as I was in college. Most of my former classmates to this day feel it and complain about it, no matter what field they’re in. These are all symptoms that are not specific to any one field.

What I’m trying to say is this: correlation does not equal causation. That and also: if we're depressed as web developers it’s because we’re just as depressed as everyone else.

So there’s no reason to panic or believe that being a web developer hikes up your chances of mental illness. But it’s still an important subject to talk about and keep in mind. Your mental health is as important as your physical health, if not more so.

What are things you can do to keep yourself mentally healthy as a web developer?

Manage your physical health. Stretch, get out of your chair often and walk around. On that note, take a walk outside while there’s some sunlight.
Manage your screen time. Yes, we literally work on our screens but try to limit your social media consumption if it’s taking too much of your free time.
Nurture your hobbies outside of coding. Your life doesn’t have to be all code. Let your brain switch lanes every once in a while.
Leave your work at the office. Or the office nook for those who might take their work home. Give yourself limits so you don’t overextend yourself if that’s something you’re liable to do.
Pay attention to your eating habits. Notice yourself feeling a little groggy after that plate of pasta? Maybe leave the pasta for when you don’t need to problem-solve.
Ask for help. Life is hard and sometimes we just run out of juice. Don’t be afraid to ask for a jump.

Networking: It's a Lot Like Dating

Aidi Rivera — Fri, 21 Jun 2019 22:58:21 +0000

Networking is a daunting piece of advice that’s constantly flung around. It's especially prevalent in the tech field, where networking seems to be the only way to find that one job you want. The problem with networking is that, for most people, it’s this monster of social anxieties, confusion, and self-doubt. And everyone believes they’re the only ones suffering while the rest go confident in their networking. The truth is, we can all feel good about networking. We simply need a change of perspective.

But why bother? Shouldn’t you be evaluated by the quality of your code and your code alone? Yes. But only after a recruiter’s bothered to look at it. Putting a face to a name on a resume helps a recruiter see you and not a sheet of paper. And that’s if you meet recruiters at all; recruiters make up a sliver of the people you’ll be meeting.

People like people. (Ergo, recruiters like people, too.) Resumes are not people. There is no personal connection to make there. Networking lets others get to know and connect with you, the person, and not just the very valid qualifications listed on your resume. And when people like people, they want to help people.

That’s how networking can set you up for opportunities. Connections can introduce you to a job opportunity, a mentor or mentee, insider knowledge, tips and advice, or friends.

I always thought of networking as this weird schmooze-fest for businessmen who were all trying to win favors from those with favors to give. Networking events were full of people who were exceptional in their field and confident in their abilities. I believed it because no one had ever told me any to the contrary. It's years after graduating that I recognize the opportunities for networking I had while attending. I also realize that not once was networking named for what it was, let alone how to go about taking advantage of it.

I finally lifted the veil on networking when I attended the Women In Tech conference in Seattle. The conference focused heavily on the importance of networking and by the end of the week, I was a true convert. Networking is all about connecting with people. That’s it. It’s not about schmoozing, it’s not about big events, it’s not even about finding a job. It’s about finding relationships. And that’s when you start dating.

Whatever you think about networking, the reality is a lot more forgiving. But, like dating, with the wrong mentality and approach, it could be pretty awful. So let’s change that.

Don't expect to find your soulmate - your dream job. It’s more likely you’ll meet someone you like enough to want to be friends with and nothing more. And that’s great! You just made a friend. Go you!

You don’t attend events to find a job, though that can, and frequently does happen. It’s nice to know that the worst you can do when you attend and engage in events is to make a friend. Because that’s the whole point. You got there to meet people and make your friends group grow. Because:

Your friends are likely to be the ones to introduce you to your biggest relationships. Meeting people at events will grow your personal network of connections. Then by maintaining those connections, you can grow your network even larger through the connections you already have. And it’s through one of those connections that someone is going to know about an opportunity with you in mind. On the flip side:

Relationships go both ways. The bigger your personal network, the more opportunities you’ll have to share with others. And it’ll be something that you’ll do pretty naturally because, guess what, you are people. And we know that people like people and when that happens, people want to help people. Plus, there’s nothing good about a relationship that’s only about one person. Don’t be that person.

Don’t force a relationship. Don't try to get to know someone because they have something you want, or think it would be a good connection to have. They’ll likely realize you’re not being genuine even if you tried. Chat around and find someone you like, someone you click with. And if you click, then see if you two have anything in common, any similar interests. Is this someone you can keep up a conversation with? Someone with shared experiences? Congrats! You’re on your way to making a new connection. Don’t forget to exchange information and keep the conversation going after the event.

If someone doesn’t like you back, don’t take it personally. There will be times when someone doesn’t reciprocate your interest. Could be you’re not what they’re looking for right now. Or maybe it was bad timing and they aren't ready for anything serious. Otherwise, maybe they can’t see a good thing when it’s smack in their face and they missed their chance with you (I mean, forget them anyways, amirite?).

Things will be a little awkward. It’s inherent to networking events. Everyone understands this at some point. So don’t worry about being awkward. Everyone’s in the same boat as you. The people you see who look super confident are actually the people embracing the possibility for awkwardness.

Now go forth: attend networking events, be yourself, don’t force a laugh at someone’s lame joke. Have fun and make friends. Because, sooner or later, you will help your people and your people will help you.

Using TTY::Prompt for your CLI app

Aidi Rivera — Tue, 04 Jun 2019 23:13:47 +0000

I recently became a software engineering student at Flatiron School, a coding school originally based in New York that's branched out across the country.

In our third week, we were charged with creating our first robust project: a CLI (Command Lind Interface) app. A project we'd then have to present. In front of all our classmates. It was awful. But, in all seriousness, a CLI app is a great project for beginners and something I highly recommend as a great challenge to step up your learning.

And for those who want to take their CLI app to the next level, I present to you an awesome gem that's simple to use and makes your app look a step above without extra fuss:

TTY::Prompt

TTY::Prompt, created by Piotr Murach, is an open-source gem that provides "a beautiful and powerful interactive command line prompt."* It's pretty great. If your CLI app ever needs input from a user (which it should because, why not?), this is the gem for you. It gives you great options to display prompts or menus with choices that your user can fill in or pick from and makes the styling neat and handsome. Like so:

How to use it

It's simple!

Add the gem to your app's Gemfile: gem 'tty-prompt'
Execute it with bundle
Or install it manually in your bash with gem install tty-prompt

When you're using it in your application, all you need is to create a variable prompt and create a new instance of the TTY::Prompt class.

prompt = TTY::Prompt.new

This way, you can call on any of the methods the gem provides on this new prompt variable.

prompt.ask(‘Your question here')

Methods

There are a few basic Prompt methods you're most likely to use in your CLI app:

ask

To ask a question that the user would respond with simple input, use the ask method. As with any time you want to use TTY::Prompt, you first need to create a prompt, then call the method on that prompt variable you have created.

prompt = TTY::Prompt.new
prompt.ask('What is your name?') 
# => What is your name? doge
# => "doge"

The return value is a string of your user's input. So say your user types in "doge," when they hit the return key, not only will your return value be equal to "doge," but your user also probably looks something like this:

yes?/no?

The yes? method is similarly built, but will only return true or false when the user presses 'y' or 'n' respectively.

prompt.yes?(‘Are you a dog?’)
#=> Are you a dog? yes
#=> true

You can also change the defaulted (Y/n) option to say something like (Agree/Disagree) instead, with the .suffix option.

mask

A nifty tool for when you require confidential information from your user, like a password, is using the mask method.

prompt.mask(‘Enter your password:')
#=> Enter your password: ••••

Menu methods

Prompt gives you a few different ways to create menus where your user selects one or more from a list of options to choose from. The most basic way to create a menu would be with a select method.

select

Whenever you need your user to choose one of a list of options, the select method is your friend. Your user will use the up/down keys to choose from a list of options you provide, which will then return a string of the option chosen:

prompt.select("What's your favorite kind of taco shell?", %w(Soft_taco Hard_taco 
Porque_no_los_dos?))

#What's your favorite kind of taco shell? 
#  Soft_taco
#  Hard_taco
#‣ Porque_no_los_dos?
#=> "Porque_no_los_dos?"

There are two other variations on the select method:

multi_select allows the user to select more than one option:
enum_select allows users to select an option by entering the numbered key corresponding to its option:

      prompt.multi_select("What's your favorite pet?", %w(cats dogs fish 
      birds reptiles plants))

      #What's your favorite pet? cats, dogs, plants
      #  ⬢ cats
      #  ⬢ dogs
      #  ⬡ fish
      #  ⬡ birds
      #  ⬡ reptiles
      #‣ ⬢ plants

      prompt.enum_select("What's your favorite pet?", %w(cats 
      dogs fish birds reptiles plants))

      #What's your favorite pet? 
      #  1) cats
      #  2) dogs
      #  3) fish
      #  4) birds
      #  5) reptiles
      #  6) plants
      #  Choose 1-6 [1]: 2

Cool Features

TTY::Prompt gives you a lot of ways to personalize your prompts. Let's go over some of the more useful ones.

Default

Many of the methods have the option of defining a default value to your prompts. It's a neat feature to have when options are given in cases of exceptions to the norm. Or maybe you foresee users being particularly lazy or paranoid about using their name; you can have a default: value set to "Anonymous".

prompt.ask(‘What's your name?', default: 'Anonymous')
# =>
# What is your name? (Anonymous)

TTY::Prompt is smart enough to have the default option available for quite a few methods:

ask

prompt.ask(‘What industry do you work in?', default: ’Tech')
# =>
# What industry do you work in? (Tech)

yes?

prompt.yes?(‘Is GrumpyCat grumpy?', default: true)
#=> Is GrumpyCat grumpy? yes
#=> true

And any menu method with menu.default <default value(s)> inside the menu iteration

prompt.select('Choose your fruit of choice') do |menu|
  menu.default 3

  menu.choice 'Papaya', 1
  menu.choice 'Mango', 2
  menu.choice 'Watermelon', 3
end

prompt.multi_select("Select tea?") do |menu|
  menu.default 2, 5

  menu.choice :green
  menu.choice :black
  menu.choice :white
  menu.choice :earl_grey
  menu.choice :sweet
end

Require

The :require option allows a prompt to be (you guessed it) required before a user can move on. Like default:, it can be added to essentially any prompt method, which makes them both extremely useful features.

prompt.mask('Enter a password:', required: true)
#Enter a password: 
#>> Value must be provided

prompt.ask('What is your name?', required: true)
#What is your name? 
#>> Value must be provided

Admittedly, with methods like the menu methods, the user would have to input a response before they can move on regardless of whether or not it is required, so pinning it onto the end of a menu prompt would be redundant.

Return values

Return values are defaulted to be a string of whichever option the user chooses, like in the first doge example. But return values can also be customized by adding the return value you'd like for that choice right after choice itself like you see in the fruit example above: menu.choice 'Papaya', 1

Though I've claimed these methods here to be the most useful, there are many more features available with TTY::Prompt and I encourage you to fully explore their documentation page and give yourself a chance to play around with them. Happy Coding!

*- Edited June 21st to credit the creator.

Forem: Aidi Rivera

Coding with ADHD: How do You do it?

5 things you might not realize make your site less accessible

1. Using <div> for everything

2. Design that relies on color with no text (or vice versa)

3. Using the wrong kinds of icons and fonts

4. Not having captions or transcripts for anything with audio

5. Captchas

Signed vs Unsigned Bit Integers: What Does It Mean and What's The Difference?

What Does It Mean?

What's the difference?

Unsigned binary numbers

Signed binary numbers

Negative binary integers

Alternatively:

Finding the max and min with signed binary numbers

The problem

The solution

Fin!

x-Bit Integers: Solving With A Range

Max and Min Range

the problem

the solution

the warning

Intro to X-bit and Binary Integers

What does it all mean?

Translating binary numbers

From binary to decimal

From decimal to binary

Why does it matter?

Learn From My Mistakes: My First Take-Home Code Challenge

1. Ask questions

2. However long you think it'll take you? Double that

3. Hold yourself to a sooner deadline

4. Use examples you're given - Emulate the company's brand

5. Don't focus so much on the "correct" way to do something

6. Test your code

7. Comment your code

8. Stop doubting yourself

9. Don't spend too much time on it

New To React Native? Do It With Expo.

What is Expo?

Using Expo

Installation

Creating Your App

Managed or Bare?

Blank or Tabs?

Some things to note before starting:

5 Ways to Keep Going During Your Last Weeks of Bootcamp

The Name's CORS. Rack::CORS.

What is CORS?

What's Rack::CORS?

How To Use It

Don't Worry, We're Just As Depressed As Everyone Else

Networking: It's a Lot Like Dating

Using TTY::Prompt for your CLI app

TTY::Prompt

How to use it

Methods

ask

yes?/no?

mask

Menu methods

select

Cool Features

Default

Require

Return values

1. Using `<div>` for everything