The dictionary defines ‘authentication’ as “the process or action of proving or showing something to be true, genuine, or valid.” So true. Since the dawn of time, people have been wondering how to authenticate requests. And as a great poet once wrote, a rose by any other name may smell as sweet, but if that rose comes through that door calling itself a tulip, I’m going to need to see some ID.

I recently found myself where, I assume, my ancestors, and my ancestors’ ancestors have all found themselves: at the juncture of needing authentication, and not quite knowing how to do it. And this is where our journey begins today.

The Call to Adventure

I’ve been working on an app that you may or may not care about, but I care a lot about: an app for organizing your skincare products and tracking them. I actually built it already, last year, but it was a mistake and poorly built and I, the creator and also 100% of the user base, abandoned it a week after launch. They can’t all be winners!! Anyway at the beginning of the year, I spent some time rethinking the build, and decided pretty early on that, it’s 2018, I need to build users into my app, and I can’t be realistically asking users to “fork and clone and then open terminal and start up the server and then start adding all your products its SUPER easy and user-friendly”.

How hard can it be? I asked myself, and set up a quick little card on my project board and figured I’d get to it when I get to it, and it’ll be like, a couple weeks’ worth of work at most? Users are everywhere! You can’t go anywhere these days without signing up for something before even using it, and if Jim can build a b2b vegetable sharing startup app in his basement and get users and auth built into THAT, surely I, a Live Employed Engineer, can figure it out. This is a lot of words to say, I walked into this with the confidence and swagger of Lindsay Lohan in Mykonos. Did I know anything, even a single thing, about adding users and auth to an app going into this? No. Did I believe I could whip something up pretty quickly? You bet, pal.

The Struggle, of the Crossing of the Threshold

You might, at this point, be wondering what stack I am working with. Thanks for asking, grab a tissue and get ready, it’s time for blood tears. The app’s stack is, basically, a Frankenstein of some things I’m already comfortable using (Rails, Vue), plus some new things I’ve been wanting to learn (GraphQL!!! The API of the future!). Because this app was also a sneaky way to learn some things that had been on my list for awhile. Multitasking baby!! It’s how we feel alive in 2018! So, the stack is: Rails on the backend, Vue on the frontend, GraphQL for the API, Apollo for GraphQL on the frontend, and the graphql-ruby gem on the backend. My philosophy when choosing the stack was “why not, honestly”.

To start, I did some research, and gathered criteria for the app’s users and auth system: specifically, I needed to be able to authenticate API requests, attribute data to a specific user, have an easy (sign in via google/social would be nice) sign in, and do all this with the lowest lift possible because users, to me, seemed like an annoying obstacle I had to cross on the way to the _real_ work, aka building the app.

Googling ‘users auth rails how’ will pretty immediately direct you to the gem Devise. It’s great! Has a lot of built in stuff, everyone uses it, lots of 5 star ratings, etc. But because it assumes a REST API setup, and the whole point of GraphQL is that it isn’t REST, it uh, wasn’t going to work. So it was back to researching. I looked into a lot of things, particularly for things that mentioned both Rails and Vue and GraphQL in the documentation, but it turns out I was in a prison of my own making. Nobody else, it seems, has willingly chosen this nightmare stack. Innovation: not always great!

I looked into a lot of other things, too, but the important thing for you to know is that I didn’t choose them. I spent a lot of time following DIY tutorials (genuinely, I think I followed about 6 to the end) but ripped them all out, because they all would show you mostly how to get there, then say, “but no one in their right mind would do this in production! So figure something else out.” This is useful if you’re building an app for, I suppose, no one, or your enemies. At this point I had learned a valuable lesson, which is that users and auth is a lot of work, and that maybe it was time to start looking for something that handled most of the internals for me. This led me to Firebase, a Google-backed solution, which does a lot of things, but particularly handles a TON of auth methods for you, has built-in support for signing in through various apps, and a bunch of nice lil convenience functions so you can do things like get the current user. Incredible.

As it turns out, adding Firebase was the easiest this project would ever get! In less than a day, users were able to sign up, login, and logout, which are three things you really want an app to be able to do. This, conveniently, meant it was working in time to show at the end of our company hack week, and where no one was impressed with it, because it was a tiny two (2) field form where you put an email and password in and then could sign in like any of the other 300 hundred apps you visit every day, but it meant a lot to me.

This was also when I paused to read up on JSON Web Tokens. Have you heard of these things? It’s a neat little token that carries a bunch of user data around so that you, An Owner of An App, can use it. Frontend Masters has a great course on it, how it works, and its advantages over session-based auth. This is what Firebase uses, and in this house, what Firebase says goes. And this is where things got messy.

The Tests of Will, Abilities, or Endurance

At this point, users could log in, log out, and sign up to their heart’s content, but none of this was linked to the backend. It was a bit like having fancy, expensive curtains covering up a gigantic pit. Cool, if you like pits, I guess. I did a lot of research around using JWTs (street slang for JSON Web Tokens) on the backend, and found a ton of solutions for building your own JWT auth system. However, these all assumed you wanted to generate and authenticate JWTs on the backend first, not the other way around. This was unfortunate for me because Firebase was doing all of the generating and auth already and, and really, all I wanted was a way to attach the user Firebase had created and verified to the users in the backend, so I could return to a user the data they’d entered.

Looking back and knowing what I know now, the solution is pretty simple, and I could just save the token provided by Firebase to the db and use that token to pass the right data back and forth. However, I still a. didn’t fully understand how JWTs work, and what using them meant, b. had a pretty fuzzy grasp on what auth meant in general, and what you needed to *do* to actually securely authenticate a user, and c. was going through this all for the first time, and was confused about how all of this fit together in the 15 layers of hell that was my stack. I really cannot stress enough how many different auth systems I’d built into the app at this point. I’d started and had to abandon about 15 different implementations, for various reasons, most of which can be summed up with, “not meant for production code, more illustrative than anything” or “way too complicated for what I needed”. I wanted to quit!! So badly. At this point I’ve been working on this stupid thing for months, making barely any progress, all the exciting work for the project on pause until this was solved, my spirit was dying, my boyfriend was losing patience with me yelling about users and auth at every chance I got. In short, I was being a nightmare.

Finally, I decided finally to just google to see if there was a firebase gem for rails. Why I didn’t do this sooner, I’m not sure, but I would guess it’s because I spent a lot of time thinking I needed something that worked with GraphQL too, and was spending a lot of time searching for apollo/graphql solutions for auth and ignoring rails. But! There was a gem, and it did exactly what I needed it to, which is take in the Firebase token passed in from the frontend, and decode it in Rails.

Well. I got this gem hooked right up, followed the docs, and did everything *chefs kiss* perfectly. But it didn’t work. There was a bug where, I could see that the token was correctly being passed into the controller, and the gem was doing everything it should be doing, but the token wasn’t decoding. Confusingly, putting a byebug in there and running the decode commands individually by hand decoded it perfectly. So there was something weird happening where the token wouldn’t decode during a normal request, but if you paused and went in, it worked fine. And this began a deep dive into source code.

The Ordeal and its Reward

Success was so close, I could almost taste it. Whereas the past few months had been a cycle of agonizingly slow progress → start over → repeat, I was now making Real Live Progress in meaningful pieces now, and this bug was the only thing standing in the way of me and that sweet, sweet decoded token. This was the final battle, and I was really ready to fix it and then move the h*ck on.

The journey to solve this bug began where most journeys to solve a bug with an obscure gem begin: a quick visit to the gem’s issues page to see if anyone else has had your problem, only to realize no one has, because only three people, in the history of ever, have used it. Next up is to look at the source code, where I really realized I was on my own, because every single method for authenticating the token rescue’d out without surfacing any errors. If it fails, it just returns nil, and thank you for coming to my ted talk on how to disappoint your users.

Next came the wave of confidence that hits you after looking at some source code and thinking, “ya i could do that”. And I really wanted to be able to dive in and add my own error handlers so I could see where this thing was failing. So I did what any sane person would do, and copied the entire gem into my own repo so I could debug it line by line. It’s only a few files, so it’s not too bad, and it’s working pretty quickly, and it’s only 2am on a weeknight so I’ve got like plenty of time to fix this before the sun comes up. Next I cracked my knuckles and set to weaving a tangled web of `raise`s and `byebug`s to catch this godforsaken bug, and finally, a useful error emerges. I have never been so happy to see an error message in my life. Et voila: the decode is failing with a `JWT:InvalidIatError` which if you google, has little information beyond people frantically copy and pasting that exact error message into stack overflow accompanied by a ‘pls help’. So next I find myself deep in the ruby-jwt gem source code, which the firebase gem relies on, to find the source of this error to find the line where this is happening.

As it turns out! Apparently tokens can be given a timestamp that is slightly in the future, and the check in the ruby-jwt gem checks specifically to make sure the JWT was issued prior to the time of check, as shown here: `raise(JWT::InvalidIatError, 'Invalid iat') if !iat.is_a?(Numeric) || iat.to_f > Time.now.to_f` And apparently this can happen for a variety of reasons, including but not limited to, your computer’s time being out of sync, the origin setting the IAT being out of sync, divine intervention. Alright then.

After some further reading, it turns out that this is an issue a LOT of people have run into and yelled about on the internet. I am going to be honest with you here: I just removed the call to check the issued at time of the token. Am I proud? Honestly, yeah. I tracked down the source of the issue, and my app doesn’t have millions of users (to be completely transparent, it has 0 users), so I think we will all live if I delete this one check. In the real world, in an actual production app, would I have found a way to fix it? Absolutely! There was something about being able to pass in a leeway time to allow for some of these discrepancies in issued at times that, had it not been 3am, I probably would have had more patience to look into.

Anyway!! Today, September 19, year of our lord 2018, the app is able to authenticate users from frontend to backend. ‘Hey but you only described logging in, what about everything else? And why’d you mention GraphQL if you never used it in this tutorial?’ We-he-hell, it looks like we are out of time. Stay tuned for my next 16,000 word essay!

The Return

Have you too found yourself the victim of a particularly terrible stack, and need to add users? Here’s a list of resources that helped me, and that may help you, too. Don’t wait, click today:

This soup is following me everywhere. I can't be the only one seeing it. It's ~aesthetic, but... off.

Like, it's soup, I get it. But also, how dare it call itself a soup? This is five noodles and a child-sized handful of leftovers from a farmer’s market. It’s like an AI, fed thousands of recipes of soup, started generating its own soup, then got bored halfway through and stopped.

How can this be ‘nutrient-packed’ when 3 out of 5 ingredients are herbs, and there’s only half of a vegetable? The most offensive part of this whole thing to me is the half floret of cauliflower. They took the time to cut up a floret, but couldn’t be bothered to throw the rest of it in. Where did the rest of it go? Who is eating the other half of my cauliflower?

Is that one single leaf of basil? Weather conditions have been tough this year, but surely we can’t be rationing out basil like this? It’s not even cut up! It’s just one single leaf! Are you supposed to eat it alone? And the dill! Did the chef imagine me placing the dill delicately in my mouth, and chewing on it like an herb tumbleweed with the enthusiasm of a woman in a yogurt commercial?

And WHILE we're here, let's talk about the elephant in the room: the inedible stalks that have taken up residence on top of this nightmare. I assume they're lemongrass, but am I supposed to chew on them? I checked, and almost all search results recommended removing the stalk before eating. This is even worse news, because now we’ve learned that not only are there only five ingredients in this soup, one of them isn’t even edible.

This soup is the Melania-Trump’s-Christmas-decorations of soup. It’s soup, but with a sad, empty, despair-filled twist. Somehow, they have made soup — warm, nourishing, life-giving soup — sad.

I checked their website, and there are more photos of the same soup, with no more ingredients. They’ve painstakingly switched out the background to, I presume, show off the versatility of this sad broth disaster. Look at all the thought that went into curating and arranging the soup. Imagine if they’d put that kind of effort into making the soup. For god’s sake, the background has more components than this soup!

You can try and photograph this soup in a hundred different angles, and never find a flattering angle. This is soup that’s given up, and to be honest, given this year, I can’t blame it. This soup is all of us, on Friday, after being dealt a week’s worth of news. Yes, we look like ourselves, but emptier, hollower than before.

I’m into this soup, but for all the wrong reasons. Who thought I wanted this? Who thought anyone wanted this? This soup is 50 calories max. tbh I’d rather just eat 5 peanuts.

I, like everyone who's watched Riverdale, and also everyone who walks this Earth, have opinions.

Specifically, I have opinions about who is terrorizing our fav small town, Riverdale, under the name of the black hood. Or, what a better question may be at this point, is literally who isn't. Anyway, let's just get right into this.

The black hood is at least 3 people.

Evidence: we have one confessed black hood, Hal, but we also have three (3) instances that Hal either hasn’t confirmed he did (Chic), or wasn’t able to, because he had an alibi (Town Hall, Fred, but the second time). This could mean we have one imitation black hood, but I think you will see from the compelling evidence I present, there must be more than one.

First, let’s examine Chic’s case. I believe the voice on the phone was definitely Hal’s, and I believe the voice on the phone has always been Hal’s, however, I find it difficult to believe that the same slow moving oaf who could barely muster up a brisk walk whilst terrorizing Cheryl with an axe, could be the same black hood as the one who took off after Chic like it was the goddamn Olympic trials. Hal, I argue, just does not have the physical prowess to have run this fast.

So this leaves us with at least one black hood. Next, let’s examine Town Hall. I’m sorry to tell you, but this black hood was Sheriff Zaddy Keller. Evidence: The old school gun, which is maybe a rifle, maybe a shotgun, but definitely a gun. Why is it him? Oh, maybe because he had approx one thousand motives. A of all, he is jobless, so he’s got a ton of time to plan a crime like this. B, inciting terror under the new sheriff is just good for business for the recently shunned ex-sheriff. C, he is the right stature. You will see but basically my argument for the black hood is that all of them are dads of Riverdale, for god who knows what reason. And finally, d: green. frickin. eyes. Them’s the writing on the wall, baby.

So what else has Sheriff Zaddy done? I argue it was him who chased after Chic, because from what I hear, cops have to run a pretty fast mile, and as we noted from The Basement Scene, when we saw him earn his Zaddy badge, he is Incredibly Fit. Double check my count, but I am pretty sure he had ~10 abs. That is the kind of bod that could chase after Chic like a car on a high speed chase.

Next, I’d like to point out some [bullet] holes in the Fred attack (the remix). Namely, we are meant to believe that this brutal killer just waltzes right into the Andrews’ home, has a quick little tussle with a 17 year old boy, stands there, waits for Fred to heroically say “noooooo not my son!!!!” and leap in front of the gun like he’s g-d will smith (when we WELL know he is not), and then decide just one shot is good enough, even though the first time, Fred Andrews _survived_? This is some bull!! If the killer had really come back to finish the job, I think he would have been able to spare a second bullet for good ol’ Fred Andrews.

And so. I argue that this attack was planned. Planned, because the killer knew he would be wearing a bulletproof vest. Planned, because he didn’t shoot to kill, he shot to create a narrative. Planned, because who the hell fails at killing someone twice, when they have killed so many others in just one try. Planned, too, because notice how quickly Fred bounces back from a SECOND MURDER ATTEMPT. Two murder attempts is a lot for a simple man like Fred. I believe this, again, was Sheriff Keller, trying to create more chaos and throw more dirt on the name of the new Sheriff Regime. By continuing to make it look like the Black Hood is still out there, Zaddy Keller is making his time leading the city look not so bad in comparison. I also think Fred might have been in on this, because he is a Good Guy, and I believe in his heart of hearts that he wants to keep Riverdale clean, and part of that is making sure there are no Mafia-paid sheriffs running the town.

Finally: let’s clean up some loose ends. Who committed the elaborately staged Midge murder? Do we really believe that Hal possesses the kind of stealth required to silently kill a scream-prone teenage girl, somehow stage an elaborate set of her murder, write messages on the wall, then clean up and take a seat in the audience, ready to enjoy the show? I, for one, do not. This man, to paraphrase Cheryl, lumbers around with the subtlety of bull in a china shop, with about as much elegance as one. I don’t think he is mentally or physically capable of this. Sure, he admitted to it, but I think Hal would like to believe he is much better at, well, everything than he really is. Also, this is way different than the other murders! The other ones were just a quick bada bing, bada boom, yet this one was wildly staged and planned. I just don’t think Hal has the creativity to come up with this.

So who does? Certainly not Sheriff Keller. Sure, I have argued he is one of the Black Hoods, but I haven’t argued that he’s killed anyone. He’s mostly just here to cause chaos. Murdering an innocent teenage girl whose only crime is loving that sweet sweet jingle jangle seems too far for him. So who, then? Who possesses the calloused and calculated planning abilities to commit this murder? To me, this murder just screams mafia involvement. The mafia, as viewed through a Riverdale lens, is about theatrics, sending a message, and People Elaborately Dying, as we have seen from 1. Pop’s Poker Night, and the aftermath that followed, 2. Nick renting out a large empty murder warehouse on AirBNB to “make his bones” and prove to everyone once and for all that his penis is actually a normal size. And in Riverdale, where there's Mafia smoke, there's a fire started by Hiram. And why wouldn’t Hiram want this? Things were getting too chummy in Riverdale, and as we have seen time and time again, Hiram’s plans thrive in chaos. Also, we just saw him broker a deal to trade a 17 year old’s life for ??? unclear, so he is not above killing teenagers to make some bucks and further his agenda. And while we're here, why was Chic, during the Town Hall shootout, as everyone else understandably sprinted toward the door, sitting there smiling and laughing like a kid on a frickin carnival ride? Really. I don’t know. I don’t have a theory for this, if you do, please tell me.

<p>The summer of 2017 may be remembered for many things, but to me it will forever be remembered as the summer that five optimistic young ex-One Direction members embarked upon their respective solo careers. Over the course of three short months, we have been served a tasting plate of singles from former-1D-bois-gone-~solo~. It&rsquo;s been hard, if not impossible, to make it through a Spotify new release playlist without running into at least one of their singles.&nbsp;</p>

<p>The solo One Direction takeover happened so subtly, you may not have noticed! Some of these songs are so good that you might have assumed they came from an emerging pop star who has always been solo, and not someone who has historically relied on the talents of 4 other pop stars, and so I would forgive you. I guess realistically, they could all be successful, but that is no fun. Messy pop star drama is what I live for, and so to me, there can only be one successful ex One Directioner. And so, I present this list of the One Direction solo careers, ranked by criteria that matter to me, with absolutely no scientific support.</p>

<p>Louis Tomlinson was most famous during his days in 1D for being the only member who was actually secretly 45 years old, and who probably had a family in Ohio he was trying to support but we never really got confirmation on that. Anyway, Louis gets a red flag for releasing a single that he is barely even in. I almost disqualified him for this, but as he has a Spotify page with two official singles listed, the editor (me) was forced to include him. Louis is ranked last because he has fallen prey to a classic rookie solo artist trap: relying on other artists like a crutch to carry his single to the top of the charts. Louis, I know you read this newsletter, and I want you to know that you don&rsquo;t need to rely on gimmicks like Steve frickin Aioki to carry you to success. You were ⅕ (and, after Zayn quit, &frac14;!!) of a member of what I haven&rsquo;t looked up the official numbers on but I&rsquo;m pretty sure was the most successful boy band of the past few years. Your fans loved you! You toured! You tasted success! And I&rsquo;m sure your kids in Ohio look up to you, too! What I&rsquo;m saying is, I know you can do better than this. I&rsquo;m rooting for you. Your fans are rooting for you. Your kids are rooting for you. Make us proud. But no pressure. Anyway, for this reason, Louis, I have no choice but to rank you last.&nbsp;</p>

<p>Released in May of 2017, this song barely made the cut, but since I&rsquo;m the judge, I&rsquo;m calling this one a solid summer single. You&rsquo;re welcome, Niall. Niall is most famous to me for being the &ldquo;other man&rdquo; that Ellie Goulding stepped out on Ed Sheeran with, and who subsequently found himself the subject of Sheeran&rsquo;s scathing single &ldquo;Don&rsquo;t&rdquo;. I am confused how this happened because I am pretty sure Ed Sheeran and Niall Horan are just the same person. What is also confusing is this song, but damn it if it isn&rsquo;t catchy. That raspy voice! That bumpin beat! I cannot get enough.&nbsp;</p>

<p>But I have to knock this single for leaving me with lingering questions; namely: <em>Whose</em> hands are slow? What does it mean to have slow hands? His tone suggests slow hands are desirable but for the life of me I cannot work out why. Is this a sexual term some boi band member who is a full calendar year and some change younger than me hip to, that I am not? I don&rsquo;t get it! But, I want to. And that is why, lingering feelings of unease over unanswered questions and all, this song makes the cut as a hot sizzlin summer jam. Unfortunately, Niall&#39;s position has been bumped down here because he also subjected us to his other single, &#39;Shape of You&#39;, which we all agree is the most hollow pop song of the summer. Sorry, Niall, but you better get your act together if you want to rank higher here!</p>

<p>Harry shocked us all by releasing not just a single, or two, or three, but a whole entire read-em-and-weep album, somehow in the same time frame that the others could only muster up the creative energy to release one single. Oh, and in between his busy album dropping schedule, he also auditioned for and won a part in Dunkirk. Harry has been a busy ex boi! Before we even get into the music, we have to pause and note the album art, which is giving off extremely not subtle birth vibes, and which I think we can all assume is an extremely emphatic nod to his being born anew in the wake of his messy and public five-way breakup. I applaud his dedication to the artwork, because it looks like he really rolled around in water to get this shot, and he definitely didn&rsquo;t have to. We all would have still listened to the album even if he didn&rsquo;t lay submerged in a pool of pink water, reliving his birth moment to get the shot. But he did, and we&rsquo;re proud.&nbsp;</p>

<p>I don&rsquo;t even care that it&rsquo;s not pop music he released! None of these songs are club-bumpin jams, like that of his four counterparts. Instead he said nope, and went with a very Bob Dylan-y album that I think we can all immediately picture being sung to us in front of a campfire by a man with long messy hair and a thick shawl cardigan, who we are pretty sure is a mistake for us but there&rsquo;s no really good way to tell someone to stop singing their heart out to you and so you kind of just sit there nod and wait for it to end. Was that too specific? Maybe that is just me. Anyway! Harry wins the award for &ldquo;Most Surprising Genre Jump&rdquo; and you know what? I think he stuck the landing. Harry, I look forward to more folk-y albums from you that will be sung to me by a budding musician from Tinder that I just haven&rsquo;t worked up the courage to ghost yet. Thanks in advance for the ghosting encouragement material! My main concern with Harry is that as quickly as we started talking about his album drop, we stopped, and I worry that this album just does not have staying power. For that, I have to knock him a few points, but I think he showed the most originality of the five, and for that, he has my heart, which honestly is worth a whole lot more than a ranking on this useless list.</p>

<p>Boy oh boy, is this song an emotional journey. Between the intro, which includes a shouty announcement of every party involved in the making of the song, the melodic verses, that deep, base-heavy voice that belongs to no one that appears in the song as quickly as it disappears, and finally a verse from Quavo, who has truly become the product-placement voice of songs this summer, this song is six songs put into one and I love it. It shouldn&rsquo;t work, but here I am, listening to it on repeat for the 16th time this week. And the LYRICS. &ldquo;Use to be in 1D, now I&rsquo;m out free&rdquo;. What better way to announce you&rsquo;ve broken free of your old boy band to strike out on your own, than by literally saying exactly that? Break free of those boi band shackles, Liam: you&rsquo;re free and we&rsquo;re all here for it.&nbsp;</p>

<p>We should also pause to note that this song has another good element we can appreciate from a former icon to teens turned rugged ~adult~ pop star: it is oozing sex. Like, to the point where you maybe have to wonder if he has had sex? Because he is kind of screaming about it a lot? Really loudly? Like the chorus is basically one big &ldquo;I love going to clubs because there are WOMEN there! Hot hot women! With boobies and butts! Just like in the videos! And sometimes they dance with me!&rdquo; Anyway, Liam, I hope you find love or lust or an illustrious solo career or maybe all three. You deserve it, for fitting six solos into one and tricking us all.</p>

<p>Zayn is almost disqualified because he technically gave himself a full year&rsquo;s head start on a solo career. However! He released a whole album during that time and literally no one is talking about it anymore, so I think we can all agree that that head start barely did anything for him.</p>

<p>We can all just ignore Pillowtalk. I know it was a popular single, but it was bad; you know it, I know it, Zayn knows it. But he is trying! And he did get a solid summer hit with &ldquo;I Don&rsquo;t Wanna Live Forever&rdquo;. This song has all the good markings of a good boi band member gone solo: guest artist with chart-boosting abilities (Taylor Swift), sex!! featured as the main topic (it was the main release from the latest Fifty Shades of Grey), an edgy video that probably references fame in some weird way (watch for yourself, but the video features a solid minute and a half of Zayn slow walking away from paparazzi). And edgy this video was! So dark! So moody! You can tell he has shed his boi band persona by the level of scruff on his face. Also, he is THROWING things at the wall and generally being an all around &ldquo;bad boy&rdquo;. Good boys don&rsquo;t throw candelabras at walls; they leave them on the wall where they belong. But Zayn is not a good boy. I guess I would make fun of this video more, but it just won an MTV VMA, which also makes Zayn the first member to win an award as a solo artist. For this reason, combined with his entire album release, <em>and</em> his hot single of the summer, I have to begrudgingly award him the top spot.</p>

Lately, there's been a lot of talk about sexism in the workplace, and a lot of discussion around how to correct it. There are many arguments against sexism — it's wrong, women should be treated as equals, etc. These are all reasons, but are they compelling ones? I am here to argue that the most important impact sexism has on your company is a financial one. If you want to run a lean business that spends efficiently and avoids frivolous costs, eliminating sexism is a necessary step. If you have sexism in your workplace, you could be losing money right now.

What if I told you you could be wasting nearly $10k/year per employee? What if I told you that this money is going toward paying employees to do things that provide absolutely no value back to the business, and instead cut into their productivity?Unfortunately, if you have sexism in your workplace, much of your hard-earned money is being diverted toward these very things.

Skeptical? Let's dive into a breakdown of the time and costs of sexism, given a typical female employee:

10min: Gap of time between woman suggesting idea in meeting, and rest of group finally hearing idea and deciding to go with it after male employee restates same idea

15min: Time per day female employee spends trying to convince team that thing she just said is important and should be taken seriously

5min: Per day estimate of female employee having to restart sentence after being interrupted in middle of her point by louder, more testosterone-driven colleague

30min: Time female employee spends per week trying to figure out how to bring up concern without seeming pushy/bitchy/confrontational/aggressive yet still coming across as authoritative enough to be listened to

5min: Time set aside per week for a woman to consider how to tactfully avoid male colleague who is getting too friendly while still keeping things light and professional

10min: Time per week woman spends doing essential task(s) male coworker/boss was supposed to do, but didn't get around to

5min: Accumulative time per day women spends listening as male coworker explains to her thing she already knows

35min: Time per week woman spends listening with feigned interest as male coworker who likes sound of own voice continues talking, taking forever to get to point

30min: Estimated time per month female employee spends crying quietly alone in the bathroom after it hits her that she's going to have to deal with being treated like this through her entire career

60min: Average time per quarter a female employee spends escalating a sexism related issue to management, going through the proper avenues, and otherwise handling sexist offenses

Overall, this is an astounding 60min per daya female spends dealing with sexism. That is 260 lost hours annually. Let's assume a typical salary of $75k/year. We can break this down into an approximate hourly rate of $36.06. Some quick math reveals that annually, you are losing $9,375.6 per female employee. Keep in mind, this is time you are paying your female employee, but they are not doing any work.

And if you think these costs are constrained to female employees only, think again. Men waste nearly 200 hours per yearon sexism as well. Here's the breakdown:

15min per day spent ignoring ideas/thoughts/questions of female employees

5min per day explaining thing to female coworker she already knows, because he is really good at explaining it

25min per week spent trying to plan out cool/witty/irresistible comment to direct toward female employee so that she knows he is witty and cool and very smart

10min per day interrupting female employees during meetings, to ensure they have established themselves as the loudest and most authoritative in the room

10min per day being offended by tone of female employee, wondering why she's being so combative and/or whiny

10min per day shirking responsibility that needs to get done, but is annoying or cumbersome, so they'll wait until female employee gets frustrated and just does it for them

This is a staggering 43min per day that you are paying your male employees to be sexist, not to work. This works out to over 186 wasted hours per year. Assuming a salary of $94k/year, which works out to an hourly rate of $45.19, that is $8,420.40 you are simply throwing away each year, per male employee. And because male employees make more money than female employees, it is actually more costly per hour to have men wasting time on sexism.

If you heard this amount of money was being spent but was providing no actual value back to your business, you would look to cut that cost immediately, wouldn't you? Moreover, this is time that your employees want to be spending on work. That's right — in a survey of U.S. employees, nearly 90% of respondents reported that they felt sexism was a poor use of their time and cut into their productivity. Again, nearly 90% of respondents said they were happier and more productive on days when they didn't have to spend time dealing with sexism. Eliminate sexism, and you gain back 1-2 hours of productivity per day, per employee.

And the news gets worse — the losses don't stop there. If your employees are also spending time being racist, or homophobic, this is even more lost time and lost profits for you. Your money losses could be doubled, or even tripled, the more time your employees are spending disparaging their coworkers. Eliminate all of these from your workplace, and your savings could be up to 4 hours a day, per employee, in gained productivity.

I hope this article has been enlightening to you, and that you'll be able to take what you've learned and save your company money. Because sexism isn't just bad for your Glassdoor reviews— it's bad for business.

At the time of this writing, I am sitting solo in JFK eating a salad, trying not think about how long this tuna salad had been sitting out before it reached my mouth and like, what the strategy is if you get food poisoning on a plane. In an attempt to distract myself, here's another installment of Keeping Tabs.

From my browser to yours, here are the tabs that caught my eye this month:

An HTML Rube Goldberg machine! I honestly did not know that I wanted to see this as badly as I did, but 5+ refreshes later here we are. It's just sooo cool. I'm not recommending you also sit there and refresh indefinitely but I'm also not not suggesting that.

Microsoft published a list of the most used CSS properties on the web (minus a few important browsers, because hey if anyone knows about the differences in cross browser compatibility boy oh boy would it be Microsoft). Anyway it's pretty neat to look through, you can read their report here and the underlying code on Github here.

So hey, we all use the internet, and we all see pretty shitty implementations of things that are ubiquitous, like animations, menus, and icons. Thankfully there are now a lot of resources to find better implementations of these things. Two recommended readings/viewings are Sarah Drasner's presentation for GenerateNY on creating functional animations, and Codepen's collection of common design patterns on the web. Sometimes [most of the time] the expected option is the best option.

With CSS the going advice has always been, "Hack it 'til you make it." As much as we complain....it can actually lead to some creative things. And although this is usually the exact thing that makes it so terrible, it can also be one of the reasons it's fun to work with. For example, did you know CSS has a counter-increment functionality? Una Kravets has a great tutorial on what it is and how to exploit it to build pure CSS games. Read it so you too can impress your friends and build fun things like an off-brand Buzzfeed quiz that tells you how Kanye you are.

One of the hardest things when you're a beginner programmer is learning how to break down a problem in order to make progress. It almost seems counterintuitive, but in order to make progress, you need to forget about the assignment as a whole, and focus instead on the smallest solvable pieces of the problem, and build up from there. It turns out that the process of relearning things you used to know when dementia sets in is remarkably similar. This American Life has a story about one man's process of relearning how to draw a clock by breaking it down into the smallest pieces that make sense to him, and learning something about the bigger picture along the way. Listen here.

// Play

Do you ever have those days when you've spent all day trying to make a layout in CSS and then take a break to stop and rewrite everything with like three lines of flexbox syntax and think to yourself how magical it would be if you could just use flexbox and forget all about floats and margin: auto? If so, then boy, do I have a game for you: It's called Flexbox Froggy, and the goal is to get the frog to the lilypad using the power of flexbox.

Firefox just released this game showing off their new developer browser, and it's pretty neat. This game will take you on a deep dive into both the sea and their new and improved developer tools. It's worth viewing just to see some features you may not usually use in the browser dev tools, and while they may not be frequently useful, it's nice to know they're there.

We all have our ups and downs. The good news is that so do the greats. Take a tour of the careers of some famous founders and their maybe-not-so-famous failures and successes, all along an interactive timeline.

// Learn

*Today's post brought to you by the 90's.

Coming up with a color palette is hard. Coming up with a color palette for a data visualization that shows a clear difference between data sets, but also presents a cohesive and unified visualization is even harder. Graphiq engineering recently wrote about their process (right down to a scientific breakdown of how much hue difference there should be to distinguish between data) for choosing a color palette, and it's well worth a read.

We could all use a brush up on our grammar. McSweeney's interactive guide uses JavaScript and CSS to give an animated explanation of some of the trickiest grammar issues. Also, it's beautiful.

Did you know there are approximately a billion different types of cursors? Check them all out here, and learn how you can manually change your cursors to thoroughly confuse every single user of your site by straying from the default.

// Read

Medium recently did a redesign, and in getting clever with their naming conventions, found they had conjured up a ghost from the past. It's a gripping CSS horror story that will have you rooting for the ghost by the end. Sound intriguing? Read all about it here.

Years ago, my web professor began our class by telling us, "What if I told you there was a way to make a website that's totally responsive, has a fast load time, and works in every browser? You can— it's called just using plain HTML." Unfortunately, the downside is that this is no fun. But if you've ever had to make a fallback for those seemingly mythical few who have JavaScript turned off on their browsers, this article from Wired is for you. Turns out, they may be onto something.

// View

Remember the good old days when CSS was just a mere afterthought, no one fussed with JavaScript, and default styles ruled the web? It's still here.In other news, the days when things were allowed to cease existing peacefully and not become archivable on the Internet are dead.

And with that...

In life and in code, it's best to be honest. Writing code that is clear and upfront about its intention and purpose reduces confusion and headaches for everyone involved, so let's all pledge to decrypt our code and make it a painless experience. Disclaimer: This post is mainly based off of JavaScript, but with some imagination, these can extend to other languages as well.

Declare your intentions.

Be upfront. As soon as you know you're going to be using a variable, declare it. This means putting all of your variables at the top of a function. Think of it as setting up the characters that your story is going to use. You want to give the readers of your code an idea of who the main players of the function are going to be. Of course, all your variables will end up being hoisted up to the top of their scope anyway, but this adds to readability and makes it clear which scope the variable will be available in.

It's also helpful to add a few lines of commenting at the beginning to describe what the program will do. Think of it as a thesis statement for a viewer (or future you) so they know what to expect in the lines to come. And if you'd still like to add some clarification, you can...

Test your assumptions.

How many times have you written something that in theory, should work, but at runtime something unexpected happens? We can't predict every outside force that is going to act on the program, and this is where testing comes in. Writing tests helps in a couple of ways: first, by writing them out, you're forced to be very clear about what your program should be doing, and what you expect the result to be. Second, you can find out pretty quickly if this is what the program is actually doing. It's hard to predict exactly how every aspect of a program is going to be received by the environment we're running it in, so writing tests helps to ensure it's being received the way we intended it to be. Starting out a program by writing tests for it first makes sure your code is staying on track with its purpose, and that you're always working on functional code. And as an added bonus, you can go forth and refactor confidently knowing that you aren't breaking your code (or, at the very least, knowing exactly what it was that you did that broke it).

Be clear.

Name your variables for what they are. Name your functions for what they do. Think of your program as a story, and each function as a chapter. Choose the names of variables and functions so that when written, your code flows as closely to a complete sentence as possible. Ideally your functions would flow semantically, and it should be obvious when reading through how each contributes to the program's narrative. A good exercise in seeing the ways this can be done is reading through If Hemingway Wrote Javascript, which breaks down how different authors would solve common coding problems in their own style.

Hemingway’s prose is never showy, and his syntax is almost obsessively conventional. 

— Excerpt from If Hemingway Wrote Javascript

Hemingway's imagined solution to the classic Fibonacci sequence problem. Note the simple naming conventions, and no-nonsense methods. Excerpted from If Hemingway Wrote Javascript.

Think of your audience.

It's easy, sitting there with your head in Sublime, to forget that you're not the only one who will be seeing your code. With that in mind, write for your audience. Keep in mind that a new viewer to your code doesn't have the full context of the program that you do. Continue to ask yourself as you write what clues you can add to your program to give more context to an outside viewer. Is there a variable that looks out of place because it's relying on the syntax of a gem? Add some comments to clarify why it's there. Find ways to keep your audience on your level of understanding.

Clean up your code.

If your intentions for the program or a function change, rewrite your code to reflect this new purpose. We've all written code with good intentions at the time, but then our goals or intentions changed, and the code we originally wrote no longer serves a purpose. Going back to rewrite or delete code that is no longer serving the purpose it needs to as soon as possible helps your program flow, and also helps to ensure that every piece of the program is serving a specific and clear purpose. In other words, if a piece of code is no longer needed, let it go.

After writing a program, go back to rearrange the functions in the order that they are called. Ordering functions in order of use makes it clearer for others to see what the interactions between the functions are. It also makes finding functions a lot easier— if you know when in your program the function should be called, you also have a pretty good idea of when it should appear in your file.

Explain yourself.

Even after all of these methods, there may still be areas where a reader of your code can get lost. If you think there's a chance for confusion in your program, add comments to clarify why a function exists or what exactly it's doing. Err on the side of over-explaining, and your readers will thank you (but don't get crazy— your project should be more code than comment).

Be mindful.

And by that I really mean, don't be careless. If a variable only needs to be in scope of one function, don't allow it to become a part of the global namespace. If a function really belongs to a class, make it a prototype, and don't let it become a global function. Be honest with each part of your program about what it does, what other elements it should be able to interact with, and what other parts have access to it. Keep everything in its rightful place.

One place where this really becomes an issue is in the global section of your program. If you've got a lot of variables mixing around in the global namespace, and functions that can be called at any time, it's much easier to run into unexpected issues with conflicting variables. Again, think of it in the context of a novel: It's much easier (and enjoyable) to follow a novel that handles one plotline at a time between just a few select characters, as opposed to a novel that's trying to simultaneously juggle multiple plotlines between fifty different characters.

Any other tips on keeping your code clean & honest?

It's the end of the week, which means it's time for the weekly Chrome tab closing purge. From my browser to yours, here are the tabs that caught my eye this week.

Every character of Hack, painstakingly laid out for you.

TO TRY

A prettier font for Sublime.

If you also spend a Cinderella-esque amount of time trying to find the perfect typeface fit for your Sublime, Hack Typeface by Chris Simpkins is worth checking out. I've only had it up for a day, but it's a nice fit and easy on the eyes, especially when paired with the Material Theme. Another typeface favorite is Monoid— go ahead and spring for the fancy dotted 0's.

More on fonts.

If Hack or Monoid aren't quite working for you, check out Simpkin's comprehensive list of source code typefaces at Codeface. Think an alphabetized list of every typeface possibility, complete with real, coded examples of each one. Never deal with an unpleasant x-height in Sublime again.

What could have been: Google's JavaScript.

Did you know Google decided a few years back that JavaScript's shortcomings were irreparable, and so they made their own version? They did, and it's called Dart. It's up and running, and you canlearn more about it here. Although it's still pretty similar to JavaScript, some notable differences are the declarations required when passing parameters and using variables, which A. make your code easier to understand, and B. give added functionality based on the type specified. For example, functions that are event handlers are passed an parameters like this: function (Event e), instead of the usual function (e). It's a little clearer inside the code, but also may get a little cluttered with multiple arguments. Try out their demo for yourself here. (Also worth noting: it may still be in development?)

Part of the Parallax tour.

TO READ

Yes, another Parallax site.

But this one's really, really cool. Dave Gamache created a Parallax Demoto go along with his post of the same topic to demonstrate one that transitions smoothly and effectively. Parallax is one of those things that looks so simple, but it can be made or broken in its nuances. To learn more about what makes it so effective, read his blog post about it here.

Grids! In! CSS!

Seriously. CSS has now implemented its own Bootstrap-like grid system, built in. Although it's not widely supported in browsers yet, get excited, because this thing is happening. Patrick Brosset gives a pretty good rundown of it here in his post CSS Grid System. Let's all vow to spend some time checking it out this week.

Hanging punctuation: It's where the magic happens.

TO DO

Problem Solving in Character Animation

Khan Academy and Pixar recently teamed up to create Pixar in a Box, a free class that details how the team at Pixar uses problem solving in various ways to tackle the challenges in animation. Their creation of subdivision is particularly interesting: seeing a need to create complex curves through simple means, they created a way of adding points and shifting them along a square to create a shape that moves fluidly, but that still only needs to be manipulated through a few points. The class is broken down into each step of the creation process, so it's also (thankfully) pretty comprehensive.

Hang your punctuation.

You know when you see non-hanging punctuation in the browser, and you start twitching? Now there's a library for that. Typeset.js pre-processes your HTML to give you such beautiful and much-needed features as hanging punctuation, optical margins, and small-caps conversion. You can finally rest at night knowing you've left all your quotation marks outside the margin, where they belong.

Designing for news.

Okay, to be fair, this has been around for awhile, but if you also haven't heard... Francesco Franchi, of the infographic and news design fame, released a book on news design under the apt title Designing News. Designing for news, particularly today, is a changing medium facing a lot of challenges, and this book addresses these and outlines his thoughts on how they might be overcome in the future. Had the opportunity to see him at SND this year, so I'm excited to dive a little deeper into his thoughts on this topic. Read more about it here.

Wikipedia articles are living, breathing things, but it's often difficult to tell just how alive these articles are. For our final project at Flatiron, our team of four wanted to create a visualized edit history for Wikipedia articles, to show information such as how often the page is changing, who is changing it, and what other pages that author is editing.

A Technical Walkthrough (& next steps)

For this project, we pulled all of our data from Wikipedia's APIs. Compared to other APIs, Wikipedia's is extremely user-friendly— they offer many ways to customize the query to return the data you want (for example, we could filter specifically for the category of edits, which is how we were able to find the vandalism edits for a given page), and better yet, there are no call limits.

To control the information that's coming in, we have a Wikipedia wrapper that's making the calls to the API and saving them out to the database. For any given search, it's creating a Page object, 500 past revision objects and 500 author objects, and using these to aggregate revision history data for a page.

Once you're taken to a page, there's a whole bunch of data visualized for you. Look through to see how often a page is changed, how many unique authors have edited that page, and, based on how often it's changed, how volatile this page is. Although this last method relies on the time between revisions at the moment, I'd like to get this method working based off of the time between revisions of all other pages in our database, simply because it would be interesting to know how often this page is changing compared to other pages on Wikipedia.

What happened to Nicki Minaj on July 30th??

We also worked with Chart.js and C3 to develop some visualized graphics. The revision history is particularly interesting, showing how many times a page changes per day for its history. We gathered this data by sorting through all of the revisions we had for the page, sorting them by date, and counting them, and translating this data into some arrays to use as data for the visualizations. As an extreme next step, I'd really like to pull in the New York Times API to show the top news story for that page on a day when it's experienced a huge jump in edits.

The last two days of our project I worked to refactor the vandalism methods out of our models and into a Vandalism helper with some AREL to help lean out the models, and also to add some functionality that we may want to implement later. Right now, we have aggregate data for the vandalism of a page, but it's also interesting to see data on overall vandalism. For example, most vandalism is coming from anonymous authors, and every anonymous author has an ip address that can be used to find the country of origin. We can use this data to answer a few interesting questions— which country, overall, is contributing the most to vandalism? Which users specifically are the worst repeat offenders of vandalizing pages? (Sidenote: another method I'd like to eventually implement would be to find out which categories of pages are vandalized the most, although my gut instinct says politicians.)

Added: PharrellWilliamsBecauseI'm happy clap along if you feel like a room without a roofPharrellWil... #PharrellWilliams#wikivice

We also have a model that automatically tweets out any vandalism anytime it's persisted to our database. This, predictably, had a few issues, mainly stemming from some of these vandalism edits coming from the deep dark abyss of the internet. At the end, I made a working method that searches through the words of a tweet at the critical point BEFORE it is immediately sent out, (think: a bouncer), searching to see if it has any of the offending language, and converting it to a slightly less awful (read: vowels starred out) version. Unfortunately this method is not perfect, and where there is a will to use profanity, there is a way, so this method needs to take into account special characters and a more extensive list of words before it's perfect. For next steps, I'd like to increase the list of terms it's searching against, as well as blacklist some terms. For example, if a racial slur comes up, the tweet won't get sent at all. There's a fine line between mean spirited (like racist edits) and funny (someone repeatedly injecting the lyrics to "Happy" on various parts of Pharrell's page).

This project came together in two weeks, which is a little crazy, and I'm excited to see where we'll be able to build it out and grow it from here. Visit my other [super, super talented] teammates on Github here:

Abhijit Pradhan, who was the main force behind switching our program over to mass assignment to our database, notably cutting the load time from 30 seconds down to a much more reasonable 7;

Heather Petrow, who created the parser helper to go through all of our revision content and turn them into something a human can read—no small feat if you've seen what Wikipedia returns to you content-wise; and

Mitchell Hart, who worked to create the anonymous author by country map, and also got our vandalisms being sent out via Twitter, releasing our project to the world.

Visit the project at wikivice.org (another thanks to Mitch for setting that professional URL up) and find us on Github here.

A little over a year ago, I found myself in a classroom of Typography students, assigned a book on sketchnoting and tasked with filling a moleskine throughout the course of the semester for a grade. Our only prompt? "Doodle."

It was one of those assignments that was so wildly vague and intimidating and seemed like so much more effort than just, you know, writing stuff down, that of course everyone put it off until the last minute, frantically trying to sketch and add visual cues to notes written months prior.

I was one of those students, drawing graphs and 3D-ing lettering at the last hour before final project turn-in, cursing our professor for making us waste our time on something so trivial when we could have been out there designing. And then about halfway through the notebook, I realized I was really enjoying it. It was fun making my notes look nice, and organizing the content in a way that made a little more sense than just writing line after line of text.

After that assignment, sketchnoting started slowly making its way into my life, anytime my hand hit paper. I realized I was retaining more information, staying more engaged during lectures, and drastically improving my (heretofore, kinda primitive) drawing skills. It was addicting.

There's a whole movement dedicated to furthering the spread of sketchnoting. Too often, doodling is discouraged, seen as a sign of being distracted or rude. However, it's actually an extremely effective way of learning: sketchnoters retain 30% more information with doodling than without. Consider this: instead of just taking in auditory information, you're creating visuals with it. And beyond just writing down what's being said, you're making instant connections to the information you're hearing and connecting it with visual cues in your notebook. This means that instead of just taking information in, you're taking in the information and immediately putting it to use, giving it a much better shot at being recalled later.

At Flatiron, we often have multiple lectures covering multiple topics throughout the day. This is a lot of information coming at us. Sketchnoting has been a great way to help retain information that otherwise might have gone in one ear and out the other. Drawing out these complicated concepts gives the brain a second chance to process them right away, and offers a chance to organize these gigantic topics into more manageable, visual chunks. Sketchnoting has been an invaluable addition to learning (So, yes, Professor Scherer, you were right— I did thank you later), and it's super easy to start. Interested in trying it out for yourself? Check out the video below for some quick tips on sketchnoting.

A quick overview of Sketchnoting:

One of the things I appreciate the most about the program at the Flatiron School is the focus on not just teaching you to be a skilled programmer, but a skilled communicator as well. As part of this, we're required to do one presentation per semester presenting with another classmate on something we've learned.

For our presentation, my classmate Elaina Polson and I decided to dive headfirst into Rails and create a playlist app (a bold choice, considering we'd only been Rails programmers for a few hours at that point). A brief overview of our first experience with Rails, below:

The Problem

We listen to playlists. A lot. And we often rely on websites or apps to curate these for us based on our tastes, mood, etc., especially when we're looking for mood-setting music to match our energy levels. When we're working out, we want consistently upbeat songs, whereas when we're studying, we want more low-key music that will blend into the background. The issue with many current app-based playlists is that they curate playlists consistently on genre, but not so consistently on the BPM (beats per minute), and energy level of the songs. This leads to playlists that ebb and flow in energy level— not ideal.

The Solution

Enter Tempo. Tempo works by taking in songs from Spotify’s API and sorting them into four different activity categories— sleep, study, party, and workout— based on their tempo. Choose your activity, and Tempo returns a playlist with songs organized by beat, creating a playlist that seamlessly flows in energy level from one song to the next.

Code

After brainstorming ideas and outlining a plan of attack, we began with the basic Rails framework, and set about creating our schema. We started with the basics, and decided each song would need an artist and tempo. Next, we worked on a way to sort a set of songs into various categories, using some Ruby case statements. After we had this working, we made a SongSorter class that, as the name would suggest, ultimately would be responsible for handling all of the sorting of songs. After making sure this worked with our own seeded data, we decided to start adding more impressive functionality. We started with using Spotify's API to seed our database with current songs, and iterated through JSON's song objects to fill our database with the information we were interested in— namely, title and artist.

Next, we used this data to scrape Echonest's API. Their JSON returns one song at a time, with a lot of useful classification information like energy, duration, and tempo. For our purposes, we were interested in the tempo, and added this information to each song in our database. After we had this working, we began working with the views and controllers to set up our routes and make sure the information we had gathered would show up appropriately on each page. Finally, we added a few design elements in CSS so it wasn't just a plain page, and then used Spotify's embedding features so the user can play the music straight from the page (although ultimately, we would love to get the playlist function working so each playlist's show page would have the embedded playlist right on the page.)

Challenges

We faced a few challenges, mostly due to us being new to the Rails framework. Thankfully efficient Googling solved many of our problems, and persistence solved the rest. The most difficult adjustment was trying to navigate the the file structure of Rails, and making sure we were placing everything in the right folder.

One of the most challenging issues was figuring out the scraping and how to circumvent API call limits. The site we were scraping only allows 150 calls per minute, and so we had to adjust our algorithm to ensure we wouldn't be calling more than this. As API call limits were something we had never encountered before (hell, API keys in general were a new concept) it was a bit difficult figuring out how to make the program functional and not overreaching our call limit. Ultimately we decided to cap our limit of song requests to the maximum, but ideally in the future we would like to instead cap each playlist at a certain amount of songs, which would allow the playlists to all be the same length while staying within the call limit.

Future Plans

Ideally, we would love to create an option where the user could choose to run the app on their own music library to create an extremely personal playlist. After all, you're much more likely to like the songs if they're already in your library. We would also love to incorporate a couple more variables into the sorting algorithm. When scraping Echonest's API, we get a lot of information per song, including a calculated danceability score. This could help sort songs into certain categories and help make sure they stay out of others.

The Experience

It is incredible to me how much we've learned in just six short weeks of coding. Even two weeks ago, I wouldn't have been able to build a web-based application in Rails scraping multiple websites. I also learned some valuable lessons. Although it was easy in the beginning to get carried away with the possibilities of functionality we could add, we needed to start super, super small and unimpressive, and then build up from there. This cemented in Avi's words of advice to make it functional first and foremost, and expand on it later. It ended up being helpful because we had a working app from beginning to end, allowing us to add functionality and test at every step of the process.

Failing is one of those things we’re taught to avoid. It’s positioned in direct opposition of succeeding, in the way of being great at something.

And rightfully so: it can be awful. You know it isn’t the result you wanted, and yet here you are, exhausted, with a wholehearted effort that looks more like a flop.

Except for one thing— failure feels kind of great.

There’s something kind of great about throwing yourself into something so fully. Something that often gets forgotten about in the middle of failure is progress. Failure can suck, but it’s still progress, and movement in any direction is better than no movement in any direction at all.

On our first day at Flatiron School, Avi Flombaum told us to enjoy ourselves because, “You’ve already jumped off the cliff. It’s not going to do you any good to scream all the way down.” It’s a good reminder to enjoy the ride. If you're putting in work toward something you’re passionate about and want to get better at, failure is going to happen, inevitably. Without it, you’d just succeed at everything, which would suck even more than failure. Imagine never having to struggle through something, and getting everything you’ve ever wanted to learn on the first try. Nothing would be rewarding anymore.

However, there are some ways to, well, fail at failing. A failure born from a half-assed effort that was never really given the chance to succeed provides less of a lesson than a failure born from a full effort. So really, it’s less about failing, and more about failing smarter— or rather, failing, not flailing (coming back full circle with the title).

How to Fail (& Hopefully Not Flail)

Learn from every aspect of the process.

As soon as something pops up that’s unfamiliar, make a point to look it up. An old literature professor used to make us religiously write down and look up every term in our readings that was unfamiliar to us. It felt cruel at the time, but it’s been an extremely beneficial habit to have in the ol' learning arsenal.

Go back and redo.

Some of the most clarifying times in code for me have come from going back and revisiting a problem I felt like I mostly understood, but was still fuzzy about how a few parts work. It’s easy when working through something to breeze by because you’ve got the gist of what’s going on, but it’s often those little minor details that don’t fit into the gist that will trip you up later on. Going through something that isn’t totally clear step-by-step will help you realize where you need to fill in the gaps in your understanding.

Be open to learning.

Most importantly, perhaps the best way to avoid ineffective failure is the willingness to learn. I think it’s a natural tendency to start shutting down when you sense that you’re not doing well. However, that’s the time you stand to learn the most. Being open to learning and understanding why your effort is heading south is like, the single greatest possible way to learn exactly what is going wrong, why it’s going wrong, and learn how to not make that same mistake again. It’s like putting a binding.pry right in the middle of your effort and tinkering with the elements until you figure out what’s working and what isn’t.

Embrace the stupid.

Success != Success

Sure, the answer may be right and the problem technically solved. But is there a better or more efficient way the problem could have been handled? How else could you have approached it? Taking a look back at something that's been solved and reexamining the approach can hold some enlightening lessons as well.

The dentist. Karaoke. Rush-hour subways. Each comes with its own brand of unease. But the one that takes the cake is being a beginner. Out of your element, failing way more often than not, and trying to solve problems that you know should be simple but feel so insurmountable at the moment.

I think the hardest part of being a beginner is not knowing where to start. As you learn more about a topic, its intricacies and processes become innate, second-nature. This is missing when you're a beginner. Presented with a goal, an expert has the intuition to decide which steps to follow and which path to take. To a beginner, however, the trip to the solution doesn't feel so much like a quest as it does trying to access a fortress surrounded by a deep and bridge-less moat. Sure, there are obstacles in both routes, but the expert has the tools and confidence to face any problems that should pop up. The beginner does not. The beginner gets to the moat, realizes they didn't bring any tools with them, have no prior experience to help them figure out how to solve this type of problem, and moreover, didn't even bring a swimsuit.

Learning Ruby these past few weeks, with no prior experience with such a conceptual language, I've felt like a tool-less, resource-less, clueless and bumbling n00b for most of my time there. It's hard to learn something new at such a fast pace. But I think the hardest part has been trying to kick the mentality that I need to know how to solve the whole thing all in one go. It's hard to kick this because it's the gut reaction, and it's (partially) true— you do need to solve it, and eventually you will need to know all parts of the problem to solve it. But the key difference is that you don't need to know how to solve all of it at the same time. Below, I've detailed a few steps for problem solving, culled from teachers' advice, the wonderful book "Think Like a Programmer," and my own experience. Being a beginner isn't easy. But breaking it up helps.

Read, re-read, repeat.

The best way to make sure you understand what you need to do is to make sure you understand the problem. There's nothing worse than spending time working toward a solution, only to find it doesn't work because it doesn't apply to the problem at hand. Sometimes clarifying with others helps as well. Sometimes something seems clear, but after double-checking, I've realized I was off. That being said...

Appreciate the Detours.

You're going to take some wrong turns. You'll work on a solution that you'll eventually, crap!, realize is completely wrong. But understanding why something doesn't work is adding to your great arsenal of knowledge as well. Sometimes getting off track gives you knowledge you'll need to use down another trail.

Break it Down.

Solving the entire problem at once should feel overwhelming, miserable, and impossible. But here's the secret: You only need to figure out how to solve the first part to get started. That first part can be as simple as restating the problem until you can identify a clear plan of attack. Hell, it can even be forking the repo. If it's working toward a solution, it counts as progress. And once you take the first step, the path ahead gets a little clearer. Working on each step gives an idea of what shape the steps ahead may take. But these steps won;t have a clear direction unless you...

Make a Plan.

Even the vaguest map is better than none at all. Sure, you may only have general blobs of green and blue to guide you, but at least you've narrowed out some area where a quick walk on land won't succeed. Having a general outline of where you want to go is immeasurably helpful in figuring out a solution. If all else fails, making a list of everything you think might work or might be worth exploring can begin guiding you in the right direction. And if it doesn't, see No. 2.

When in Doubt, Consult the Documentation.

If something exists, you can rest assured that someone else has taken the time to explain and define it. This is a great resource for learning more about a concept you don't understand, or to clarify how a method is used. And, more often than not, a trip to credible documentation leads you to discover something you didn't even know you didn't know. A big part of being a beginner is turning the unknown into the known. Learning from the people who know all (or most) can only improve this. And finally...

Don't Get Frustrated.

I mean, you will. Everyone does. But if something isn't working and you feel like you've tried everything and hours later, you're still not any closer to a solution, reach out for help. A fresh pair of experienced eyes can help sort things out and get you past any roadblocks. Also, understand that learning is uncomfortable. Really, really uncomfortable. If you're really challenging yourself, you'll probably spend a decent amount of time questioning your intelligence, how you made it this far without anyone ever telling you how dumb you are, and feel like giving up because if it's this hard, it probably just isn't your thing. But you're here. You chose to learn this, and to spend time working through it because there was a passion and an interest there. Hold onto it. Even when it feels like you'll never get it, you'll always be a beginner, and maybe getting some teeth pulled would have been a more pleasant use of your time. Being a beginner builds character. And working hard for something means the payoff is going to be great. You just have to work through it to get there.