Category Archives: My Daily Scrum

Daily Scrum: Beta Invitations

All right, now I’ve got a permissions model in place. Now I can whitelist any controller action I like all in one place. Go get a Railscasts pro account and watch epsiode #385 if you want to see how I did it. I also have a way of testing those permissions that kind of approaches english.

Speaking of testing, I ran into a small bug yesterday where the tests for my accept invite buttons were not working. The accept status wasn’t changing. Pro-tip: Do not use instance variables in your expect blocks. Use the actual object you want to change instead. When the button was clicked, the invite object changed, but the instance variable did not. Learn from my mistake and save yourself some time there, folks.

So what are we going to do today? I am going to re-implement a beta invite system. I was trying to use the system from railscasts episode #124. I ended up mothballing it because the requirement for users to have beta invites was messing up my tests. Now that I have my authorization in place, I can implement a special beta user role that will hopefully stay out of the way of my testing suite. If all goes well, I would like to do a hands-on test run-through and list any features I must have before releasing the first beta. Wish me luck!

Kid in a Candy Store

I spent my time yesterday looking for ways to administer the site. I wanted to have control of what users could and could not do. While I do want them making friends and creating events, I would not want them to be able to change their own user roles or delete other users. This is a problem that you could spend years, literal years trying to figure out. Every time Facebook works on their authorization model, thousands of voices cry out in terror and suddenly silence.

There are so many different approaches to choose from. You could hard-code the security in, you can put permissions in the database, You can have changeable permissions, Pre-made GUI solutions. You got Cancan, Active-admin, devise,

There is just so much out there, that it’s easy to lose sight of what your specific needs are. In programming, if you don’t build things to your specific needs, you could be asking for trouble. I found this really great screencast on railscasts about creating authorization from scratch. You can create a permissions model and wall off certain controller actions to certain user roles. The best way to do that is to have a pyramid of user roles with admins and the top, and banned accounts at the very bottom. Here’s what I want my authorization model to allow.

1. Administrators can do anything

Anything at all, whether it’s editing users, deleting users, or changing events. It’s not something I’ll delegate to any kind of customer service moderator, but it’ll make things easier if I just have total control. I’m also going to allow administrators to change the number of beta invites for each user which I will implement after the authorization model is complete.

2. Users can make friends, create events, create invites, but they can’t create, edit or destroy any events or users that are not theirs. Editing Game profiles is right out.

Pretty self explanatory stuff, until you try to explain it to a computer.

3. Beta Users need Beta Invites

I’m creating a beta user role because I don’t want new users being created without beta invites. The vanilla user class will just be around for testing purposes and when I take the app out of beta.

4. Banned Users should not be able to do anything.

Since this is a gaming website, there will eventually be griefers who try to make other users lives difficult. Implementing a banhammer of sorts will work as a kind of deterrent. It’s not much of one, but I believe it should be there until I can put more complicated safeguards in place.

So once the authorization is in place and the beta invites system is working, I will transfer the domain name, to my production server. The very first users will be myself and a few friends. Based on our experiences I can figure out which features I should implement next, and expand the circle of users as the app gets more advanced.

Getting to Beta

Sometimes things just go your way. I restarted the server and the accept buttons just seemed to work. I can now pass variables between partials with impunity! I spent the rest of the day playing around with the layout and the bootstrap classes, and look that this! It looks so…so…done! This is by no means the final product, but it’s readable! And it’s mine! This thing might actually have a shot at making it to beta!

At this point it’s a good idea to stop and think about where the project is going. Now that I have basic functionality it’s easier to pinpoint what’s missing. So where do we go from here?

Eventually I want to be able to connect this site with different social networks. The feature that sets Gameplaydate apart from other networks is that you can set up a trust index through info you already have through social media. Corroboration with networks like linkedin, facebook, and twitter will increase that trust.

I also want to be able to integrate the games management with various community apis that exist, like the steam api. This would allow new video games to be added to the system without a real person finagling with online forms. Users could also claim game ownerships by simply entering their steam id.

A queueing system will be an absolute necessity as the site grows. There will be a lot of e-mail to send and a lot of API checking on the site, the only way to manage that will be to implement something like Resqueue.

The first feature I should tackle is the Site administration. I want to be able to keep an eye on everything that goes on with this site. That includes activity feeds, account security, and data management. Once I release the site on beta, I want to control just how many people are using the site so I can rule them with an iron fist! Or just manage the site’s growth properly.


Here’s a good example of the kind of bugs I have to deal with. When I view an individual event, I want it to list all of the invites. It would be silly to hard-code in every invite, so I use something called a partial that calls up a nice little template to display each individual invite.

I want every invite to be able to display an Accept button so users can accept their own invites.

When they click that accept button, the status of the invite should change to accepted and the button changes into a cancel button, which people can use if they suddenly have a dentist appointment or something.

I put each of these two buttons into their own partial so that I can call on either of them without having to copy out the code. Sounds simple right?

It turns out that each button needs the ID number of the individual invite to work. So when I call the partial, I initialize a local variable by calling local.

I go to my page and…nothing. The variable is empty.

How can this be!? The logic sound, the syntax is correct, but for whatever reason, my website no worky. I’ve tried changing the variable names, switching to the object call, passing just the ID number. I don’t understand this! I am a good person! I deserve to have the things I create work!

And you know what, the fix for this is probably so simple, so obvious, that even an idiot could figure it out. But once again, I have to sacrifice my pride for functionality. I am going to have to repeat the code in the partial and the javascript until I have time to refactor it. The feature won’t be perfect, but it will be done.


I managed to finalize the sample data tasks for the events now as you can see here I have a layout filled with the event’s I’ve been invited to as well as the events where I have accepted the invitation. This would all be great if I had an interface to accept the invitations. It all works programmatically, but I need to create the buttons to accept the invites, not unlike the friend/unfriend buttons I have in the user’s list.

Okay, we had to fix up that mutual friends query there somewhere along the way.

I’m pretty sure at some point today I’ll need to take another look at designing the interface. I’ve still got that cute little wireframe that I tried to do in apple keynote, but I think I’ll head back to either inkscape or Adobe creative cloud to shore the rest of it up. Failing that, I’ve got some pencil crayons handy.