Matt Mazur

What an interesting day.

It started off with a long conversation with my boss about work related issues. The only thing to say about that is that for some reason the more I want to impress someone the stupider I seem to sound. When I talk to my brother, for example, I am clear and deliberate and speak with a kind of verbal alacrity that I seem to totally lose when I’m talking to someone I’m trying hard to impress. I much rather have it been the other way around, but, what are you going to do…

I left work a bit early to head out to Philly for this month’s Ruby meetup. The group, formerly known as Philly on Rails and now known as Philly.rb (due to interests in frameworks other than Rails), meets twice a month: a pub night, where people sit around, drink beer, and talk about geeky things, and an instructional meeting, where people get together in a classroom environment and talk about more geeky things. Today was the first instructional meeting I’ve attended.

Getting there was a bit of an adventure. Due to today’s nasty weather in the Northeast, traffic was slow as hell. The drive to Philly took about three times as long as it should have normally taken. Stop and go, stop and go, stop and go all the way. Then, when I get there, I have to deal with city driving, which I’m not terribly fond of. Somehow whenever my Garmin says “Turn left in 200 feet” I always either turn too early or too late. After several wrong turns and angry honking horns later, I found my way to my destination… almost. I found a parking spot, walked another 15 minutes to the address I had written down and wouldnt you know it: it wasn’t the right address. Great. I walked back to my car, paid my parking ticket and attempted to leave the garrage, but putting the ticket stub in my wallet reset it so that when I finally got to the gate and attempted to exit, the ticket reader machine rejected me. I had to politely ask the six people behind me to back up so I could go back and talk to someone. I got that taken care of and made my way to the right address, and finally, after a long adventure, I found it.

I arrived at about 7:40. I had planned on getting there at 6 when it started. There were about 15 guys gathered in a dimly lit basement classroom at the college building where the meeting was being held. I quietly walked in as a guy was finishing a presentation about iPhone development. I didn’t understand most of what he was saying, but got the impression that iPhone development is a complicated beast.

When he finished the organizer — Colin — asked if anyone else was interested in talking. I had previously mentioned to him demoing Domain Pigeon. I thought it was very tactful of him to ask if anyone was interested even though he knew I was there and I had mentioned demoing. He could have called me out, but did the polite thing for me and the other guy who mentioned talking and just asked if anyone else was interested.

I said sure, he said something like “Oh yeah, you wanted to demo your domain site.” I got up, hooked up my Macbook, and started talking. I had a rough idea beforehand of what I wanted to say but mostly winged it.

On a scale of 1 to 5 I’d say I was about a 3. Not bad, but not great either. I noticed myself saying “uh” a bit too much and I hunched over the podium more than I should have. I added unnecessary details to my explanations and omitted important things. There was a general flow of the demo, but I should have practiced a bit more beforehand. After a few minutes of heightened self-awareness I loosened up and things were good, but I feel like I’ve got a ways to go in this area. My philosophy on things like this is that you have to do something and suck at it for a while before you can become proficient and eventually good. Some people may be able to jump directly to good by sheer talent, but for me at least with this, I have to do it for a while, however poorly, before I pick it up. It’s kind of frustrating to know you’re doing something poorly but lack the knowledge or skills to do better, but I’m happy that I at least realize it and know that it’s part of my process. It’s similar with web page design. ALL IN Expert was probably a 2 on the 1 – 5 scale. Domain Pigeon will probably be about a 3.5 or 4. Without taking these steps I won’t be able to get to the 5 one day, whatever that may be.

The feedback was generally positive. They asked some very good insightful questions about how it would work and gave me some helpful feedback on a few usability, coding, and design issues.

The two meetings I’ve been to have been very humbling. While I consider myself a pretty good programmer, these guys having an amazing amount of technical knowledge. Most of them talk way over my head when it comes to the intricacies of a programming language and how one languages compares to another and what not. I recall some of the terminology from my computer science education, but have forgotten a lot of it. It made me realize I care more about what I can do with the language than how it works. There are pros and cons to that but overall I’m happy with my bent towards practical vs theoretical considerations.

Afterwards, I got into a conversation with a guy named Eric. Eric’s a 50 year old serial entrepreneur who now specializes in buying and selling small businesses. He’s got a strong technical background, but doesn’t limit his work solely to that area. I started picking his brain and when it was clear that we enjoyed the conversation we decided to walk over to a nearby Starbucks and continue it over some coffee.

It was quite the discussion. We wound up talking about the significance of leverage and its current role in the economy, using neural networks for speech recognition, the philosophy of science, the long term value of an MBA, mobile phone startups ideas, the ideal size for a tech startup, differences in business structures, personal guarantees, the importance of passion for your job, equity considerations when raising capital, and the risks of getting married in your early 20s, among other things. We talked for over an hour and I walked away feeling that the night was well spent despite all the earlier difficulties.

And now I must sleep, as I have to get up in 4 hours… =)

Rather than studying business, what about starting a company from scratch? If history is any guide, a significant number of people who are laid off over the coming year will do just that. Carl Schramm, the head of the Kauffman Foundation, a non-profit organisation that promotes entrepreneurial activity, points out that start-ups tend to flourish in the year that follows a sharp downturn. Rather than head back to another corporate bureaucracy, some of those made redundant will take a shot at being their own boss.

from The Economist

Taken from How To Spot a Breakthrough: Tips from Early Amazon Investor Nick Hanauer, which has a lot of good sound bytes:

The key elements of a breakthrough idea, Hanauer said, are value creation and social disruption.

As for social disruption, Hanauer gave a quick summary of what he meant:

—If everyone thinks it’s a great idea, it probably sucks.
—If people understand it, you’re too late.
—If people don’t like it and don’t understand it, it probably still sucks.

If you have a breakthrough idea, you don’t need a breakthrough way to get it to the market. “If you have transformational value, people will beat down your door…Focus on the product. If the product is good enough, marketing will take care of itself. If the product sucks, no amount of marketing will get you over the hump.” [see ALL IN Expert]

—”I’m not a technologist. From my point of view, technology is simply a thing that allows you to bring transformational things to customers…People get excited about a particular technology, and they forget the question: what does this do for people? It’s about what the customer gets compared to the alternatives.”

—”As an entrepreneur, I’ve never been concerned about competition. If you’re early, run like hell. It’s all about execution at the end of the day. It’s about having a great idea, executing like hell, and delivering value to customers.”

—As for walking a different path, “I was difficult for my parents, and for my teachers. I’m incredibly uncomfortable in crowds, I never go to sporting events…What that allows is for you to have an idea and be comfortable with people not liking it. Jeff Bezos calls me a high-functioning contrarian.”

Hmm, I think I just quoted about half the article.

You know those password reset links that are sent to you get when you forget your password? Well, some of them set a limit on how long you can use it before the link stops working. For the life of me, I couldn’t figure out why sites did this. Who cares how long it takes me to get around to resetting my password? Why not just make the same link work every time a person wants to reset his or her password?

So, I coded up a registration and password reset system for Domain Pigeon without setting a time limit on reset password links.

Last night, somewhat randomly, it hit me why this is a bad idea. It’s so obvious now that I don’t know why I didn’t think of it sooner.

If you reset your password in a public place, such as a library computer, the reset password URL will probably be stored in the browser navigation history. The next person who uses the computer might accidentally come across the “www.whatever.com/reset/…” URL and click it to see what happens. Surprise: it still works.

So how do you prevent this? You guessed it: a time limit.

Here’s how I implemented it for Domain Pigeon. When the customer requests a password reset email, store the time they requested it and then, to generate the URL, use a hash of the user’s email concatenated with the time they requested it. This’ll ensure that the URL is unique based on that specific request (aka a salt).

Then, when the customer clicks the link to reset his password, compare the current time to the time the link was sent and if it’s less than a specific amount of time, allow him to change his password. In pseudocode, this looks something like:

if hash(user.email + user.forgot_sent_at) = params[:hash] and user.forgot_sent_at + 2.hours > Time.now then
... yada yada yada
end

[Update: Note that the has function used here is a SHA-1 hash of the input concatenated with a secret key, so that the final product here = SHA(user.email + user.forgot_sent_at + long_random_string). Thank you to Artem for pointing out it needed to be clarified]

Lastly, after the password is changed, reset the stored time. That will prevent someone from changing the password twice using the same reset password link.

The only flaw I see with this method is for the person who clicks the link to reset his password and abandons it, because that’ll allow someone else to access the page and reset his password. Fortunately, this should be rare enough that it’s not a major problem. For extra security, set the time limit to five or ten minutes. After all, how many people request a reset password link and don’t access it within the next few minutes? For the few that do, they probably won’t mind the small annoyance in return for the extra security.

If anyone has any thoughts on this method or password reset algorithms in particular, please let me know.