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

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.

Peripherally:

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?

 

 

An Internet Expedition (or what I learned navigating a New York Times graphic's source code) by Becca Barton

The best way to learn how to do something is to study the work of the greats. Today, we're going on an expedition through the New York Times' source code. Grab your tools, and let's get started.

Tools

Our map.

Our map.

Part I: A Quick Survey of the DOM

A quick scan of our map shows a typical breakdown: meta tags at the top, some CSS thrown in, followed by some HTML. For the purposes of making this journey concise and expedient, we're going to be mainly venturing through the script in the document. This means we'll be treating the meta tags and social media and Google Analytics like the far-out corners of the map: you're probably not going to need to know the exact terrain, but it's nice to know that they're there.

Moving on, we hit our basic setup in the DOM. Open up the link of our map, and inspect element. Hovering over each element will give us a good idea of what all these pieces are doing. We can see that the header is one element, the graphic is another, and the footer is, fittingly, the end element. Keep exploring the layout of the land, and when you're ready, we'll move on to the meat of the expedition.

Part II: Exploring All Our Routes

Starting out in the source code, let's start with the fun part: clicking on any link that looks like it might have a trailmarker. How will you know what's down a trail if you don't explore it? Starting in the footer, clicking on the first link leads us to the source for the base of the whole graphic: the data. We can see that this graphic's data is coming from the U.S. Census Bureau— pretty trustworthy, and it's worth knowing where all the data's coming from. 

Skipping down to the script source links, the first link shows they're using Google Maps API, which is, mercifully, pretty well-documented. Note the specification in the API url here: libraries is set to geometry. According to the Google Maps documentation, using a setting of geometry adds built-in functions to calculate geometric values, including geographic area. This gives us a clue that they may be adding shapes on top of the map Google's API returns, and a quick check back at our map confirms this, with the area lines for the 'Percentage below poverty' graph, and the circles for the 'Number living below poverty' map. 

Next, we see two script sources linking to different parts of the poverty map, one to the map.js, and one to a lib.js. Looking at lib.js first, we can tell at first glance that it is very, very long, and we are not going to be able to make it to the end of the trail and back before sundown. But the first word gives us a hint: d3 is set up as a constructor, with many functions inside. This tells us that the graphic is using D3, the data-visualization javascript library. Also, this file is not wrapped in a document ready function, meaning that, as its name would suggest, this is a supplemental library file that the other javascript files in the graphic are pulling from.

Switching gears to maps.js, we can see this whole document is wrapped in a (function(){});, meaning it's ready to start firing as soon as the document is ready and loaded. As a quick sidetrack, note on line 7 the (RegExp.$1). According to Mozilla's JavaScript documentation, this nifty method will accept any number 1-9, preceded by a $, and in return will give back one of the nine most recently memorized items from RegExp pattern matching. Not really pertinent to what we're looking at, but much like taking time to identify the name of a tree, it's fun information to tuck into your back pocket.

Part III: Heading Deeper Into the Forest

We're really in the thick of it now. Still on map.js, this is another case of a long trail we're not going to make it back from in time. But a quick scan shows some interesting helper methods being setup here: a constructor called Waiter is setup with some prototype methods to help it wait around on objects in the program until they're ready. A few take an argument of ctx, which according to the experts over at Stack Overflow means 'context', and is usually used to pass around in a program to help maintain state, as opposed to global variables.

A quick overview of some other things happening: This document is setting up a lot of JavaScript objects that are adding some important basic functionality to the program. There are objects changing the CSS based on the state, one to load scripts, a data table object aptly named DataTable, and constructors setting up different document reactions to mouse events. 

This has been fun, but we need to head back to the main trail. Back in the source code underneath the footer, there's more JavaScript to explore. Starting from the beginning, they're setting the variable selected up to the previously defined constant CITY_DATA, which will help swap out the location data depending on which city's map the user clicks on to view. 

Next, a variable slug is set up to normalize text that's being passed in as an argument to a function. From the regex used here, it looks as though it's trying to eliminate any characters that aren't letter characters and then lowercase the result.

The next variable, cities, is calling on the d3 library and selecting elements in the DOM with an id of 'g-cities', and a class of 'g-city'. From here, the following few lines are appending HTML to the cities variable. What this all really appears to be doing is setting up a way to swap out all of the data depending on which city map is currently selected. We can also see that they're using slug to set up a unique link to an image depending on which city's map has been selected. So RESTful!

Now that the city url has been appended, an event is set up to listen for any clicks on cities in the DOM. Once clicked, a function that zooms into the currently set latitude and longitude fires, based on where the user's mouse is. This is a part of D3's library, and it's pretty neat. If you're interested in learning more, checkout this visual.

A variable called selection is pointed toward this (in this case, buttons, which is what's calling this function). 'id' is set to point toward anything in this that has the attribute 'data-id'.  Next a function toggle is called, and if we take a quick peek ahead on the map, we can see that that function is being defined just a few lines below. 

Normally when we encounter toggle in the wild, it behaves by, well, toggling between hiding and showing the selected element. The one we see here in the New York Times' code is a slightly different beast. This one works by taking the buttons and keys and returning a boolean value depending on whether the value of their attribute 'data-id' matches id or not. Then, depending on the size of the window, a certain image is returned for the map.

Looking ahead, we see a try/catch statement, which is a classic JavaScript way to try out some code and catch certain data if an exception is thrown during the execution of the try block. Here, the try block is checking to see if location data is available, and if not, catching the error event. If it is, the map zooms to the location given the latitude and longitude found during the execution of the try block. Also interesting to note is it's using decodeURIComponent, a JS method that takes a piece of previously encoded information and outputs the decoded (read: pretty) translation. For example, you know when you see a %20 in a url to indicate there's a space there?  That's the encoded version. The decoded version would read with the spaces, as in "personal space".

Part IV: The End of Our Journey

At long last, we've come to the sweet, sweet end of the trail. We saw a whole lot of code here today, some setting up mouse event functions, some setting up conditions to swap out images, and some setting variables for D3. And while we didn't go to the end of every trail and back, much like a typical hike, simply exploring the main trail and taking a quick peek down the side trails gave us more than enough to explore. We saw some interesting sites and learned some useful things today, so go ahead and head home with the pride that you now know a little bit more about the wilderness that is someone else's source code today. 


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.

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

TO READ

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.

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.

PERIPHERALLY

 

 

 

 

 

 

Recursion by Becca Barton

Recursion. It's a fun word. But what is it?

A quick explanation is that it's a clean way to perform a repeat task on an element that is continuously breaking that element down into its most basic parts in order to reach an end goal.

The longer version goes like this: Say you have something you're passing into your function via an argument, and you know you want that information to be manipulated within the function. So you have your starting information, and a clear idea of what the final information should be. You know you could use a loop to manipulate the data until it reaches the certain end condition, but you also know that a loop could take many lines of code. Enter recursion. 

Recursion is useful when you're faced with the dilemma of trying to perform the same action until the variable meets a certain condition, but you're not totally certain how many iterations it's going to take you to get there. 

It is, essentially, setting up a loop. So why doesn't it just keep going on forever and ever? The key to recursion is that eventually, every problem is broken down into its smallest possible part, known as a base case. On each iteration, the the problem is being broken down into a simpler version of itself, until it finally reaches the simplest version of itself. By setting up an if condition, 

When I first came across this in programming, it sounded like a foreign concept. Calling a function within itself? It sounded less like a way to solve a problem, and more like a way to break your terminal. Outside of coding, though, we actually encounter recursion all the time. Think of a tree: it starts out as one large trunk with many large branches, but follow any given branch out, and you'll find that it breaks down into smaller and smaller pieces, until you've eventually reached the smallest twig at the very end. It even happens in lightning (see: cool GIF on the right).

So how does it work? Setting up a recursive function has a few criteria. First, there must always be a defined base case. This is the most basic, simplest possible form of the data. Think of Russian nesting dolls— the starting point is the biggest doll, and on every iteration through, you're dealing with a smaller and smaller version of the doll until you eventually have broken it down into the smallest, most basic form, which is the tiniest doll.

(Re)curse With Caution.

Another important thing to keep in mind is that for every problem that can be solved recursively, there's also a way to solve it iteratively, through a loop. The benefits of using recursion include it being a bit more elegant and concise. After all, you've already written the code to perform the exact function you want— why not reuse it?

The downside to its implementation is that because it's calling itself, it's adding a new series of requests to Ruby's performance stack. This means that typically, recursion is going to be a slower way to solve a problem than implementing a loop. Knowing what your priorities are beforehand (eg. readable code? faster performance?) will help you decide which route is the best for your problem.

It's an elegant way to avoid eating up twenty lines of code setting up a complex set of nesting loops. It's also a great way to impress your programmer friends. The key thing to remember: recursion is great, but there's a time and a place for it. If you're looking to create clean and elegant code, go right ahead and use it. If, however, your main concern is speed, use with caution.

Okay, so how would YOU use it?

Kinda like this.

Kinda like this.

Recursion can be used in a lot of different ways. Here's my dream program for using it. Anyone who designs has probably spent a fair bit of their time sifting through their font library trying to pick the perfect font. A little bit of recursion could be used to solve this dilemma.

Say you're creating a design and need to pick the perfect typeface. Opening up FontBook, you can see you have about 500 options. Now, you could go in manually look at each of the 500 versions, or you could use recursion to separate all of your fonts and return the useful ones to you. Imagine a program that does this heavy lifting for you, eliminating options and just returning the relevant ones.

You need to sort this unwieldy list of hundreds of fonts into a much more manageable one. Nobody has time to sit there and type out 'partyhats' in 600 fonts. Instead of setting aside a Saturday and manually organizing all of your fonts into nice lists, let's stop and consider that we're programmers, and we can use programming to solve this problem.

Each font can have many categories. It can be sans-serif (lineale) or serif, but also geometric, or humanist, and it can also have different feelings (elegant? quirky? assertive?).  Imagine a program that would divide this one gigantic list of fonts first into a few basic smaller ones— serif, sans-serif, script, and slab-serif. Now instead of one complicated and category-filled font list, we've separated it into multiple simpler piles. This isn't simple enough, though. Next, we want to further sort each of these piles into even smaller, simpler versions of themselves, using their specifications. For example, we want to look through the sans-serif pile and assign each font into either a humanist, geometric, gothic/grotesque, and neo-grotesque. For serifs, we want to split each pile into smaller piles of old-style, Didone, and transitional (we could get into an argument that slabs belong in this category, but let's just agree that slab-serifs deserve their moment in the sun). From there, we can separate further into any number of categories, such as feel, time period, etc., depending on what your preferences are. 

This program works by using recursion to take one large problem, and breaking it down on every iteration into smaller and less complicated versions of itself. We eventually end up with a collection of base cases, or fonts sorted into their respective piles. We want the program to keep running until each font can't be sorted anymore, but we aren't sure how long this is going to take because we don't know how many categories each font has, or how many fonts the user will have. Recursion takes care of both of these unknowns by sorting the fonts until they just can't be sorted anymore, as opposed to sorting them a certain number of times. 

To finish up our ideal font sorter, we'd also like to see the program take in parameters from the user, including the categories they'd like to explore and a test phrase, and return a given phrase in each of the fonts from the list that best matches the criteria of the user.

If you'd like to start developing this with me, hit me up.




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 wikivice.org (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. 

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