I've just completed one of many overhauls to gregorypark.org. So far, I've gone through a few phases:
No, not StackOverflow, but close. When I am searching for an answer—and just programming-related ones—I do tend to end up somewhere in the StackExchange universe. A big reason for this, I think, is the value those communities place on asking good questions.
What do our Facebook posts really say about us? Some dismiss them as just noise, but several research teams are seriously considering social media as a source of psychological data. A common goal of this work is to discover faster or cheaper ways to measure important but elusive variables, like personality, health, and happiness. While I worked on the World Well-Being Project team, one of our goals was turning the language from social media into useful new measures.
Of the many new things I've learned about over the last few weeks, recursion was one of the trickiest. Honestly, I still don't fully grasp it, because I haven't encountered any problems yet where a recursive solution makes more sense than a simple loop. I hear that there are lots of those problems out there, but at this point, I just haven't had to deal with them.
Move fast and break things was, for a while there, one big company's motto. It probably still survives as personal mantra in many scrappy young minds. According to this philosophy, it's best to quickly try new ideas out to see if they work at all before over-optimizing a useless idea forever (because you never actually tested it).
As a follow-up to last week's post about stereotype threat, this week we were asked to do some self-reflection about our own values. Some experiments have found that reflecting on one's values prior to a performance can reduce performance gaps, and some interpret this as a potential antidote to the stereotype threat effect.
Variable scope, according to David Black in The Well-Grounded Rubyist,
This week, my Dev Bootcamp cohort was asked to write about stereotype threat, one of the most publicized psychological phenomena in recent decades. I'm no expert on the topic, so bear with me. I tried to get through the more sensationalist stuff and get to the core of the effect, which turned out to be a nice diversion from Ruby for a couple hours.
Over the last few weeks, I've been doing a lot of pair programming, described on Wikipedia as:
Lately, we've been spending a lot of time at Dev Bootcamp learning how to organize objects and model behavior with classes in Ruby. That's a really generic description, so here's an example of some of the fun you can have by creating your own classes.
For a few weeks now, I've been immersed in learning about web development. It's been great so far, and I don't want to slow down at all yet, but I often find myself wondering (and doubting) how well I really understand something. This usually happens when I'm learning something new—for example, wrapping my head around git—and I am deciding whether I should keep plowing away at it, or if I should be satisfied for now and just move on to the next thing.
Ruby's #group_by method provides a way to (wait for it) group things by some arbitrary property. It's part of the Enumerable module, so you can generally use it anywhere you'd be using
#each or some iteration. To use
#group_by, you first need to know two things:
Imagine you have one week to solve a big, complex, and novel problem. It doesn't matter exactly what it is, just that you have no prior experience with this problem, and your proposed solution could have a huge impact on your business, colleagues, or family. So you've got a lot of work to do over the next week. If you had total freedom, how would you tackle this?
Arrays and hashes are the two most common way to handle collections of objects in Ruby. Collections (which are objects themselves) not only help to organize our individual objects, they also have some powerful methods for iterating through or transforming all of the objects within them.
Over the last few years, I've spent a lot of my time writing—writing manuscripts, reports, code, and technical documentation. Most of these writing projects take days or months to finish. Some never end. I like to write and revise in small bursts, saving all my new additions, edits, and deletions along the way.
Watching an experienced vim user edit code looks like magic. Awesome magic that I want to learn.
A few months back, a blog post by Darkhorse Analytics illustrated how to enhance a plot by removing unnecessary ink and making other simplifications. The process is animated in this gif:
Over the last month and a half, the Online Privacy Foundation hosted a Kaggle competition, in which competitors attempted to predict the psychopathy levels of Twitter users. The bigger goal here is to learn how much of our personality is actually revealed through services like Twitter, and by hosting on Kaggle, the Online Privacy Foundation can sit back and watch competitors squeeze every bit of information out of the data.
One of my first runs in a Kaggle competition finally ended with the closing of Don't Get Kicked!. It was an excellent learning experience, and I had a lot of fun in the process (at the expense of sleep). Plus, I did pretty well, ranking 36th out of 588 teams!
Recently, updating this blog got a lot harder than I anticipated. I moved to New York, started a new job, got a dog, and discovered Kaggle. What's Kaggle? From the site:
I was lucky enough to receive the awesome gift of a Garmin Forerunner 305 GPS watch recently, and it quickly became an essential piece of running gear. It collects all sorts of fun data from each workout, but my favorite feature is the heartrate monitor, which wirelessly transmits heartrate information to the watch from an elastic band worn on the torso. Having such objective feedback about how hard the heart is working can be very useful info mid-run, but why limit the Garmin 305 to my runs?