An Extremely Authoritative(tm) ranking of every ex-One Directioner's solo career (backed by *science*) by Becca Barton

<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>


<h2>The *definitive* ranking of ex-One Directioners, ranked by their solo careers</h2>


<p><img src="" style="width: 605px; height: 337.071px;" class="fr-fic fr-dii"></p>

<h3>Louis Tomlinson, Back to You &amp; Just Hold On</h3>

<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><img src="" width="560" height="415" class="fr-fic fr-dii"></p>

<p><em>Tell me these two men are not the same person</em></p>

<h3>Slow Hands - Niall Horan</h3>

<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><img src="" style="width: 599px; height: 377.58px;" class="fr-fic fr-dib fr-fil"></p>

<h3>Harry Styles, A Whole Damn Album</h3>

<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><img src="" style="width: 513px; height: 302.953px;" class="fr-fic fr-dib fr-fil"></p>

<h3>Strip That Down - Liam Payne</h3>

<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><img src="" style="width: 477px; height: 553.543px;" class="fr-fic fr-dib fr-fil"></p>

<h3>Zayn Malik, I Don&rsquo;t Wanna Live Forever, Pillowtalk</h3>

<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>

Read More

Breaking: Sexism is 'financially costly' by Becca Barton

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
  • 5-25min: Rough time female employee spends repeating her question, anywhere from 1 to 100 times, until someone finally listens and answers
  • 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 day a 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 year on 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.

Keeping Tabs, Installment III by Becca Barton

I got bored and made this this week

I got bored and made this this week

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 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.

The New York Times did a really interesting write-up of Minecraft's impact, and how it's kind of accidentally teaching kids computational thinking. At the very least, I think we can all agree it's more effective than the ol' chalkboard lectures of days past. Read the piece (complete with illustrations by Christoph Niemann) here.

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.


Yeah, okay, we all know Steph Curry's amazing, but until now could you really picture how amazing? And hey while we're on the subject, why not take a quick look at every shot Kobe Bryant ever took.

A quick reminder to beware your defaults, lest you send the internet to an unsuspecting family's farm in Kansas.

It's been a long week, you deserve to party.

Dig deep into your emotions.

Keeping Tabs, Installment II by Becca Barton

Here it is: From my browser to yours, the rarely-regular roundup of the tabs that caught my eye this week.

// Play

Currently keeping me going: These quotes from Good F*cking Design Advice

Currently keeping me going: These quotes from Good F*cking Design Advice

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.

*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.

I'm not usually a fan of BMX, but I'll make an exception for this.

Just move your mouse back and forth around this for an hour.

Sooooo cooooool. And seasonal!

And with that...




On Writing Honest Code by Becca Barton

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.

 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?



Keeping Tabs by Becca Barton

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.

Every character of Hack, painstakingly laid out for you.


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 can learn 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.

Part of the Parallax tour.


Yes, another Parallax site.

But this one's really, really cool. Dave Gamache created a Parallax Demo to 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.

Hanging punctuation: It's where the magic happens.


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.








Final Project: WikiVice by Becca Barton

Welcome to WikiVice, a version control history for Wikipedia pages. 

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.)

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 (another thanks to Mitch for setting that professional URL up) and find us on Github here.

Sketchnoting by Becca Barton

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:


Flatiron School Presentation – Tempo by Becca Barton

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. 


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.)


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 vs. Flailing by Becca Barton

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.  

You're a beginner, and could literally not know less than you do right now. So don't worry about seeming stupid— you are! As Milton Glaser says, "There's only one way out. Embrace the failure." 

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.

Creative Problem Solving by Becca Barton

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.