Django Masterpiece

Let’s roll:

Revolution

(I’m going to start going over the major projects I’ve worked on over the years.)

This project, dubbed Revolution, was my first major programming endeavor. I worked on it heavily in late 1998 and distinctly remember sending it to my friends in middle school and watching with pride as they used it to scroll massive amounts of text in random AOL chat rooms.

This was the reason I got into programming in the first place. My friend Jake sent me an AOL prog (program) and curious, I set out to learn how to build one.

The code is absolutely terrible and the only thing uglier is the design. It was a start.

Here’s some screen shots:

And here’s the menu hierarchy which shows all the exciting features:

I almost forgot about this program until I was going through some old 3.5″ disks and came upon it. I’m glad I did… I haven’t seen the words “Lagger” or “Punter” or “Fader” in many years.

Gotta love it.

Why to Set a Time Limit on Password Reset Emails

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.

Macs: Productivity made Easy

Day #3 of the Macbook…

I began working today with the intention of integrating a test Heroku site with Paypal’s Instant Notification System. Didn’t get there quite yet, but I’m getting there. Here’s a few things I worked on this evening:

Modifying the Terminal Prompt

Every line had been displaying “matthew-mazurs-macbook: Matt $” or something long and annoying like that, so I looked into how to change it. Some helpful individual on #rubyonrails told me to look up PS1 and surely enough, changing it is pretty easy. This site teaches you how to change it, though this method only works for the current terminal. When you reload the terminal the name reverts to its previous state. To change it permantely, you have to close down termal and edit /etc/bashrc in some text editor. Change the PS1 name to whatever you want and it’ll be changed permantently for future terminal windows. There’s probably an easier way to do this but hey, it worked.

Using VI

As nerdy readers have probably realized by now, I suck at the command prompt. I regret not taking more opportunities during my college compsci classes to gain more experience with it. Anyway, this tutorial is a pretty good introduction to what you need to know in order to navigate vi.

Ruby Gems

Up until this point in my app’s development I haven’t had to use any gems so I was pretty lost when I read I should install a Paypal gem to interact with Paypal’s Instant Payment Notification system. For the unenlightened, IPN is an alert that Paypal sends to your site when someone has made a purchase. You can use this notification to enable a user’s account, for example. Thankfully, rubygems.org offers an excellent tutorial which quickly brought me up to speed. I worked my way through their progressbar example, which as stupid as it is, was a nice thing to get working.

Fortunately, while developing ALL IN Expert (more to come on that — I promise), I spent a lot of time learning how to do IPN with PHP. Things are slightly different now, but the prior experience is helpful.

Focusing on Productivity

I’ve been spending some time the last few days thinking about ways I can improve my overall productivity. In general, I’m not working at a pace that I’m satisfied with, and while part of that is due to long hours at work, a lot is also due to not fully taking advantage of the free time I do have.

Accordingly, I made two major changes today that should:

News. A few months back, per Marc Andreessen’s advice, I subscribed to the Wall Street Journal. At first I attempted to read it on a daily basis. Now, I’m lucky if I scan it through twice a week. The problem is twofold: 1) I don’t understand a lot of it and 2) It takes time. The original purpose was to learn the important things going on in the world and in the tech industry. I think a combination of Hacker News, Inc magazine, and a few of the major blogs take care of the tech half of that goal. Usually, when my time was limited, I would just flip to the Business section and see if there were any internet related articles. For the news half, I’m going to subscribe to Time, which I think is excellent. Since they’re a weekly publication they generally avoid a lot of the irrelevent news, and they write less in one issue than the WSJ writes in a day. Starting tomorrow, I’m putting the WSJ on hold. There will hopefully come a time when I have the time and the need of reading it on a daily basis, but that time is not right now.

Computer Usage. I’ve been using InstantRails on Windows Vista in conjunction with UltraEdit for learning and programming Rails. InstantRails, as far as I can tell, is a hack that let’s Windows developers work with Rails. It gets the job done, but it just doesn’t feel natural. And so, today, I took the plunge and bought a Macbook, which I’m currently writing on. It is a breadth of fresh air; I wish I had made the switch earlier. It’s taking a bit of getting used to (I didn’t know what the traffic lights at the top of the windows were), but it’s incredibly straightforward. Usability was clearly a focus for the Mac developers, which is why it’s been such an easy transition. The plan is to do all my web development on this computer from now on.

My goal is to launch Domain Pigeon by the end of the year.

I’m going to try to write more often, as I find that it helps me to write things down.

Thanks for reading.

Good Design is Easy, Great Design is Hard

I spent a good seven or eight hours today working on Domain Pigeon.

The last week has been very busy so I haven’t been able to make much progress, but with a full day to work I got a lot done. The site now has a registration system and a semi-well done home page. One of the designs that I put together two weeks ago (that took several hours) I completely scrapped today in favor of another. I get this feel like I’ll scrape this one in time too, but, hey, the more I iterations I go over the more I learn what doesn’t work.

After spending a lot of time playing with different layouts and color schemes I’ve come to two conclusions: 1) It isn’t very hard to make a site that looks OK. 2) It’s a lot harder to design something that looks great. I base this on the fact that the majority of websites are designed with very little attention for usability, color schemes, overall layout, navigation. Most are, well, ugly. But every now and then you stumble upon a site that just flows. You get the feeling that if you asked the designer what the padding is between two adjacent elements, he or she will be able to tell you off the top of his head. Quality matters.

Esquire has an amazingly well designed magazine. Everything just seems to fit. Inc and FastCompany too. I’ve been perusing them looking for ideas and I suggest anyone who is stuck just pay the magazine section at the local book store a visit for some inspiration.

Function vs Design

My latest project, dubbed Domain Pigeon, is coming along well. I work on it when I can, getting in a few hours here, a few hours there, probably not totaling more than 15 hours/week. I’m at a point with Ruby and Rails where I am knowledgeable enough to know what to look for when I run into problems (which happens frequently).

With the limited amount of time I have to work on it, I’m trying to allocate my time better than my last project. With ALL IN Expert, I spent wayyyy too much time in the beginning worrying about the design of the website and the software. I literally spent like 10 hours one day experimenting with icons I was creating with Photoshop. This was probably a good sign that it was going to fail. I spent too much time initially deciding on nitpicky design details that really weren’t important.

On the other hand, there is value in spending small amounts of time working on the interface. Ideally, design should be driven by function. However, in my case I’m still working out the details on some of the functionality, so creating a basic site has helped narrow my focus in a lot of areas. Also, by designing the site as Igo, I’m starting to see what the final product is going to look like. It’s a pleasure watching beautiful things grow.

On an unrelated note, I’m removing the “Recommended Books” from the side bar. My original intent was just to share books that I liked, but it now strikes me as arrogant so I’m just going to nix the entire section. Also added Mark Cuban to the blogroll and removed some of the shittier ones.

Scriptaculous Troubleshooting

I spent the better part of the last two evenings troubleshooting some problems with the Scriptaculous library. On one of the pages for the project I’m working on there’s an element that is supposed to expand with some dynamically generated content when the user clicks a link. This was easily accomplished, except that the element expanded too far momentarily and then jumped back to the right size, creating a slight flicker. It also turns out that the element was expanding each time I clicked the link, so that it would start out with a hight of 24px, then be 36px, then 48px, and so on.

After way too much work, I realized that it was taking into account the size of the padding and border when determining the height to render.

Since I haven’t used it much, I naturally assumed that I was the one in error, but it turns out, the problem may actually be with the library. Anyway, after a lot of hacking away at it I finally achieved the effect I wanted and am that much smarter with Prototype now.

There’s a definite satisfaction with finding the solution to difficult problem.

Narrowing Down a Path

I spent a fair amount of time this weekend working my new Rails project. While I got a lot of work done, it reminded me how much work I could be doing if I actually had more time to do it. I’ve come to realize that I probably won’t be founding any HUGE startup soon. I simply don’t have time to manage anything that requires lots of time and involvement from me. I get home at 6:30 – 7 on average, which leaves little time to accomplish everything I want. 

Maybe this project will be really successful, but even if it isn’t, it should provide me with a solid foundation for more ambitious projects in the future. If by summer ‘09 I can be a Ruby/Rails expert, I’ll have a lot more opportunities to do the type of things I want to do. 

Also, I’ve been blogging a lot less. Somewhat paradoxically, that’s not a sign that I’m doing less work, but a sign that I’m doing more. If there ever comes a time when I give in I’ll make sure to write about it, but I don’t expect that to happen… ever. 

For the few of you who continue to read this, thank you, and I hope you’re making progress towards your goals. 

Matt

Zend, its Not You, It’s Me… Why Hello There…

Enough is enough. I’ve been trying to make my way through Practical Web 2.0 Applications with PHP the last few weeks, but have found myself unmotivated and making little progress. The book uses Zend Framework to build an Ajax heavy blogging system.

I can’t talk programming theory, but I can tell you that programming with ZF just didn’t feel right. The framework is bloated and fat and doesn’t make doing easy things easy. The examples in the book would go something like this: “Oh, that’s easy with ZF: Just follow these ten easy steps and voila, you’re ready to go.” Learning the intracicies of the framework became a chore and I just did not look forward to it.

Originally I attributed this to my own inexperience with frameworks. “I don’t care how annoying this is, I’m going to make it through this book” was how I approached it. But something was wrong, I realized, when I was looking for excuses not to program. That’s not what a programming language should do. It should encourage you to experiment and should enable you to do the things you want to do.

I went to Borders looking for a book on Django. They didn’t have it, so I went to B&N to see if they did. Why Django? No reason in particular. I’ve heard some good things and wanted to try something new. B&N didn’t have it either though so I scanned the shelves… PHP… ASP… Visual Basic 2008… Rails. Hmm, Rails. That’s not a bad idea. But wait: do I really want to become one of those people?

Sure, why not? I picked up Simply Rails 2 and made it through about 100 pages yesterday afternoon. My initial impression? The language just makes sense. It’s intuitive, relatively easy, and dares me to do something.

This is what programming is all about.

Next Page »