Github recently discovered a distributed brute force password cracking effort. Short version, scammers used a network of 40,000 IP addresses and slow, methodical retries to get around lockout restrictions.

Good news: Github emailed users who were compromised, including some that they could not confirm but suspected were compromised. If you didn’t receive that email, you’re probably ok.

Bad news: They probably tried logging into your account anyway. Check your Github Security page for failed logins (look for user.failed_login). I found one from Indonesia from 3 days ago. A GeoIP lookup tool will give you a botnet world tour.

This is as good a time to repeat password hygiene advice:

• Do not reuse passwords across different sites
• Use strong passwords (12-16+ characters, include symbols and alphanumerics)
• Use a password manager so you don’t have to remember or write down strong passwords. PwSafe is cross-platform, 1Password works well for the Apple ecosystem. There are others, but make sure to use one!
• Use 2 factor authentication for important accounts. I have it for Google, Dropbox, Github. The Google Authenticator app (iOS+Android) and Authy both work well.

Hacker News has a good discussion that covers more angles on this attack and security in general. Here’s an article about why you should not reuse passwords.

Stay safe!

tl;dr: $ find . -type f -ls | sort -r -k 7 | head -20

I’m a programmer who grew up on Windows, so while I’m competent at Unix commands, there’s a lot I don’t know. That “young and clueless with lots of time” period is a great time to pick up skills; the “busy working father” period means I have to be much more selective now.

Backstory: I have been a Dropbox user since they were in beta in 2006, and every once in a while I bump up against my free space limit and have to weed out files. This gets harder every time since everything left is something I’d previously decided to keep. COMPUTERS TO THE RESUCE!

I went to the first place I always look for these problems: Stack Overflow. There was an answer, of course, but it didn’t work for me. I tried to get it to work, but didn’t feel like looking past the man page for why the printf option wasn’t valid on my machine.

So the next place I looked was the rest of the Google search results. Eventually I came up with this:

$ find . -type f -ls | sort -r -k 7 | head -20

List all the files, sort in reverse order based on the 7th field, and take the top 20. Thanks nerds of the world for answering my question!

[EDIT: Full attribution for the JD Intellectual Property rights]

My coworker Andres, whenever he spots “clever” code during code reviews, asks “What will Joe Developer think of this?”

(Feel free to use Jane Developer if it’s more appropriate.)

Joe Developer is our fictional persona of a capable but not outstanding developer. He knows the popular parts of commonly used APIs, the mainstream parts of the language, but doesn’t know or use quirky constructs or features. He’s probably better at writing code than reading it, and he doesn’t have any particular knowledge of the domain.

You might think we look down on Joe Developer, like he’s not one of us, that he’s not smart. That’s not the case at all – Joe Developer is us.

We have a team of about 10 people and a 3 year old codebase. People have joined and left the team during that time. Even the most senior or most productive people on our team haven’t written more than 20% of the code, and haven’t even seen more than half of it. Some code is new and evolving quickly. Most business reasons behind the code are only documented in our issue tracker and the brains of the people that worked on it.

This means that most of us, most of the time, have to actually read code to understand what it’s doing and how to modify it. Reading new code without the benefit of knowing the domain is hard enough. You have to read, understand, and simulate the execution of the code in order to reason about it. And that’s hard! Brian Kernighan (creator of C and Unix) said:

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

When you’re reading code, you are Joe Developer. Joe reminds us of the difficulty of reading vs writing code, of the power imbalance between the writer and the maintenance programmer a year later. It’s a clever shorthand reminding us to be clear, concise, and as simple as possible in our code. Putting 5% extra attention and rework to accommodate Joe Developer makes reading and revisiting code so much easier. We don’t fix everything, but we remove the most burdensome, most confusing time-sinks, producing an outsized benefit.

We look out for Joe Developer because we are all Joe Developer.

(Andres already wrote about Joe Developer on our company blog)

tl;dr: Discover Meteor is a great book for learning to program in Meteor.  Highly recommended.

New programming languages, tools, and paradigms come out all the time, old nuggets get rediscovered or reinvented, and old mistakes get remade. It’s dizzying and hard not to get cynical about it (ack, writing that sentence turned 13 of my facial hairs gray!), but every once in a while, persistence is rewarded. I just got very lucky and was rewarded twice.

Backstory

I heard about Meteor over a year ago when it was announced on Hacker News. It sounded cool but too immature at the time.

Then a few months ago I heard that Sacha Greif was writing a book on Meteor. [Side Note #1: how did I hear about it? I signed up for Sacha’s email list after buying his last product. Email marketing works!] A book signals tech maturity because a) there’s enough meat to fill a book with content, and b) someone is betting a bunch of time that it will become more popular.

A new project came up where Meteor would be a great fit so I bought the Full Edition of Discover Meteor.

[Read more…]