@FredKSchott's Blog

Yesterday, Facebook announced the accidental release of 6 million users' personal information. The source of the leak was their Backup Tool, which lets users download their list of friends complete with any information they'd chosen to share. So what happened? A bug in the tool released the phone numbers and email addresses of friends that they not only hadn't chosen to share, but that they hadn't even given to Facebook.

Because of the nature of the leak and recent NSA activity, both Facebook's apology and the Internet's reaction have focused on the data leak itself. It's a valid concern, but 6 million is a drop in the bucket for Facebook, and any data that did get leaked was only released to a Facebook friend or two. For a company with the mantra "Move fast and break things" it's hardly unexpected.

So, "No harm, no foul," right? Not quite. Things start to get murky when you ignore the leak and focus on how this was even possible. For one, the phone numbers and email addresses that Facebook leaked weren't submitted by the users themselves. This means Facebook has your phone number, even if you've never given it out. How? By analyzing and storing your number when your friends give Facebook their address books and contact lists.[1] The same goes for your email address, which Facebook most likely grabbed from a friend's email contacts.

While it's common knowledge that Facebook loves collecting our information, it's always been information that we've willingly provided. Our favorite movies, photos, and hangout spots are all included on our profiles for our friends to see and Facebook to leverage towards better ads. This bug has exposed that this isn't entirely the case: Facebook knows more about you than you want them to.

Discuss on Hacker News

Today we’re announcing CoVim, a plugin that adds multi-user, real-time collaboration to your favorite (or least favorite) text editor. CoVim allows you to remotely code, write, edit, and collaborate, all within your custom Vim configuration. Originally started as a senior capstone project for Tufts University, we’re now open-sourcing it to give the world one of Vim’s most requested features. Think Google Docs for Vim.

Work on CoVim started almost a year ago. I wanted to explore this concept of a shared classroom note-taking platform (someone should still do that, by the way) while my project partner Sam Haney wanted to explore something a bit more well-known and dependable. We decided to meet each other halfway, and CoVim was born.

How it Works

Vim has built-in Python scripting, so Python was an obvious choice for our project. For networking, we used Twisted, a powerful event-driven networking engine that comes included in most versions of Python. Whenever the user makes a change to the document or moves their cursor, the client sends an update to the server. The server then updates any cursor locations before sending the update to the other clients.

With CoVim, there’s no representation of a file. All updates live within the Vim buffer, which is simply a working copy of the document’s text. This isn’t so much a bug or feature, but more a symptom of how Vim represents documents-in-progress. While it’s the responsibility of the user to remember to save their work, it also allows users the freedom to save whatever and whenever they want.

So What?

CoVim is obviously awesome, but that alone doesn't justify a year of hard work. So, what can we actually do with it?

The problem we initially set out to solve is one that plagued us as students: the annoyance of pair programming on one computer. Pair programming is a great coding technique that turns frustrating work into a team effort, but the physical limitations are a pain. There’s just one screen and one keyboard, so space is cramped and switching writers interrupts the creative flow. With CoVim, you can have your own screen and keyboard, so space is never cramped and time is never wasted switching writers.

But students aren’t the only ones who can benefit. Teaching Assistants can use CoVim to help multiple students during office hours, and a professor can walk through a students code with them one-on-one without ever leaving the office. Going one step further, TA’s could run office hours completely remotely, whenever they had a free second. (Is this a great idea? Probably not, but it is a good example of just how much CoVim can help in academia.)

Businesses will also benefit from CoVim. Got a question for someone across the office? Instead of trying to explain the problem in abstract, just open Vim and let them see the code in question. Does your company practice code reviews? Walk through the code together so that feedback can be given line-by-line. Making it so easy to share code will increase collaboration in any business, which means better code quality and greater results.

Grab the Code

CoVim is on GitHub, so go check it out, grab the code, and start sharing. Tons of work went into this project, and it wouldn’t have been possible without Ming Chow (an amazing Tufts professor who completely revamped the Senior Capstone Program) and my project partner Sam Haney. There are tons more features on the way (including chat, annotations, & admin tools), so keep on the lookout.

Happy collaborating!

I don’t really know if this means anything, but it’s an interesting observation nonetheless:

I’m sitting here in my Networking lecture and decided to look around the class. Peeking at other laptops is always fun because the people using them are almost never paying attention to the professor. So if this were a normal class, most people’s open laptops would be on Facebook, BuzzFeed, Reddit or any other entertaining yet mindless site. But In this class I can see 6 different laptop screens, and 5 of them are filled with code being written. One student is working on some website’s front-end, one is hacking away on at the terminal, and another is checking out what looks like the Twitter API documentation. Instead of daydreaming or goofing off, these guys are working on side projects, building cool stuff and growing their skill-sets.

I liked a lot of things about Zack Shapiro’s post Want to learn to code? Start here. I actually remember reading his original post dedicated to Ruby on Rails last year, and thought it was a great starting point for the framework.

Zack’s obviously a smart dude, but there’s a certain hostility in his newest post and others like it towards those who “don’t want it enough” and I cringe every time I see it. Coding isn’t a secret club that requires a pledge of undying loyalty to join; it can be enjoyed on all parts of the spectrum. So advice like, “Nights, Weekends are bad” is incredibly damaging to the cause. If someone works days, then what? They just shouldn’t bother? Quit their job? Worst-case scenario they never try, and best-case they think they’re screwed from the get-go and have an easy excuse to quit. “Well, I could only code at night… so obviously it didn’t work out.” A more helpful way to phrase it would be, “The more you can give yourself to learning the better” which is both true and doesn’t alienate the rather large group of “people who do things during the day."

Put another way, this bitterness is like getting mad at a user for abandoning your app/site/product. Sure, maybe it never was for them and they were never planning on making it a part of their daily life. But maybe they would have stayed if you (the community) had done something differently. Regardless you should be excited that they were interested enough to try it out, and curious about what you can learn from their departure that could make your next version more “sticky.”

So. I want to offer an alternative. Instead, this post IS intended for the person who thinks they should code because they hear so much about it. It’s intended for nerds, jocks, English majors, CEOs, the mailroom guy, and anyone else who wants to know more about coding. Here’s all you need to remember to get started:

Start small As small as possible, then build your skills off of each other

Have fun Build something you want to build, it will feel personal and keep you engaged in learning

Start Small

“Fundamentals, fundamentals, fundamentals. You’ve got to get the fundamentals down because otherwise the fancy stuff isn’t going to work.” ― Randy Pausch

Every coach I’ve ever had preached the importance of fundamentals daily, and it’s something I still believe in. Sure, the strongest of you might be able to learn everything about Ruby on Rails all at once (Ruby, Rails, the terminal, HTML, CSS, Javascript, the distinctions between client-side and server-side, routing, file permissions) but only after weeks of frustration, searching online and not even understanding the solution, let alone the problem. All roads lead to Rome, but some take a lot longer than others and are covered in shit and its way easier to just not even bother.

Instead, start small and grow. If you want the first steps, I’d say learn (and get really familiar with) HTML, then CSS, and then Javascript + jQuery. [1]

Hear that? That was the sound of a hundred programmers vomiting in rage. “HTML? CSS? That’s not even real programming! Where’s the MVC? Where’s CoffeeScript? How will they learn to setup a dev environment?” Ignore them; they’ve forgotten how hard it is to start out with next to no knowledge, when everything feels unfamiliar and frustrating. For you, it’ll feel just like programming and even better, it’ll get you familiar with how a computer reads and interprets what you’ve written. Get familiar with the fundamentals, and the fancy stuff will come easily when you’re ready for it.

Have Fun

“If you have no interest in politics, will you enjoy a language course that uses political articles? Of course not. You’ll get bored and quit.” ― Tim Ferriss

I’m horrible at being bored. I can’t stay focused on anything for long unless I’m finding some sort of interest or entertainment in it. Last summer my cousin took me to a driving range to teach me how to swing a golf club. 10 minutes later I was falling asleep, but instead of quitting I just started messing around. I was hitting one ball into another, two balls at once, and lining 10 up for rapid-fire golf. It was a stupid distraction but it kept me interested and my stroke improved regardless.

Whether you like golf or not, apply this to your learning. The web is such a great place to start because It’s the most fun. Your rewards are immediate, visual, and can be shared with friends. I agree when Zack writes, “Stop telling [nontechnical] people you’re learning to code” but disagree that learning to code should be a solitary act. Instead of telling everyone you’re learning, tell everyone about what you’ve made. Send links out to your friends. Show people at work. Bring it up on dates (On second thought maybe don’t). The point is, be proud and excited about what you’ve made and how much better you’ve gotten.

Tutorials are a great place to start, but creating a bunch of useless little things can quickly get old. Once you feel comfortable start something that you could excited being creative about, like a personal webpage or a simple idea for a site you’ve always had. Then if you want to add or learn something new, find a tutorial and try to follow it while applying it to your own, personal project. This will force you to actually understand and apply the concepts in the abstract instead of just understanding how they fit into any one specific example.

That’s it!

If you ever feel too frustrated, take a step back and ask yourself if you’ve bitten off more than you can chew, and if so find where you can compromise content for familiarity. When I was just starting out with NodeJS I had never seen the tempting engine Jade before (I’m more of a Django guy). It didn’t seem too hard to learn, but it felt unfamiliar and small problems kept getting in the way of the main goal: learning Node. So I switched out Jade for Swig (Django templating clone), and got back into it. Suddenly the whole thing felt way more familiar,I was enjoying myself, and most importantly I was able to leverage that familiarity towards learning Node faster. Then when I felt more comfortable with it all, I switched back in Jade.

In the end you need to do what works for you. I only post this to provide an alternative to the everything-at-once approach that seems so ingrained in the “Learning to Code” culture.

Discuss on HackerNews Follow me on Twitter

-—

In order to get my degree I need to take a bunch of silly classes. One of these is called "Human-Computer Interaction" and it's all about good design and the user experience and optional attendance. Unfortunately the professor created this class in the 90's, and as far as I can tell he hasn't meaningfully changed it since. To get some context of where design was in the 90's, check out the Space Jam website.

Here's my favorite part so far:

Write the user documentation -- a brief (one page or screenful max) new user's guide to getting started, which will inform the user how to use the device.

I read this article called Those Five Days Matter More Than Anything, Except The Other Days a while ago. It’s a few years old now (it sports a solid McCain reference) but for some reason I can’t get it out of my head. The focus is on the pieces that make up your identity and how a few key moments can completely define your life for the better or worse. It’s an interesting read for that alone, but here’s what keeps me up at night:

Who you are is a product of your experience, and also a product of the experiences you did not have.  You didn't talk to that girl, now that's part of you-- you are the guy who was too scared/angry/self-absorbed/whatever to talk to her, and that is an entirely different guy then the guy who does talk to her and it works; and an entirely different guy from the one who gets maced.  That was one of the most important days of your life, and you didn't even know it. 

Knowing the right or wrong choice is impossible in the moment, since you never truly know which was which until long after a decision’s been made. The perfect spouse could wake up one night and murder you in your sleep, there’s just no knowing for certain. But there’s another implication, one that is actually useful for us in the present. Your decisions don’t just create your future life; they also create the future you. 

To borrow the author’s example: You see a pretty girl reading across from you on the train. What do you do? It’s impossible to know what will happen, but one thing is for certain no matter what you do: this moment will become a part of you. You think that because you haven’t approached her yet you haven’t put anything on the table but you’re wrong, your entire identity was on the line the second you imagined the conversation. So. Are you the kind of guy who approaches girls freely, or cautiously? Are you outgoing or shy? You can only be one, and these are the moments when you choose.

The distinction is easy to miss, so I’ll say it explicitly: Choosing inaction over action isn’t just a missed step towards becoming the type of person you want to be, it’s a step backwards. Acting like a wimp - no matter what your rational or reasons are – is both a lost opportunity to be awesome and sign that you should get a cat. 

I have a friend choosing between two jobs after school. One offer is to be an analyst for a finance machine here in Boston for the next 2+ years, one of the most common steps toward business school. The other involves moving to London to lead in the creation of a new office for twice the pay and 10x the responsibility/freedom, but it would be an unusual job that HBS might not understand. I have no idea which job would be the right move for his career (the only business term I know is “synergy”) but I do know that Boston is the safe bet, and London is the risk. So by choosing between them he’s also choosing what type of person he is: “Safe and boring” or “risky and exciting”. This is doubly true because it’s his first big career choice, one that will set the base for every future career decision. Even if he chooses neither and goes AWOL on a Greenpeace mission to Africa, he’s still made a choice: “Scared of hard choices”. There’s really no way out of it.