I’ve implemented a password recovery system, very nice, and I tried to implement the beta invites system, also a good idea, but I didn’t quite figure out the part where I had an original set of users to create all of the beta invites. Again I found myself coming up on a critical decision: Should I spend another 4 hours trying to crack this, or should I work on another, more forward facing feature? I find myself running into these types decisions again and again, and I’m struggling to figure out which feature should I work on first. Looking at my list, I’ve got an online persona system, add events to google calendar, an event check-in, re-factoring Factorygirl factories to incorporate beta invites. Where do I even start?
I’ve been working on this thing for a couple of months now. I have the luxury of some time and money, but the same time, this isn’t a funded start-up. I’m just a guy in a basement with a wi-fi connection.
The most important feature of Gameplaydate.com is to make it easier for people to use multi-player games.
The second-most important is to show off what I know about programming and making usable software. Right now it’s not doing either of those things. So my decision, for today, is to deploy Gameplaydate on Heroku. This is not an official launch, but I need to get out from behind the automated tests and decide for myself what needs work.
Yesterday, I spent way too long trying to make it impossible for Event organizers to invite themselves to an event. I didn’t even get to worrying about conflicting events. There’s a red test for it, but that’s about it. I came up with an answer to the “man cannot invite himself to his own lan party” problem. I was running around trying figure out where the validation should go. Should it be at the controller level? The Model level? Should it go in the Events Model or the invite model? I found that create invites in two places, at the creation of the event, and at the editing of the event. The Organizer validation needs to execute at both actions. So, the validation goes into both models.
I beginning to see a trend on features I’m willing to put hours and hours time into. It has to be something really simple in concept, but really difficult to execute. Again, I don’t believe I should spend so much time on one feature when I have other features that may be much simpler to implement. It’s easy to say “software must be beautiful and bug free”, but what’s the shortest path to that outcome? In the real world, people care about the destination, not the journey, particularly if you are building software for them. So today, we are going to try out some of the features that I have tutorials for, like the password recovery and the beta invites system. Hopefully that will be a quicker path to launching.
Between a phone interview, my son’s eye appointment, and waiting to open the door for the cable guy, I was lucky to complete the transfer back relational databases with all tests running green and glossy! I had to go back to making Events belong to users as opposed to making the event creator just another invitee. If I did it the old mongodb way, I had to do a lot more messing about with nested attributes, and nobody wants that. Today we’ll be trying to make sure a user can’t join or create a conflicting event. I believe we’ll be able to do this through a single time comparison method. Next we’ll validate that an organizer can’t invite himself to is own event, then we’ll get started creating a mutual friendship system. See you next time!
I spent the first half of yesterday trying to design the user interface a little more using Apple Keynote. It’s…okay. You can form boxes and colors rather quickly with it. The animation sort of works but because you can’t get a good look at all the animation actions at once and everything happens on mouseclicks, it gets a little complicated. You’re trying tosimulate a fully functional web app on what is essentially power point. It doesn’t help that I’m not that big on mock-ups. I try to get an idea of what I want with the design then do all the nuancing when I’ve expressed everything in code. It’s probably for the best anyway. An app in the hand is worth two in demo, as they say.
The last half of yesterday was dedicated to transferring back to postgres. After an hour of wrestling with my local installation, I decided to use sqlite on development since postgres is already fully installed on heroku. There are about 24 failures left for me to deal with, most of them have to do with the specific way mongoid saves records.
Once that’s finished, I’ve compiled a list of features for me to implement. These are either features I’ve implemented before, like custom validations, or features that I’ve found railscast episodes to go with. I think the tough part will be creating tests for them in the first place. First of all we are going to make sure events can’t conflict, so you can’t create or accept an invite to an event when you’ve had a previous engagement on the system. Next we’re going to make it so only mutual friendships are allowed, and that you can only invite mutual friends to events. Then there’s the recover password system, beta invite system, community points, profile trust index, game persona system, messaging system, google calendar integration and event check-in system! Not to mention a whole bunch of mailers to make this all work.
I’ve got a simple mailer working for my app now. I feel like I’m almost getting to the point where I can start deploying, but I’m beginning to realize that I need to crystallize my direction a little here. I’ve got a minimal UI going with twitter bootstrap and some code from Mike Hartl’s railstutorial, but I think I need to figure out what I want from the end product a little better. Today I’m going to try and use Apple keynote and gimp to see if I can put together a couple of User Experience stories together. If they’re good enough, maybe I can cut them together for use on my launchrock page.
Once that’s done, I’ve decided to make another change in direction. I would like to switch back from MongoDB to Postgres. I know I put a lot of work into making this work with a document based database, but the more I look at the problem I’m trying to solve, the more I realize I need a relational database. How all these individual data rows relate to each other is more important that what is actually in them. This way I can re-establish has-many through relationships. There are a lot of cool things about MongoDB, but I don’t think I’ll be able to use them until the site starts getting large. It might be possible for me to use MongoDB for more high-volume functions later. So for now, I’ll be using a more classic use case for Rails. I won’t give myself more than a day or so to do it, otherwise I’ll be throwing away a perfectly functional system.