Trying out Omakase Charity, which is like a mutual fund for charitable giving. Interesting idea. They're trying to be data-driven:
You'll receive a quarterly report detailing exactly which projects your money has supported. 90% of all donations go directly to our partner charities; 10% stays with us to cover administration expenses and credit card processing fees. We are a 501(c)(3), so your donation is tax deductible.
For example, the preceding link has a tracking number so I can see the network effects of me getting the word out.
Simplest explanation of the math behind Public Key Cryptography
I was trying to explain public key cryptography today and totally failed at it. Here are notes to myself based on various Wikipedia pages. There's a lot more to it than this (like padding) but this is the gist of it.
e^-1 = d (mod φ(n))
23^-1 = d (mod φ(91))
23^-1 = d (mod 72)
23 * d = 1 (mod 72)
23 * 47 = 1 (mod 72)
d = 47
Now you have all the magic numbers you need:
public key = (n = 91, e = 23)
private key = (n = 91, d = 47)
Secret messages to you
1. Have someone else encrypt a message m using your public key (n, e):
m = 60
c(m) = m^e mod n
c(60) = 60^23 mod 91
c(60) = 44
c = 44 (they send this to you)
2. Decrypt the message c using your private key (n, d):
c = 44
m(c) = c^d mod n
m(44) = 44^47 mod 91
m(44) = 60
m = 60 (now you have the secret)
Prove you wrote something
1. Hash the message to broadcast (this is Knuth's insecure hash function):
broadcast = 102
hash(broadcast) = broadcast * K mod 2^32
hash(102) = 102 * 2654435761 mod 2^32
hash(102) = 169507974
2. Compute the signature with your private key (n, d):
signature = hash(broadcast) ^ d mod n
signature = hash(102) ^ 47 mod 91
signature = 169507974 ^ 47 mod 91
signature = 90
3. People who receive the broadcast message (102) and the signature (90) can confirm with your public key (n, e):
broadcast = 102
hash(broadcast) = broadcast * K mod 2^32
hash(102) = 102 * 2654435761 mod 2^32
hash(102) = 169507974
confirmation = hash(broadcast)^e mod n
confirmation = 169507974^23 mod 91
confirmation = 90 (matches your signature)
Why is this safe?
In this simple example it's totally not. You can trivially take n = 91 and guess p and q with simple factorization:
>>> set((91 / i) for i in xrange(1, 91) if 91 % i == 0)
set([91, 13, 7])
Redo all the math above and you have the private key. Doh~
Now imagine if n was such a large number that it took a very long time to guess p and q:
>>> set((12031294782491844L / i) for i in xrange(1, 12031294782491844L) if 12031294782491844L % i == 0)
This takes a really long time. Even fancy solutions on the fastest computer on Earth would take until the end of the universe. That's why transmitting secrets with public key cryptography is safe. That's also why great leaps in prime number theory are frightening / exciting.
Select a worthy challenge. Tell a compelling story. Assemble a good team. Put them in control. Enable the cast of characters to express themselves. Help improve their skills. Be fair and settle disputes. Overcome setbacks, together. Accomplish the mission (against all odds). Make sure it's fun for everyone.
Er wait, no, sorry — this isn't about the role of a Dungeon Master. This is what it takes to lead an engineering team. Who knew it's the same thing?
I've always thought that good work speaks for itself, that programming is a meritocracy. The most successful software projects I've seen are just immediately and self-evidently awesome. These are the role models I hope to emulate. It goes back to the Jargon File:
It is better to be described as a hacker by others than to describe oneself that way. Hackers consider themselves something of an elite (a meritocracy based on ability), though one to which new members are gladly welcome.
Recently I had a conversation with an engineer I respect very much about meritocracy. Their opinion surprised me: The quality of your ideas and code matters, but that alone will not convince others of your point of view. The very first thing you need to do is build relationships with people. Persuasion, even for software engineers, even in an assumed meritocracy, starts with the trust between individuals.
Thinking back to projects I worked on 4+ years ago, it's clear to me that this foundation of trust is something I have not understood. The worst example is a long and cynical story. I'll spare you the details, but the experience burnt me out and led me to a new project.
The gist: I was trying to convince another team to take a different approach to a problem. I tried to make my arguments with code, prototyping alternatives to prove my point. My suggestions fell on deaf ears. But that's because I was doing it wrong. I should have taken the time to build relationships with that team so we understood each other's perspectives. Without that we were talking past each other. I remained unswayed by their arguments, they ignored mine.
Looking back I feel pretty dumb. Now I get it: Persuasion starts with trust. If you want to convince people your idea is right, you first need to build relationships with them. If you build relationships, you may convince them you're right, or they may convince you that you're wrong. Either outcome is positive. This highlights what I've known for years now: Software development is primarily a social endeavor, not a technical one. The technical part of programming is just the setting for the real story.
My team launched a new product a couple weeks ago. It's an endorphin rush: jumping off a cliff, entering the unknown, showing the world what you've been doing. The longer it's taken, the scarier it is. But it feels great.
You experience the same thing to a lesser degree after hitting publish on a blog post. Tweets are a shortcut to this feeling, minimal effort for a small reward of satisfaction. That's probably why people like the tweets (and why tweeting is lazy).
"When I got started in my dorm room at Harvard, the question a lot of people asked was 'why would I want to put any information on the Internet at all? Why would I want to have a website?'
"And then in the last 5 or 6 years, blogging has taken off in a huge way and all these different services that have people sharing all this information. People have really gotten comfortable not only sharing more information and different kinds, but more openly and with more people. That social norm is just something that has evolved over time.
"We view it as our role in the system to constantly be innovating and be updating what our system is to reflect what the current social norms are.
"A lot of companies would be trapped by the conventions and their legacies of what they've built, doing a privacy change - doing a privacy change for 350 million users is not the kind of thing that a lot of companies would do. But we viewed that as a really important thing, to always keep a beginner's mind and what would we do if we were starting the company now and we decided that these would be the social norms now and we just went for it."
aboard vs. on board - These two terms mean nearly the same thing and in some uses are interchangeable. "Aboard" is the preferred usage. Use "on board" as two words, but hyphenate on board when used as an adjective. "Aboard" means on board, on, in or into a ship.
A space fountain is a proposed form of structure extending into space that, unlike a space elevator, does not need to be as tall as geostationary orbit, and does not rely on tensile strength for support. In contrast to the space elevator design, a space fountain is a tremendously tall tower extending up from the ground. Since such a tall tower could not support its own weight using traditional materials, fast moving pellets are projected upward from the bottom of the tower and redirected back down once they reach the top, so that the force of redirection holds the top of the tower aloft.
It has "sign in with X" buttons, but those buttons don't sign you in at all, they just give Disqus your email address and pre-populate their account creation form. You still need to pick a password and create a Disqus account. No thanks.
Zed Shaw's talk "The Web Will Die When OOP Dies" (2012) is a good critique of the steaming pile of shit we call the web platform. In the talk his observations about object oriented programming are similar to those from Rob Pike (2012) on why C++ programmers aren't using Go. Rob also captures why I'm averse to using languages with vast hierarchical type systems.
Maybe this whole OOP thing is a fad? Funny that it was popularized by NeXT. The lifecycle of technology platforms (e.g., OOP, XML, Ruby on Rails, Node) reminds me of economic booms and busts: irrational exuberance. I guess that makes me a value investor.
Want to be seen as upper class and as a person of good character? Don't smile.
In a letter to the Sacramento Daily Union, Twain wrote, “A photograph is a most important document, and there is nothing more damning to go down to posterity than a silly, foolish smile caught and fixed forever.”
The 10x engineer discussion going on isn't about 10x engineers. It's about team dynamics and people making excuses that are harmful. That's a fine and useful discussion. On the actual subject: The 10x engineers I've known are outliers in productivity. E.g., one of them has a university course taught about their brain. It's not something you can aspire to be.
“We find it a stupid chant,” said a 33-year-old fan named Stephen, who is a Garden State Ultras leader. He declined to provide a surname, noting most knew him as Terror. Still, he said, some members were uncomfortable about regulating language inside the stadium and uneasy about being offered incentives — however anyone wanted to characterize them — to control their behavior.
“We don’t do the chant,” he said, “but we don’t want money to be told not to do something.”
What were you thinking, O bicyclist? Through the wheel, not through the frame, quick-release on the same wheel! This was so easy I almost stole the bike myself (but would have given it to the guard of the nearby building, I swear).
People tend to buy the big clunky U-locks because they don't know how to use them properly. A U-lock should go around the rear rim and tire, somewhere inside the rear triangle of the frame. There is no need to loop it around the seat tube as well, because the wheel cannot be pulled through the rear triangle.
I guess this is the problem with tricks. If you just learned a trick and try to reproduce it, did you do it right? If it's so tricky, how can you be sure? This is part of why I try to avoid cleverness in general: too high a chance of fooling yourself into thinking you're right.
For the record: I do not use Sheldon's lock strategy.
The two most practical skills you'll need as a professional programmer
I love this cautionary message in NewsBlur as it's loading:
Indeed, counting is difficult. It's one of the hardest things I do at work. Hell, you could even say that professional computer programming consists primarily of two seemingly simple activities repeated over and over:
1. Counting things: data points, log records, clicks, views, users, tweets, transactions, money, pixels, padding, percentage, significant digits, bytes, zeros — the possibilities are infinite (har har). But really, some of the nastiest bugs I've seen in practice are related to counting even the simplest of things. Some of the mostcomplexsystems I've used are glorified counting engines. Thus, to be a good programmer you must first learn to be good at counting. This is probably why they forced us to take discrete math and computability. I didn't appreciate that at the time.
2. Copying data around: user input to a POST, HTTP to request parameters, parameters to an SQL query, query to RPCs, RPCs to b-trees, b-trees to blocks, blocks to bits, and back again. At Google I call this "pushing protos" because ultimately a project isn't done until you have copied the contents of one protocol buffer into another with minor changes of the format (perhaps you'd even call this "Dean's Law"). Elsewhere this is all the conversions you have to make through JSON and POST parameter names just to get your JS frontend to talk to your database through a server.
Now that I think about it, I don't think these skills are limited to programming. As a musician, for example, you must count time and pitch, you must repeat themes in slight variation. Perhaps this is just the nature of information.
"I will never use Python in production ever again"
This quote is from an engineer I respect very much. The reasoning behind it was they hit a few SyntaxError and AttributeError exceptions in their production jobs and had to do a whole new release to fix it, which took a lot of time. The same engineer followed that story by saying that Python is also slow, so to them, overall, Python totally isn't worth using ever again.
1. Why didn't you have tests that caught the syntax errors? Static typing doesn't ensure correctness for languages like C++ and Java. You should always test your code! Say you implement the same functionality in Python and C++, respectively, and the same tests. All other things being equal, I expect the total time spent in Python will be lower than C++. The whole point of using a dynamic language is to boost your productivity as a programmer for equivalent work. But you must always write the tests!
2. Why did your release take so much time? Everyone has hit an exception or crashing bug in production. Fast deployment is crucial for fixing these, continuous deployment is even better. With frequent, smaller releases to production the risk introduced by each release is lower, the cost of fixing bugs in each release is lower, and this lower risk compensates for pushing "fresh" code all the time. So who cares if you have a SyntaxError? Pushing should take minutes, not days.
3. If Python is slow for your problem why are you using it? By using dynamic languages you are trading program execution time for project execution time. The code will take less time to write but will also be slower (or take more resources) when it runs. That's okay, because the vast majority of the time I find it's fast enough. When Python will be too slow, I find another tool that fits the use-case (C++, Java, R). No tool is a panacea. You should choose Python when it makes sense to use it.
Like any tool, Python is great for what it's good at, which is many things. The APIs Python enables are wonderful. For what Python can't do well it works great for a prototype, but long-term you may find the need to switch to something else. That's fine! The constant lesson is always use the right tool for the job you're facing. In my experience, all things being equal, I find that Python* lets me focus on making my project successful by delivering functionality to users sooner. That's what's important to me.
Finally: What's really interesting in this whole consideration is Go. Go is the closest I've felt to Python with a static language in terms of productivity, and I don't even know Go very well. I look forward to using Go more and seeing when it can replace Python for my needs.
* This applies to any dynamic language, really. Advocating for Python specifically isn't my goal.