Adventurous

Chris Murphy

In which I write about things I've learned recently, before I forget. That gives me at least a few hours to write...

Search

22 Dec 2011

December 22nd, 9:22pm 0 comments

Adventures with Sous Vide

So I got a FoodSaver recently on a great sale. It's something I've wanted since I was just a little 10 year old captivated by the infomercials. I can't remember if it was my mom raising me to obsess over the potential savings (it'll pay for itself!!!), my inner nerd fascinated by the technology, or just the fact that I loved watching infomercials. An odd duck, that one.

Anyway, now that I'm pretending to be a responsible adult-- or, at least, making a living-- I get to make this type of purchase. And while the packaging and storage is enough to sell me alone, I've learned about other potential uses as the years have gone by.

Sous vide is one of the hot techniques in modern gastronomy. It's not a brand-new technique, but it's becoming quite popular. Sous vide is French for vacuum, and that's literally all that the technique implies: putting food under vacuum. You can achieve this by putting the food in some sort of air-tight bag, sucking the air out, and sealing it shut. There is a range of equipment available to do so, from a standard ziploc bag to a proper fancy chef machine. You might've seen the like on Iron Chef. Using the FoodSaver to seal food falls safely on the upscale side of this range. It's not quite as awesome as what a Michelin rated restaurant would use, but it's a hell of a lot better than a ziploc.

Once you have the food packed up, you cook it in a water bath. Since the food is all sealed away, the water serves merely as a super-efficient heat transfer mechanism. Unlike sautéing, baking, or grilling, the water bath can transfer heat all over the food at exactly the same temperature. And since you have such precise heating, you can manipulate the temperature of the water bath in really interesting ways.

For example, you can cook a steak in water set to the exact temperature that you want the interior to reach -- the nice rare 125F, perhaps -- and cook it for a couple of hours. Since the water is 125, no part of the steak will ever be more than 125. When you're done, the steak won't have a bands of overcooking where the heat was trying to penetrate in order to warm the center to 125. You won't lose as much juice (and the juice all stays in the bag!), and the meat won't toughen up as the protein freaks out. Rare meat lovers should be rejoicing right now...with one caveat.

Since the temperature is so low, you don't get the tasty Maillard reaction that comes with high heat. As a corollary, the steak might look a little unappetizing (it'll look almost like steak tartare). That's why an important final step is to sear the steak as hot as humanly possible, just for enough time to get some color. Since your steak is already cooked exactly how you like, you don't want to leave it on any longer.

One other benefit of the vacuum packing is that you can put some flavorings (herbs, butter, whatever) in with the meat, and the force of the vacuum will help flavor the meat quite strongly. The final result ought to be the best steak ever!

Well, Erica and I don't cook a lot of red meat (we prefer $2/lb chicken breast, thanks), but I needed to try this thing out. I had some carrots, onion, and potato. Why not try it out?

I'd heard rumblings that certain veggies (such as brussel sprouts) become absolutely amazing when done sous vide, so I was pretty excited. I'd like to try brussel sprouts, beets, and other root veggies, but I went with what I had on hand.

I gave the veggies a rough chop and tossed them in the FoodSaver with some butter, salt and pepper, and a little dried thyme. Interestingly, the instructions said not to vacuum raw onion, garlic, or mushroom (???), but I ignored that. My first seal went off without a hitch!

When you're cooking a steak to 125F, you want to be pretty exacting with the temperature. There are many ways to achieve this temperature, and again, they range from the MacGyver to the badass. Since I had a little more flexibility cooking veggies, I went with the big pot o' water on the stove method. It's pretty hard to control the temperature, but I think I'll get better at it with time.

Cooking veggies is different from steak. Since the pectin in vegetables isn't broken down until around 183F, we need to use a pretty high temperature bath if we want to get any softening action. Once again, the exact temperature of sous vide can be powerful here, as you can cook the vegetables all the way through, but leave no part mushy.

I took constant temperature readings, and I pretty much stayed from 182 to 186, with two brief excursions higher by mistake. I cooked the veggies for about an hour, and they felt slightly soft, so I figured, good enough!

I was debating whether or not to finish them in a hot pan, since I kinda wanted to see how they were plain- just the pure vegetable flavor. But then my high-heat sensibilities won, so I got a stainless pan scorching hot, added a little canola oil (neutral flavor fat), and dumped the bag in. I stirred constantly for about 30 seconds, then dumped them on to a plate to serve.

The results were impressive. The onion was probably the least awesome- I couldn't tell much of a difference. I'd hoped that the harsh flavors would mellow and make it taste almost carmelized (since carmelized onions are cooked at a very low temperature), but with a better texture. I think they were sort of on that road, but definitely not as tasty as carmelized onions. The carrots were really good- just a pure carrot flavor, with the perfect texture. Great combination of soft with bite.

I think the potatoes might've been the best. They didn't have the outrageous flavor of a bacon and cheese stuffed potato skin (although you could definitely add some interesting things in there...oh man, bacon fat....), because I didn't put anything in except thyme. But the texture was amazing! Perfectly soft all the way through, no mealy texture (even with just the russets I had on hand, no pre-rinsing to remove starch or anything)....awesome.

Can't wait to try more!

Posted by Chris Murphy

0 Comments

29 Mar 2011

March 29th, 8:21pm 19 comments

Git 201: Slightly More Advanced

So you've made it through Git 102, and you wanted more. Git 102 was more of a justification for some of git's trickery, and a way for me to express my philosophies for using version control. Now that you're through with that, let's see if we can figure out some of git's less known features.

Finding that issue

"The Pickaxe"

So you're doing a code review on a piece of the program you don't normally touch, and you notice that there's a new property of your Person class. Since when did we start tracking social_security_number for our workout app? The pickaxe is part of the internal gitdiffcore, but you won't find it by name in the git commands we all use. Instead, pass in the -S switch with a term to search for. In our case, let's search for that new variable:

$ git log -Ssocial_security_number

This will show you each time that the string "social_security_number" appeared or disappeared from the repository history. It can be very useful, as long as you know what string you're looking for. The pickaxe is one of a few different transformations that the diff uses, but it's really the only one I've used. I'm not even sure if the others, other than order, are intended for the end-user.

You probably know the -p flag for git log, which shows the git diff inline with the log messages. You can combine that with the pickaxe so that you can see a little context while you search. If you use the pickaxe for presenting changes, you might find the --pickaxe-all switch useful. That'll show you the diff for all of the changes in the commits that the pickaxe finds- not just the actual lines that the pickaxe recognized. Try them out:

$ git log -Ssomething -p

$ git log -Ssomething -p --pickaxe-all

**NOTE: originally I typed pickaxe-diff here for some reason. Sorry about that...as mentioned above, pickaxe-all is what you want**

Pretty powerful stuff.

Git Blame

What if you don't know exactly what you're looking for, but you know the file you want to look at? Git has a tool just for you: git blame. Try it out:

$ git blame <file>

This will show you who is responsible for each of the lines in that file. In other words, the last commit that touched the line. This is really useful, but don't use it as an excuse to yell at people. Unless they did something really awful. Okay, not even then.

By the way, this is one of two times that I sometimes like to use GUIs for git. The lines for git blame can be pretty long (even if you modify the output with switches). Just say

$ git gui blame

That'll do the exact same thing, except in a nice GUI interface, which'll make it easier to see the whole line, and navigate between commits.

Git Bisect

Bisect is an awesome idea: a combination of binary search, interactive, and testing that can only result in happiness. Suppose a user reports a bug in your program, and you figure out how to reproduce it. You write a test for it, and sure enough, it fails on current build. You have no idea when the bug was introduced, but bisect is here to help. If you happen to know a version where the bug didn't happen, you can tell bisect to start there. If not, just tell it the beginning of your history.

$ git bisect start

$ git bisect good <sha>

$ git bisect bad master

git will do all the hard work for you. You just have to run your tests at each point that git prompts you, and tell it whether it passed or not:

$ git bisect bad (or good)

Thanks to the power of binary search, you'll find it pretty quick. I haven't found a need to use this feature in anger, but in my simple tests, it worked like a charm. You don't even need to have a bug to test it out- just lie to git about what is good and what is bad.

If you have the ability to run your tests and get a Unix return code (0 for success, non-zero for failure), git bisect run will actually do all of the work for you! See Sam Stokes's comment below.

Branch Management

When you're making good use of git branching, you'll notice that the easiest thing to do is to just merge in your branch to master and move on. But if you do a lot of branching, and you're constantly pulling in changes from other branches, that'll become really ugly, really quick. It may be worthwhile to prevent all of those merge commits, depending on your team strategy. If you want to do this, git (as always) has plenty of ways to help.

Cherry Pick

git cherry-pick is useful for bringing in a selection of commits from any branch. I use it when there's selected bug fixes or feature adds in another branch that I need to pull in to my working branch.

As with all git commands, you can tell git which commit you want to cherry-pick in a variety of ways, but to be honest, I almost always explicitly call out the sha-1. Use git log or gitk to find the sha-1, then:

$ git cherry-pick <sha-1>

Here again we see the value of keeping your commits logically separated. Otherwise, a simple one-liner turns into manual file editing, which is just asking for mistakes. Why not let git do the work for you?

Rebase (onto)

You already know about rebasing from Git 102. In that case, we just rebased the master branch, but we can do so much more. If you decide you don't want a merge commit to show in master, you can do the following in your feature branch:

$ git rebase master

$ git checkout master

$ git merge feature-branch

Since you already did the work to rebase the changes from master with your changes in feature-branch, when you merge into master, it'll be a simple, fast-forward merge. No merge commit.

The next step is to use rebase across multiple branches. If you often float back and forth between fixes, this one is for you. As usual, the man pages have all the information you need, but it can be a little difficult to untangle. Let's see what we can do with --onto:

git rebase [-i | --interactive] [options] [--onto <newbase>] <upstream> [<branch>]

If that makes as little sense to you as it did to me, read on.

You feed git rebase --onto three things: the place where git should play commits onto and the two places to compare commits from. So if you do a simplified version of the man page's example:

$ git rebase master~5 master~3 master

In our case, master looks like this:

A-B-C-D-E-F (F is HEAD)

Git checks out master, then looks at master and master~3 (three parents from the HEAD) and figures out what commits are in master, but not in master~3. In this case, that would be D, E, and F. It applies those commits onto your current branch, at the starting point of your first argument, which is master~5 (commit A). Using git's friendly message terminology, it rewinds HEAD to master~5 (it actually does exactly what a reset --hard would do), then plays back commits D, E, and F. The newly rebased master looks like this:

A-D-E-F

Put simply, rebase killed B and C from your tree. That's pretty awesome. Now we can tackle the more complex case of working around branches:

Look at the example from the man page with topicA branched from master and topicB branched from topicA:

The page says to run git rebase --onto master topicA topicB to get commits H, I, and J applied to topicB, starting at master. Since topicB was branched from topicA, it has all of the commits in the picture in its history. But topicA doesn't have any of the commits of topicB, so rebase will find that H, I, and J need to be applied to your target, which is topicB, which has been reset to the starting point of master. The end result is equivalent to if you had branched topicB from the same place that you branched topicA.

Sometimes, I like to think of the command as playing back your commits onto master, because at the start of the playback, your current branch and master are identical. It's a useful simplication, but to be perfectly correct, you should remember that the commits are, in fact, played onto your current branch. Since the last argument of the command is the branch to check out, that will always be the branch commits are played onto.

You should note that the man page's previous example with topic and next is actually identical. The only difference is that master has moved on since you branched next. This demonstrates that the commits are played back starting at the point of master's HEAD (since that's what you told it to do)- it has nothing to do with where the first branch (next or topicA) branched from.

Recovering from Mistakes

git reset

Sometimes, you just can't gracefully back out of a messed up manual merge, rebase, or plain ol corrupted working tree.

$ git reset --hard <something>

That'll reset your current branch, index, and working tree (for less than all three, try --mixed or --soft) to whatever you tell it. Most often, I'm running it against origin/somebranch, to reset to the last pushed state.

Ok, so you probably already knew that one. But what about the untracked working tree files that get spewed around sometimes (p4merge on Windows leaves .orig lying around all.the.time.)?

git clean -fd

clean will kill off all of those pesky files that you haven't added to git, and want gone. Since git is so safety-conscious, you have to force it with -f, and you probably want to tell it to get rid of the directories too, with -d. With reset and clean, you should never have to rm -rf and re-clone again.

The reflog

All this playing around with hard resets, rebases, and whatnot might scare you. What happens if you hard reset two days of work? No matter how careful you are, this will happen eventually). Well, git hasn't really destroyed everything permanently, at least until the garbage collector comes around. If you accidentally trash something, just type git reflog to see a list of the last operations. Here's an example:

$ git reset --hard HEAD~2

$ git reflog

7298e1e HEAD@{0}: HEAD~2: updating HEAD

ca9164c HEAD@{1}: Oh man this is the best algorithm ever. It sorts in constant time!!

$ git reset --hard ca9164c

*phew*. You obviously shouldn't rely on this, and if you're digging into the reflog every day, you should probably re-evaluate your git strategy. But it's great to have that safety net there when you need it!

Filter-branch

One last tip. If you're working in an open-source environment (pushing to GitHub, for example), you'll want to be careful not to commit any sensitive information. As we've seen, any commit is part of the repo forever. That is, unless you rewrite history. That's what filter-branch is there for. As you might imagine, GitHub has an excellent article to show you how to protect yourself.

By the way, anything that's hanging around in reflog waiting to be gc'd won't make it out if you push to GitHub, so don't worry about that. You can still kick off gc manually if necessary.

Bonus tip: if you're constantly merging from other branches into your working branch, and then either resetting and re-merging or rebasing, you will want to check out rerere. If you enable it, git will track all of your conflict resolutions, so that if you do one once, you won't have to do it again. I got bit by repeated manual merge for the last time today. I can't explain it better than Chacon, so go read his post!

Posted by Chris Murphy

19 Comments

27 Mar 2011

March 27th, 11:23am 0 comments

Git 001

Git is a wonderful version control system, but it does have a bit of a learning curve. The learning curve is made worse because git is so much more powerful than Subversion (for example). When you first try to learn git, it's confusing to sift through all of the powerful features people excitedly write about, just so you can find out how to do the simplest SVN use case. Annoying.

I want to write a post on those advanced features, but when I reflected back on my learning process, I realized that it wouldn't be fair to make the situation worse. With that in mind, here's my simplified guide to git- nothing but the absolute basics. It's not even git 101, it's git 001. If you don't need git 001, skip to git 102. There is no git 101- that's covered all too well online.

[Assumption: you have git set up for development on your team's repository. If you don't, there are a million tutorials online, but I'd honestly recommend just asking someone to do it for you. If my motivation lasts beyond Git 102, I'll add another post about setting up]

The first time you want to track the version history of a file in SVN, you add it with svn add. Do the same with git:

git add <file>

The same goes for removal. The analogue of svn delete:

git rm <file>

When you've added, deleted, and modified to your hearts content in SVN, you commit to the repository with svn commit -m "message" <repo>. Do the same in git:

git commit -am "message"; git push

Why is this different? Git is a distributed version control system. For your purposes, that means you can have the entire power of SVN on your local box. To pay for this power, in order to share with other people, you have to publish your commits. Let's look at that last line piece by piece:

git commit -am "message"

The only purpose of the extra "a" is to imitate SVN's commit command. In SVN, when you commit, it commits everything that you've modified, as long as you've once added that file before. It also commits the fact that you've deleted a file, as long as you've told it with svn delete <file>. the -a switch for git does the same thing. Later on, you'll realize the power of not supplying -a, but for now, just do exactly what you've done in SVN.

git push

This is the "share with other people command" that is implicit in an SVN commit. The git commit didn't do this because git wants to give you the choice of keeping track of your changes locally, without other people seeing. Again, you'll see the power of this later, but for now, just share right away, like SVN forces you to do.

If you want to get the stuff other people have done, you need the analogue of svn update:

git pull

That's it. You're done. Life is safe and cozy in the extremely limited SVN world. I'm excluding branches, because branches in SVN are unworthy. See Git 101 for that. But honestly, isn't that simple? The only real point of confusion is learning new terminology, which is no less intuitive than SVN (except that you're probably used to SVN, and thus will complain).

ASDF IT WENT WRONG AND IT'S HORRIBLE

Although it's getting better all the time, git's 'helpful' messages when things go wrong are a little intimidating. I suspect what went wrong is that you got a conflict when you tried to share your changes with the world. This happened because someone else pushed before you did. Since life in the repository has moved on from where you started your work, git warns you that you're not allowed to share anymore. This makes a whole lot of sense when you realize how git represents changes, but for now, let's just fix the issue:

git pull

Now you have the latest state of the repository. If the new changes didn't touch the same files you did, then git will handle everything for you, and you can do a git push again. As long as nobody else shared in those few seconds, you'll be fine.

If the other guy's changes did touch the same files you did, then you have a merge conflict. Git will try to tell you about this in a confusing way. Just do:

git mergetool

This will launch your merging tool of choice and you'll have to do the manual work. No piece of software can do this part, at least until Skynet comes along and we're all relieved of those worries.

When you're done, you need to commit your merge and share:

git commit -am "message"; git push

For your sake, I hope there are no more conflicts- it can be depressing if you have to do this a few times in a row!

This was obviously a very limited subset of git, and you really do need to know more than this. But hey, hopefully now it's not as scary, and you're ready for some more. There are a million excellent resources online. Try http://progit.org/book/ or anything by Scott Chacon. And if you can slog through them, the man pages really do help. If you read through enough of this material, you'll be fine. The real trick is getting a jumpstart on how git can make you more productive, and that's where git 102 comes in.

Filed under git programming

Posted by Chris Murphy

0 Comments

27 Mar 2011

March 27th, 11:21am 6 comments

Git 102

If you have started to feel comfortable using git and have begun to acknowledge its power, but you feel like you're missing out on some of the importance of the advanced features, this post is for you. Before I jump into the use cases and commands, I'd like to explain a little motivation.

As you should know if you've read enough about git, one of the many interesting things about the design is that a commit in git is just a snapshot of the current repository. Yes, the entire repository! Of course, due to algorithmic awesome-tude, this is compressed against time, so it's not horribly inefficient to do.
If you want to read more about the internals (which I highly reccommend), check out Git from the Bottom Up.

I think that fact of git's design is interesting in and of itself, but most especially because it reveals intent. Git's awesome flexibility and power are useful because they allow you to manipulate your changes into logical steps that you can present to your team. It's no surprise that this is one of git's strengths, considering it was developed to do version control on the Linux kernel. Without a system that allows such manipulation, Linus would be impossibly swamped with work trying to extract meaning from hundreds of commits coming from all across the world. While most of us are lucky enough to not have such a large team, the same practices that make their development efficient can be applied to yours.

The value of having logically divided commits should be obvious, but very few teams recognize it. Having monster commits that touch dozens of files across multiple bug fixes, feature requests, and performance enhancements is barely better than not using version control at all. If you're doing that, you're basically using the VCS as a handy interface to copies of your files (current_working_view.py, latest_view.py, good_view.py, good_view2.py, view_broken.py, etc), like most of us did in our teens when we first learned how to program.

Don't believe me? What are you going to do when your customer wants to take out the feature you just added if that feature was thrown in with a bunch of other, unrelated code? You have to manually go through all of the files that that feature touches, remember how you added the feature, and manually remove it from each part of the code. You'll also have to test your entire project again, to make sure you didn't kill something you didn't mean to.

If you were using git and making sensible commits, you'd be done in one command, and it would take seconds. Awesome.

Hopefully I've sufficiently motivated you to want to know how git enables such precise breakups of changes. Here we go!

There are two different steps you need to learn: how to break up a commit into smaller commits, and how to mash up many commits into fewer commits.

The first way is the most relevant to developers who suffer from the monster commit plague, so let's do that first.

Let's imagine you just finished up the feature you wanted to add to the project. Only, along the way, you noticed that a few people forgot to format their code properly, so you did that. And oh, that function is no longer in use, so you removed it. And QA stopped by and told you about a bug, so you fixed that. Now you have a monster commit situation, but you're ready to defeat it.

Learning to love the git index

No, it's not just a way for Linus to make you feel stupid for forgetting to 'git add' or 'git commit -a'; the index is actually very useful! You've made changes to too many files, so you shouldn't limit yourself by using the SVN-esque 'git commit -a'. Do a 'git status' to get ahold of the situation- figure out exactly how many files you touched.

Use 'git add <file>' to add all the files for the bug fix. Then 'git commit -m "fixed JIRA 4329"'. Repeat for the code formatting. Finally, repeat for the feature request.

Oh man, I can hear you complaining already. That's sooooo much more typing than 'git commit -am "stuff"'!!!1

It's almost impossible for me to believe that the same architecture astronauts who spend hours writing more code to generalize things that really don't need to be generalized complain about this. But okay, even with tab-completion, I got pretty tired of typing that much. Luckily, there's a faster way: 'git add -i'.

The i is for interactive, and once you learn the keys (u for update, a for add, etc), you'll fly through your adds. Instead of explicitly giving git the file paths, you can just say 1,2,3 for the first three files, or 1-4,5,7-9 for those ranges of files. Glorious. Once you start using interactive, you'll realize that it also takes the place of 'git status', since you'll see the status as part of the interactive add. Pretty swanky, huh?

You can see how using the index is pretty powerful, and hopefully you no longer believe it's just another level of indirection between you and the repo. But we can do one better than adding files individually. We'll still use the index to stage changes, but instead of git add <file>, we'll use git add -p <file>. This brings up an interactive adder for chunks of the file that git has detected changes in. Super useful, especially considering the use case I've presented, where there's a good chance unrelated changes happened in the same file. You can also use the patch mode in the interactive add, or you can just do 'git add -p' to bring up the interactive chunk adder for all of the unstaged changes.

Just as with the interactive add, you'll start to notice that the interactive add can take place of git diff. Why bother paging through a git diff to jog your memory as to what changed, when you can do it as you go with -p?

With these simple tools, you can present your work as logical commits, which is great. But once you've committed, what happens when you realize you've forgotten something, or grouped a piece of one fix with another by mistake? That's where the next level of git is useful- the fact that you commit everything locally before you push.

In the same manner as before, when we stopped using 'git commit -a' to skip the add stage, we will stop using 'git push' immediately after committing. In this case, since we've broken up our commits exactly how we want to send them, the only real use for this is to allow room for error (and, of course, if you're offline- the huge advantage of DVCS). But in the next scenario, where we smush together smaller commits, you'll see that there is another use.

To simplify the explanation, let's pretend you just realized that your last commit for the bug fix was actually two bug fixes in one. It wouldn't be the worst thing in the world to commit them both, since bug fixes are unlikely to be rolled back, but just in case, lets split up the commit into two pieces. I should note at this point that you should never do this on a commit that has been published to the world already- only do it on your local commits. Otherwise, you're rewriting history, and it'll get real confusing. More on this later.

Use 'git reset --mixed HEAD~1' to reset your branch and index to the previous commit, but leave your working tree alone. Since your working tree contained the changes of the commit you just reset, this effectively means that your current git status will be identical to before you started constructing that final commit. This turns out to be really handy, because now you can add and commit the bug fixes separately, and go along your merry way as if you did it the right way the first time. Nice.

With the tools of add, patch, and reset, we're pretty much set to construct logical commits. But it would really be best if you got into the habit of committing early and often- after all, it's all local, so you should feel comfortable using git to enable your personal development without worrying if things are ready to be shown to everyone else. Thus, as promised, it's time to learn how to mash together lots of tiny, incremental commits into the logical commits we feel comfortable presenting to the team.

Learning to love git rebase

Rebasing seems like such a contentious when you're first learning git. I had a heck of a time trying to understand what people were arguing about. Basically, it boils down to two things. One, everyone can agree on: don't change public history. If you do the things I show you on commits that other people have seen, you will really mess them up when you push. Don't do it. Nobody argues about this.

What we do argue about is rebasing your own history. I'll just come out and say it: rebasing is lying. You get to manipulate your commits and make them look exactly like you want, and apply them on top of new commits that you didn't originally work off of. But, I argue, you are totally allowed to lie in this manner. It is no more of a lie than the lie of the monster commit developer, who presents the entire sum of his changes as if it was all done at once! And if you're going to lie, you might as well make it more convenient for other people, right?

I think this issue is confusing for people because of the mindset change necessary when using a DVCS. As I mentioned, you can and should use git locally to its fullest extent. You should only conform to public standards when you are, in fact, in public. In a VCS like SVN, you don't have a choice- committing is publishing. So people haven't really fully grasped the idea that you are in full control and can lie as much as you want, as long as you do it locally.

With that in mind, there are two ways you can lie and help others with rebasing. The first is a simple case of commit re-ordering, so we'll do that first. For simplicity, lets work on the master branch. Do a 'git pull' and get some changes pulled down. Since you have some commits that you haven't published, they are automatically merged by git, resulting in a merge commit.

'git rebase origin/master' does the following steps:

- Take all the changes in your current branch (master in local repo) and save them in a special place

- Reset your current branch to origin/master, which is the snapshot git took of the remote repository when you pulled (if this is news to you, you may like my git graphs)

- Apply the changes that were saved on top of your branch

That's why git will say something like "first, rewinding head to replay your work on top of it". The message sounds like it was carefully formed for maximum confusion, but that's actually exactly what it's doing.

After rebasing, you won't have a merge commit anymore, and your commits will appear on top of the commits you just pulled down. There are lots of good graphical representations of this floating around the internet, but as usual, Pro Git is a good place to start.

But why would you want to remove the merge commit? Well, this is where the argument gets interesting. You could argue against any merge commits whatsoever, but I'm just going to argue for the simplest case. When you commit stuff, then pull other people's changes in, git will create the merge commit we resolved just a moment ago- I'll call it a 'dumb merge'. Is this really a merge? Not in the traditional sense of the word. You certainly didn't have to do any manual merge work, and you weren't really merging branches (for example, a feature branch back into trunk). Since the 'dumb merge' is by far the most common case, if you look back at your repo history, you'll see lots and lots of dumb merges, and a few real merges hidden amongst them.

I think this is confusing and bad. It's so much harder to untangle the history when you're looking at all those dumb merges, and you'll start automatically disregarding them...which is bad, since you really want to pay attention to the real merges! Rebasing is a simple way to resolve this issue, and as long as you only do it to resolve dumb merges, you won't have any issues. To be honest, it's not any harder to resolve real merge conflicts, but it is a completely different set of terminology and methodology, so I don't usually encourage my colleagues to seek it out. There are so many ways to do everything in git, so you really have to pick your spots to avoid overwhelming people.

The other case for git rebasing is reorganizing and mashing up your commits before sharing them with others. The main benefit of having this power is that you can use your local git repository to its fullest extent. Every time you try something out, you can commit, revert, etc. You don't have to comment out tens of lines of code across multiple files anymore. By the time you share with your team, you'll have reworked the commits so they don't see 50 back-and-forth commits until you finally got the feature working. And of course, if you use git's branches, it's even easier to explore different approaches.

Once you have this power, you'll realize how completely useless other VCS are. If you don't feel comfortable using your VCS to manage all of your changes, you're not really using version control. If you only commit once at the end of every day, why don't you just go back to making backups of your files as your VCS?

The key tool for managing your mess of commits is the interactive mode of rebase. To perform surgery on the last 10 commits, simply run git rebase -i HEAD~10. Git will show you exactly what to do. The only thing you have to wrap your head around is the fact you can actually do all of this- reorder, reword, squash, and more! My personal favorite is squash- any commit that I squash will be included in the previous commit. That's how I get rid of all of those pesky intermediate commits that didn't turn out quite right.

The most common thing I used to do was create a new commit with some changes I forgot to put in (usually noticed when reviewing the diff), rebase and squash into the last commit. I had this workflow down pretty pat, thanks to vim. But it turns out that git can do this even simpler with the --amend flag: 'git commit -a --amend -C HEAD' will amend your previous commit with all of the newly edited files. It's an extension of the --amend feature, which I had only used for editing commit messages before. Nice.

Hopefully you learned some of the reasoning behind git's more advanced features, and how you can use them to increase the productivity of both you and your team. There's so much more to cover, but that's all for now.

Filed under git programming

Posted by Chris Murphy

6 Comments

23 Feb 2011

February 23rd, 8:40pm 0 comments

Pursuing Pizza Perfection

After eating the best pizza of my life at Piccos in Boston, I realized the next focus of my obsessive food perfection would have to be pizza.

Pizza (at least, Neapolitan style) is actually quite tricky to do at home. The best pizzas in this genre are cooked in a 1000 degree brick oven--conditions unlikely to be replicated at home. If you're a complete badass, you can snap off the oven lock and use the self cleaning feature to get around 900 degrees, which is awesome, but risky. The doughs are also difficult to master, and the yeast strain has a huge impact on the final flavor, so we have a lot to overcome here. The following is a description of my first official attempt at home cooked pizza heaven.

There are many important factors for delicious pizza dough. One thing I noticed at Piccos was how intensly flavored just the plain crust was. There's no garlic butter here, this is the dough itself that tastes amazing. The first key is to have a good yeast strain. I would love to get my hands on a fancy sourdough starter to use in pizza doughs, but for now, I just used the regular yeast I picked up at BJs for pennies on the dollar. And when I say I, I mean Erica, because I was busy making insane amounts of lasagna and soup for work and she's better at doughs anyway.

The next important thing is to cold-ferment the dough. I first heard of this from Alton Brown, but it is apparently common wisdom among the pizza making elite. With this method, after you make the dough, you let it rise in the fridge for 2-4 days. Right before use, you let it rise at room temperature, but not before then. The cold environment of the fridge means that the yeast are practically in hibernation. They are still going to work eating sugars and producing carbon dioxide, but at a much slower rate than room temp.

The idea is that this long, slow production improves the taste and bubble structure of the dough. Wait, bubble structure?

The lifetime of the bubbles in the dough shoud be something like this. Yeast burps carbon dioxide slowly, making small, sturdy bubbles. 2 hours before cooking, the dough comes out of the fridge and the yeast start to wake up, inflating more and more bubbles. When the dough hits intense heat, the water in the dough turns into steam, inflating the bubbles and producing that light, airy, bubbly crust we all love. You want to be careful with all of these steps. As this mad scientist hypothesizes, if you let the dough overrise, the bubbles will go past their elasticity point and start to lose structure, thus collapsing and being lame. He gives the analogy of blowing bubble gum, which I think is wonderful.

This brings up the final point of dough construction that I'll talk about today: moisture. You need to have a very wet dough, much wetter than normal for bread or pizza. You really want that steam to inflate the bubbles. Besides, we're ideally cooking at high heat, and we don't want our pizza to burn before we get that nice inflation.

You could write about dough forever (and Mr. Varasano really does), but the most interesting thing for me is actually the cooking. This is how I tried to imitate a brick oven.

Following the advice of many internet chefs, I turned to the power of cast iron. Thanks to my new Christmas gift from Erica, I have a satisfyingly hefty cast iron pan. Cast iron has incredible thermal mass and conducts heat extremely well. Great for searing a steak, so why can't we use it for searing a pizza dough? By preheating the cast iron on the range beforehand, we can get searingly hot temperatures. This is going to be like a extreme pizza stone!

Unfortunately, the cast iron can only cook from the bottom, and we really want the top just as hot--if not hotter, if possible. The next hottest thing I can think of in my kitchen is the oven broiler. We want to get the top of the pizza as close as possible to the broiler, so we'll actually flip the cast iron pan upside down. This also gives the benefit of not ruining the inside of the pan and not having to deal with the sides to limit the shape and constrict the retrieval. Win win.

The proverbial topping on this high heat cake is to pre-heat the oven to 550 with a pizza stone in it. The pizza stone will go under the cast iron pan and hopefully reflect/contain the heat a little. Ideally, I'd like a stone that is significantly bigger than the cast iron, which would almost create a mini-oven in the top 1/4 of the bigger oven and really reflect the broiler heat back and forth. As it was, I only had one barely bigger, but I figured it would still help--and it would definitely give some thermal mass to maintain the hot oven temp when I opened it to put in the pizza.

I had my theory; it was time to test.

We planned out the pizza toppings for our 6 mini (not so mini, but shhh) pizzas and got going. We shaped and topped one at a time, which hopefully kept the bubbles as unmolested as possible and prevented the toppings from soaking the dough. You should definitely try to get the pizza in the oven as fast as possible after topping.

Right away, we realized the difficulty of transfering a sticky, wet, thin pizza dough onto the cast iron. With Laurel and Becca employing multiple spatulas, we managed to flop most of the dough onto the cast iron. I heard a satisfying sizzle and threw the pan under the broiler.

Oh, dear. Well, you learn more from failure than success, right? In my excited state, I totally forgot to flour the cast iron--but that wasn't the problem. Actually, after it's cooked, the pizza comes off pretty easily. Rather, the lack of flouring took away what could've been a critical indicator that the pan was too hot. As I learned later, the pan should probably be no hotter than is required for the flour to just begin to smoke when applied. If I had floured the pan at that point, it would've instantly infernoed*. Oh well, lesson learned.

*I know this because it happened. I tested the pan, decided it needed more preheating, and put it back on the stove. A few minutes went by, and before I knew it, the pan was pouring smoke. The fire alarm may have gone off for a while, until we opened all the windows...oops!

(download)

Ah, that's a bit better! I was conservative with the pan heat this time, but at least it looked edible! But something's missing...

Forgot the basil! Much better if you put that on beforehand, but better late than never! Oh, and another lesson learned from this pizza--since I had already managed to get a bunch of crap on the bottom of the pan, it would've been a bad idea to put it back on the burner. So I flipped it over like a lid for the stove, which actually worked well. I don't think it heated up as fast, but it worked.

(download)

Oh yeah, that's nice! Got the environment a little hotter and the crust is lookin' better. Still not as much carmelization as I'd like, but we're getting there, for sure.

We had also decided to make one of the pizzas regular style, at the bottom of the 550 degree oven, for comparison. You can see how much flatter this crust is--even at 550 degrees! The pizza was still delicious, especially since the toppings were $22/lb prosciutto and cheese. Classy.

That's the masterpiece of the day. Ain't it purdy? By this last pizza, I sorta figured out how to activate the broiler during the few minutes of pizza cooking, which was critical. The problem with preheating the oven to 550 and whatnot is that the broiler, even on hi, turns off when the oven thermometer tells it to. Lame. I tried to vent the oven in between pizzas, sacrifcing some of the 550 degree heat. For the last couple of pizzas, I did get that red-hot broiler for most of the cooking process, which was great.

Next time, I'm going to be more careful with this. I don't think the 550 of the rest of the oven matters too much, since the cast iron is burning from the bottom and the broiler is burning from the top. I could also try to get some ice in there to fool the thermometer, if I can find it. At first, I thought that might ruin the crispy crust, but then Erica pointed out that bakers spritz the oven walls to create steam, which apparently crisps up bread. So who knows, that could be huge! We'll find out soon...I can't wait to try this again!

Filed under food

Posted by Chris Murphy from Boston, MA

0 Comments

26 Dec 2010

December 26th, 5:44pm 0 comments

Programming Quote

On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

— Charles Babbage

Filed under programming

Posted by Chris Murphy

0 Comments

7 Dec 2010

December 7th, 9:21pm 0 comments

My Bookmarks

I don't know why I lapsed from using Delicious. I think the Firefox bookmark tool broke down at some point, and that really interrupted my use case. And once the Awesome-Bar proved its name by keeping any piece of my history within reach, I didn't even use regular bookmarks. After switching to Chrome, which has a decidedly Less-Awesome-Bar, I realized I was missing bookmarking quite a bit.

So, I'm back to posting my bookmarks here: http://www.delicious.com/cmurphycode

Enjoy!

Posted by Chris Murphy

0 Comments

5 Dec 2010

December 5th, 1:30pm 0 comments

Groupon: But What About the Future?

Groupon, the fast growing coupon site, has reportedly turned down an acquisition offer by Google in the multi-billion dollar range. Despite using and enjoying Groupon, when I first heard the size of the offer, I was stunned, so I did some research on the company. Although we don't know the exact numbers, all reports indicate that Groupon is on track for 500 million dollars in revenue in 2010, with some estimates claiming that in just the last quarter. Certainly, Groupon is one of the fastest growing companies out there, and with an actual business plan, they're distancing themselves from any talk of a Web 2.0 bubble.

I don't want to get too caught up in the exact numbers; if you search around, you'll find plenty of speculative articles. I'd rather discuss the Groupon business model, and contemplate whether they will continue to see success.

Groupon is essentially a place for businesses (typically local) to sell vouchers (coupons) for huge discounts. The typical Groupon saves the consumer over 50% off the retail price, which is enough to get any smart shopper's ears perked up. Groupon makes money by splitting the sales of the coupons with the business. Again, I couldn't track down a reliable number for the split, but I've seen 50% quoted quite a bit.

There are several obvious conclusions from just this short introduction to Groupon. The first is that consumers are going to love it. 50% off is almost too good to pass up. When you see a discount that big, you almost can't resist. There does seem to be something magical about deep discounts, such that some people buy products they would never have otherwise considered. This is somewhat similar to the BJ's Wholesale Club and Costco school of thought, where they entice you by having the best prices on the item you're looking for, which makes you notice all the other items that are such deals, and before you know it, you've bought 5 more things than you ever wanted to.

This model is good for businesses, but only up to a point. Nearly any profitable sale that wouldn't have happened otherwise is a win for the business.* After all, 1% profit on $100 revenue is better than 10% profit on no revenue! But you do have to wonder, are any of the Groupon deals profitable? At a 50% (or more) discount, split in half with Groupon, the business is seeing less than 25% of the original price of the item. There are very few businesses that have margins that comfortable.

*There are much more complicated and much more correct ways of phrasing this in economic terms. If you're interested, pick up an Econ 101 textbook :)

Of course, there are ways that even a non profitable sale can help a business in the long run. Stores like Staples and OfficeMax have made a practice of promoting "loss leaders", which actually cost the company money to sell, but get the customer in the store to buy more. Furthermore, simply making one sale is establishing a relationship with the customer, which can lead to more sales in the future. This is especially important for new and local businesses, who have a hard time making an impact in the expensive advertising market.

I'm sure these are the types of things Groupon tells businesses when it tries to get them to post Groupons, and for some of them, I'm sure it works. But for others, the overwhelming numbers and devaluation of the product that a Groupon inspires may hurt. There's really no way to know which factor is bigger until we get more data on whether businesses return to Groupon or not. Such data can only come with time, so that's not any help for predicting the future!

I should also address the social aspect of Groupon. During the rumors of Google's acquisition offer, people said that Groupon would provide the social media piece that Google seems incompetent to provide on their own. I completely disagree. Groupon is not a social media site. It has one viral product, but people don't go to Groupon for any purpose other than seeing the deal of the day and possibly buying it. They don't communicate with friends, like on Facebook. However, as we know from the predictive powers of credit card companies, the purchase data that Groupon holds could be very valuable to Google. Google has a vested interest in figuring out what you want, and Groupon could have helped them with that. But to call Groupon the social piece that Google was missing is very misguided.

Now that I've described some of the downsides of Groupon, let me describe some of the things they've done well.

First, they are clearly the complete package: they have the marketing people to gain business partners, the design and copy folk to catch the eye of customers, and the engineers to tie it all together. They had a large investment that allowed them to advertise a lot and spread the word. Yet since they were profitable quickly and the investment wasn't too large, it didn't force the founders into a boom-or-bust mentality, where anything but a multi-billion dollar success (which happened anyway!) would be a failure.

Second, like Twitter and Facebook before them, they have completely infiltrated the mainstream. One of my favorite categories of customer is the stay-at-home-parent. They usually handle the finances, they network like crazy, and they are quick to use and proclaim the benefits of any product that improves their lives. The fundamental idea of coupons is nothing new, so I'm not surprised that Groupon won them over so quickly. With such amazing deals (often delivered to your Inbox daily), you almost feel obligated to tell your friends about it- it's quite viral.

With their large and fast growing user base, profitable product, and nothing but good press, I have to imagine that Groupon will continue to grow for the time being. And if Groupon doesn't produce enough value for businesses now, I'm sure they will figure out a way to provide more value in the future. Now that they have the loyalty of the customer base, they can easily expand their offerings if they choose. Thus, despite my doubts about the sustainability of the current model, I believe Groupon will be a profitable company for years to come.

Filed under bubble web

Posted by Chris Murphy

0 Comments

16 Nov 2010

November 16th, 9:42pm 0 comments

The Three Ways Facebook Messages Will Print Money

Facebook has launched their new communication platform, called Messages. Hyped around the Internet as an email killer, Messages is an interesting product that will improve Facebook's business model.

Facebook is valuable (i.e. makes money or has potential for making money) by collecting information about people and selling it to advertisers. Messages will improve the value of Facebook by increasing the value they can offer to advertisers.

The first way Messages helps Facebook is obvious: having more communication under Facebook's control means having more information to sell to advertisers. This is no surprise, and traditional services such as Gmail make their money the same way.

The second way is more subtle. As I said, Facebook's information is already valuable, but its information is incomplete. Conversations that span IM, SMS, email, and Facebook imply that Facebook is not truly understanding what its users are doing. Now that Facebook can listen to the entire conversation, it is not only gathering more information than before, but it can use it more effectively than before.

In fact, the only two methods of communication that are now outside the grasp of Facebook are phone calls and face to face interactions. I wouldn't be surprised if Facebook is working on some sort of mobile phone project to handle the former. There have been rumors of a Facebook phone for a while, and I didn't quite understand why that would be valuable until now. If the Facebook phone employs a Google Voice-esque transcription of your conversations, they can extract information, and thus value, from your phone calls. Of course, the target audience for Facebook (an even younger generation than mine) doesn't really make phone calls anymore, so I'm not sure how much value they could expect to see. Still, the prospect of a Facebook phone seems like an instant win; millions of teenagers would be clamoring for a "properly" social phone (i.e., heavily integrated with Facebook), and if that happens, phone calls should be part of the ecosystem, too.

The final way that Messages is going to increase the value of Facebook is actually the whole reason I wanted to write this post. Dunbar's Number is the idea that the average person can only hold a certain amount of social relationships at one time. While it is probably impossible to pin down an exact number, it's still a useful concept to think about. I think Messages can actually increase Dunbar's Number. Rather, Facebook and the Internet in general have been increasing Dunbar's Number, and Messages is just an extension of that.

Certainly, someone today can handle more relationships than someone 200 years ago. As technology has progressed, so have our means of keeping track of people. The Internet offered an enormous geographical widening of social circles, so that anyone can maintain relationships with anyone, regardless of distance. Facebook has been working hard to keep track of people's relationships. This has been made explicit in the latest "Friendship" page that replaced the wall-to-wall feature. Imagine my relationship with my college roommates. Facebook knows which events we've been to together, what photos and videos we are in together, what we've said to each other, and what interests we both have. For me, this resource means I can easily keep track of people that I probably would've forgotten about otherwise. For Facebook, it means more information collected. In short, if Messages can make managing relationships easier, it will increase the number of relationships people hold, which will increase Facebook's value.

Thus, while I refuse to tab Messages an email killer (on principle), I do think it is worth a close watch. We may see some interesting trends arise from its use, and Facebook will certainly increase in value. If Facebook keeps this up, they will completely dominate the technological lives of the next generation.

Filed under web

Posted by Chris Murphy

0 Comments

13 Nov 2010

November 13th, 10:44pm 0 comments

The New Value

We are in a new age, and you're probably ignoring it. Whether you like it or not, the new social is here. I'd like to discuss some of the arguments against social media, and explain a few of the benefits that you might not realize.

From the invention of agriculture until recently, the human race has had to work long, difficult hours to survive. With the progression of technology and education, we've traded working harder for working smarter, so we've seen an increase in leisure time.

(Source)

What have we done with this time? That question interests me, and while I can't speak for all of history, I'd like to touch on the last two generations, since they're the target of this post.

When the television was invented and popularized, a huge piece of our free time was devoted to passive consumption. While I'll be the last person to argue against watching TV, I challenge anyone to make an argument about the benefits of the passive consumption of I Love Lucy, Seinfield, or The Jersey Shore*.

The thing about passive consumption is that the entire impact is felt by you, and delivered by a small group (in this case, the TV company). Your consumption of the product has no effect on anyone else. I should note that the idea of passive consumption was in no way started by television; before Saturday morning cartoons, there were Saturday morning comic books.

*I picked these three series because they are good examples of popular television from different eras. That none of them add value to our society does not mean that there is no valuable TV. More on this later.

My generation still watches TV, but we're going through a serious transition. Media consumption is rising, but we don't care how we get it. In fact, we'd prefer to get it online, so we don't have to pay a cable company for the privilege of not being able to choose when we watch a show. Furthermore, we want to find out what interests us and watch it immediately, which requires effective recommendations. Whether those recommendations come from your social network or from a recommendation engine, the only place to get them right now is on the Internet. The BBC seems to get it, and other broadcasting companies won't be far behind. Everyone wants to tap into the power of viral video, and if you already have a TV show that a million people watch, it'll be trivially easy to get them talking about it online, if you provide the means.

By providing media through the computer, broadcasters can turn the passive consumers of yesterday into the producers of today. Let the college kid watching Community hit the Like button, write a note and send it to his Facebook friends, or simply send the link to that one hilarious scene.

And this is just one minor part of the new value. YouTube showed us that anyone can take the place of traditional media broadcasters, and Twitter is showing us that anyone can supplant the traditional news media. I was reading the Financial Times this morning, and saw yet another example of the power of Twitter. Nancy Pelosi announced she would run for Senate minority leader on her Twitter, which "ended days of speculation", according to the article. Combined with the huge celebrity/athlete population on Twitter, it seems clear that the simplicity, immediacy, and direct, unfiltered nature of this new medium has changed the way we communicate. When Twitter first launched, I doubted the value of a service that limited to 140 characters (necessary to support text messaging). Now, I can see that the very thing I thought was a weakness was a strength. Shaq, Pelosi, or Kanye don't have to prepare a carefully worded statement, they just say a quick note on what they feel. If they want to respond to fans or supporters, they can do so with 10 seconds of effort. It doesn't seem brusque because, hey, it's Twitter!

So there may be some value in services like Twitter for famous people. But what about the rest of us? Why should you care what I had for breakfast?

That is the number one argument I hear against Twitter: "why is it necessary for everyone to know the details of your life?". While I feel the argument is misguided, I understand why it's so common. Twitter embodies a shift in focus from the individual to the group, and that shift is not easy to get the first time around.

As a user of Twitter, it seems like a really convenient way to tell the world about the minutiae of your life, like how long your morning commute is. That's fine, and admittedly, that's a huge reason why it's so popular: a lot people like to make their feelings and opinions heard. Some would argue that that is enough to prove Twitter's value, but I'll go further. The vanishingly small value of your tweet about Obama's State of the Union is merely one piece of the Twitterverse, and the sum of all the pieces together is something with real value.

Twitter is becoming increasingly important as a source of news. The power of millions of people who can update within seconds of an event happening is something even the most visionary of the traditional media could have never calculated. Indeed, the traditional media is still trying to figure out how to use Twitter, but we've certainly seen its power already. Whether it's simply used as a source (seems like at least half of athlete comments), is summarized in a new visual display, or actually used as the delivery mechanism, like during Hurricane Earl*, Twitter displays the value of its simplicity, flexibility, and huge pool of possible consumers and producers.

*I was amazed when the most up-to-date information I could find on Weather.com or Wunderground.com was actually just a stream of tweets from their reporters, captured on the site. Using nothing but free tools, the weather sites were able to add a real-time updating feature to their website. Amazing.

So Twitter has clearly demonstrated that having millions of producers of information can be very valuable, compared to the traditional media. But in considering the millions of possible sources, we have to address the other argument about social media and Twitter: isn't the value of the service overwhelmed by the nearly infinite additional amount of noise created?

There's no doubt that sites like Twitter, Facebook, and YouTube have created massive amounts of noise. In fact, these sites are merely a continuation of the Internet at large: from the early days of bulletin boards through websites and blogs, letting anyone have a voice results in lots of proof of age-old wisdoms. I've talked about this trade-off before, and while it's a worthy consideration, I think it's worth it.

But even if you're convinced that there is some value to this new way of production, you may still have a problem with social media and the Internet in general. After all, a huge portion of time is still being spent on passive consumption, such as browsing Facebook photos, reading wall posts, and keeping track of relationships. Compared to TV, it seems pretty harmless, but then again, people have been arguing against TV for decades. I think I can raise a better defense*.

*I've thought a lot about the difference between reading the Internet and reading books and other traditional media, and whether they can be considered academically equivalent. For now, I want to focus exclusively on the social aspects of the Internet, but I hope to devote adequate time to learning activities another time.

The first piece of the argument, and thus of my defense, deals with electronic social interactions. It's clear that the new school of social has taken a chunk out of the old: we'd much rather text than talk on the phone, we'd rather Facebook than email (and forget about writing a letter!), and, in some cases, we'd rather stay home than go out. This is a source of much consternation for some, but why? I think it's fear of the change, and of the unknown.

When we entered into the age of the telephone, people worried about the impact it would have on face-to-face interaction. When my mother called her friends for 3 hours every night, her mother yelled at her, just as she yelled at me to stop texting at the dinner table. There is so much symmetry in history, but everyone seems to forget it.

The telephone was just the beginning of the shift away from face-to-face conversations, which we'd had throughout our evolutionary history, and the rate of change of that shift is accelerating. With all the new ways to avoid talking to someone in person, I can see why people worry. But the fact is, social media is not replacing real life interactions, it is merely supplementing them. There's no doubt that Facebook and Twitter have changed the way people communicate, but we shouldn't automatically assume this change is bad.

(Source)

Just like the telephone changed communication, so does Facebook. And just as people continued to socialize in person after the telephone appeared in every home, they are continuing and will continue to socialize in person after everyone has a Facebook account. Some of the interactions that used to happen in person or through the telephone are slowly changing to the electronic medium. For example, to plan a party, I post on Facebook and Twitter, rather than calling everyone. The next day, I can share the photos with my friends online, rather than waiting to see them in person again. Some people have a real problem with this, because they believe there is intrinsic value in these face-to-face interactions. For me, as long as we're still physically going to the parties, the administrivia can happen online.

In fact, if you think about the example I've given, clear examples of the benefits of digitizing certain social interactions arise. If I choose, my party invitation can reach many more than I could tell in person, or even over the phone. When my friend goes back to law school after the party, he can still see the photos from 200 miles away. Of course, this is nothing compared to sending a video update to my former roommate, now teaching in Korea. The Internet enables a fantastically broader type of interaction, and that can only be a good thing.

I spent my formative years as a computer geek chatting with people from England, Spain, and Canada. Such experiences were literally impossible just 150 years ago, and were hardly normal even after the telephone. My interactions with these people surely shaped my understanding of the world; what better way to enhance my history class at school? Beyond learning about these foreign cultures, I got a firsthand lesson in the power of social media as a news source.

I woke up for school one morning, and checked the chat before eating breakfast. I saw my friend describing the shattered windows across from his apartment, a consequence of the terrorist bombings in Madrid. It was 6AM (hours after the attack), and I didn't really process what had happened until I saw it on the news later that day.

Thus, I argue that social media truly does enhance social interactions. Of those interactions it replaces, I feel no loss. If there's an intrinsic value to discussing party plans face-to-face with everyone, every time, I'm not seeing it. What I am seeing is the efficiency of the new medium: replacing an unnecessarily long, potentially interrupting phone call (half the time leading to a voicemail, requiring checking, listening, and calling back) with a 50 character text message has been great.

Even the least interesting updates to Twitter are no different than the idle chat we used to engage in on our porches, around our fireplaces, and at the watercooler. For some reason, people get visibly upset about seeing these daily minutiae posted on the Internet. I suspect the visibility of the medium misleads them: they feel the producers are forcing their personal details on everybody, simply because anyone can see the updates. On the other hand, I am pleased to see people using Twitter to vent their feelings. If I want to avoid seeing the noise, I just unsubscribe from their tweets. Much easier than pretending to care in person! Plus, as I discussed above, there is some potential value in the aggregation of the otherwise useless updates.

Even if I can't convince you that, in some cases, we're better off interacting with social media, I hope you don't decry the changes we're seeing without good reason. I believe there is real value, and I hope we have a chance to prove it to you. Our world will always change, and how we interact will change with it; if you hide from the changes, you'll miss out on some really interesting things.

Perhaps there is some value to the social interactions offered by sites like Facebook and Twitter, then. What about the truly passive consumption of, say, Farmville? One of the most cited examples of the time our youth is wasting, Farmville is certainly not providing benefits to anyone. My thoughts have come full circle, back to the passive consumption of television. While these types of activities don't have any recognizable, direct value to the world, I am convinced they are necessary*. Throughout the history of our race, our leisure activities have changed, but their existence has remained constant. This alone indicates that it is nearly impossible to live a life filled entirely with productive activities. I doubt that anyone would argue this point, so I suggest that the real argument against television and the Internet as a leisure activity boils down to proving those activities somehow increase the need or desire for more leisure, at the cost of formerly-feasible productivity. I don't think that's an easy argument to make. In short, social media is a way to spend our free time. It is new, it is different, but it is not inherently worse.

This argument deserves an essay of its own, and I hope to write it in the future.

In fact, that's a good summary of my entire point. Social media is new, and it is different. It is changing how we interact with each other, and I find a lot of value in it. I've tried to explain some of the value we can extract from sites like Twitter, but I realize that until we have some time to understand them, it may be a tough argument. So I also tried to defend some of the less valuable pieces of social media. In doing so, I drew ties to other historical shifts in our history. That way, even if you don't see any use for social media right now, you won't dismiss it out of hand and miss out on all it has to offer.

As always, I would love to hear your thoughts on this.

Filed under social media web

Posted by Chris Murphy

0 Comments

Adventurous

Search

Tags

Contributors

Adventures with Sous Vide

Git 201: Slightly More Advanced

Git 001

Git 102

Pursuing Pizza Perfection

Programming Quote

My Bookmarks

Groupon: But What About the Future?

The Three Ways Facebook Messages Will Print Money

The New Value

Search

Tags

Subscribe

Contributors