I'm sorry you didn't have a good interview at Digg. My goal, then and now, is that even people who don't get an offer should leave feeling okay about the process. I clearly didn't live up to that with you, and I apologize for it.
We never made a no-hire decision based on one answer, and nobody ended an interview after one question, unless there was some sort of emergency. Site outage, fire alarm, that sort of thing.
> He went on to ruin digg.com (the rewrite everything guy)
I didn't ruin Digg. Ruining Digg was an all-hands-on-deck multi-year team effort. I wasn't involved in the decision to rewrite it and didn't agree with it. I don't know for sure who was, or what pressures were at work behind it.
What I do know is that our VPE came to me and said that we were going to rewrite Digg from scratch, and do it in six months, because the code was a mess and it took too long to do anything. Which was true.
I told him it was a terrible idea and we should figure out the end point we wanted to be at, then incrementally refactor our way towards it.
He said we'd tried that and it didn't work, so we were throwing away everything and rebuilding it from scratch. In six months.
I said that if we wanted the slightest possibility of success, we'd have to cut features to the bone and ship a minimal version we could quickly iterate on. I suggested cutting the ability to comment on stories.
He told me he didn't think we needed to do that, and we were going to ship a feature-complete version of Digg in six months, from scratch.
It was a completely bananas project, doomed from day one, and I wasn't shy about saying so — I told anyone who'd listen that I gave it a 50/50 chance of destroying the company. The promises made about what would be delivered & when were completely unrealistic and unreasonable. There was nobody articulating what we were supposed to be building, or to say no to what shouldn't get built. Into that leadership vacuum flowed a torrent of well-intentioned but (in my opinion) misdirected ideas for what the thing should be, which ate that first six months in the blink of an eye.
I sympathize; I was in a simliar situation around five years ago.
There are three things I've done which have been responsible for literally every job I've had in the last decade. In order of importance, they have been:
1. Know people.
2. Engage in the FOSS community.
3. Challenge myself.
That's it. Now, the interesting thing is that if you reverse this list, you get the steps you need to get a new job:
3. By challenging yourself, you will increase your knowledge base and become a better coder.
2. Find an project, tool, or subject that interests YOU. Something YOU would find useful and rewarding. Whatever it is, write it and RELEASE IT. If there's a project that already does what you want, start contributing. Help other people use it. Write documentation. Anything. Whatever it is, RELEASE IT. Doesn't matter if it's something a hundred people worldwide will find interesting - you'll get their attention, which leads to…
1. Knowing people who can get you jobs.
I cannot stress this enough: RELEASE CODE. The great thing is that you can usually get your employer on board with this. If other people use it, they can contribute features and bugfixes back, which they can make use of. It's like having programmers work for them for free.
The fact that you have this ambition at all puts you at a significant advantage over other programmers. Keep hold of that drive.
Clever shortcut to use JS literals, which means that parsing it can be read with eval(), but the syntax sure is awful. No symbols to speak of, no keywords, and commas everywhere.
I bought a 16gb iPad the week after they came out. I didn't really have a need for it, I just wanted to see if it was interesting. I had a very simliar experience as the author.
My wife has little but distain for my gadget obsession, but within minutes she wanted one for herself. Our three-year-old adores it. I put some educational games and cartoons on it, and she can get to it all on her own. Literally every person I've shown it to has wanted one.
I have a wide array of taste, but when working, I primarily listen to metal. The key here is something with a fast and steady beat, which really gets me into the groove.
It's hard to automatically classify this kind of music, so I have a half-dozen or so hand-made playlists, each around an hour long.
The music is for when I know what needs to be done and just have to sit down and do it. When I'm thinking about a problem, silence is what I need.
Comments are denormalized and stored two ways: One in a plain ColumnFamily (for random access) and one in a SuperCF (for sequential access).
The plain CF ("Comments") uses the comment ID (which is a timestamp+salt) as the row key. The fields of the comment are columns in the row (username, text, date_created etc).
The SuperCF ("StoryComments") uses the story ID as the row key. Each row contains one SuperColumn per comment. The SC name is the comment_id, and the columns are the fields of the comment.
So, say you want to get the first 50 comments for a given story, you'd do a get_slice on StoryComments, passing the story ID in as the row key, "" as the start column, and a count of 50. You get back 50 SuperColumns, each of which contains one comment.
Cassandra is extremely good for sequential reads, not just random lookups. Just about any list of things can be efficiently stored and retrieved with its batch insertion and slicing operations.
Just like it's important to learn multiple languages to be a well-rounded programmer, you should train in multiple styles of martial arts to become a well-rounded fighter.
I recommend kickboxing for learning fundamentals of open-hand stand up fighting, Sambo or BJJ for ground fighting, and Filipino martial arts (Kali/Arnis/Eskrima) for weapons and to tie it all together. Wing Chun fits in nicely as well, and JKD is worth your time too.
I echo the sentiments of the people who say it's less about the style than the teacher. A good teacher will expose you to outside concepts. A good teacher will teach you to be practical and not flashy. I strongly recommend you focus on practicality. Always ask yourself, "how will this actually help me if I have to defend myself?" I've seen practitioners of certain styles get completely taken down because they were not taught to be practical - nothing to do with the style per se, but they didn't have good teachers. In particular, I recall a Tae Kwan Do fighter try to use spinning kicks while sparring. As soon as he started to turn his back, his opponent simply stepped forward and kicked him in the balls from behind.
1. Perhaps you could keep the PHP-style syntax around under a different name.
2. Sweet.
3. (:some_array 4) seems perfectly reasonable. Would that interact with superglobals the same way? e.g. ($:server "PHP_SELF"). I believe that PHP 5.3 or 6 has return value dereferencing, so I don't think it's necessary to know the type - you could just do (:(array 1 2 3) 1)
4. If you haven't played with Clojure, you might find inspiration there. It has interop with native Java instances, though I find it a little too syntaxy for a Lisp, and PHP doesn't have such deep class structure.
Nice start. I was considering something simliar, but I just didn't care enough about PHP to work on it.
Stuff that I'd like to see improved:
1. if/elseif/else syntax is pretty ugly. What are the chances of getting if/when/unless/cond?
2. Nicer array syntax. Maybe coopt the vector literal syntax, since PHP doesn't have anything similar: [1 2 3]. Failing that, quotes: '(1 2 3) -> array(1, 2, 3). Not sure how to handle cases where you would have something inside the quote that would eval, though.
3. Not thrilled with the superglobals/array syntax, which are more verbose (or the same, in the case of superglobals).
4. It isn't clear if/how this interacts with objects. Does it work like: (object->method arg1…argN)? What about static methods?
I was specifically writing about features Lisp pioneered which other languages adopted. I think it's enlightening to understand the roots and history of things, and fint it amazing that such an old language pioneered so many fundamental constructs.
Perhaps by 2059, we'll have languages with macros and regular syntax.
We never made a no-hire decision based on one answer, and nobody ended an interview after one question, unless there was some sort of emergency. Site outage, fire alarm, that sort of thing.
> He went on to ruin digg.com (the rewrite everything guy)
I didn't ruin Digg. Ruining Digg was an all-hands-on-deck multi-year team effort. I wasn't involved in the decision to rewrite it and didn't agree with it. I don't know for sure who was, or what pressures were at work behind it.
What I do know is that our VPE came to me and said that we were going to rewrite Digg from scratch, and do it in six months, because the code was a mess and it took too long to do anything. Which was true.
I told him it was a terrible idea and we should figure out the end point we wanted to be at, then incrementally refactor our way towards it.
He said we'd tried that and it didn't work, so we were throwing away everything and rebuilding it from scratch. In six months.
I said that if we wanted the slightest possibility of success, we'd have to cut features to the bone and ship a minimal version we could quickly iterate on. I suggested cutting the ability to comment on stories.
He told me he didn't think we needed to do that, and we were going to ship a feature-complete version of Digg in six months, from scratch.
It was a completely bananas project, doomed from day one, and I wasn't shy about saying so — I told anyone who'd listen that I gave it a 50/50 chance of destroying the company. The promises made about what would be delivered & when were completely unrealistic and unreasonable. There was nobody articulating what we were supposed to be building, or to say no to what shouldn't get built. Into that leadership vacuum flowed a torrent of well-intentioned but (in my opinion) misdirected ideas for what the thing should be, which ate that first six months in the blink of an eye.