El Dorado

So, first I wanted to say, I really like this app so far. The second thing is that, for the stuff I want to do with it (running a local community gaming website), I think I need a little bit finer grained control over what people can see and do with the website.

So I was planning to write a user/role permission system for this app, and was wondering if it would be something that would be useful in the main trunk of the code.

I basically picked this particular feature to scratch my own itch, and because I've implemented it before in other apps of my own, but I've never done anything bigger than 'hello world' in ruby, let alone anything rails, but I'm interested to dig into it. So I figured a problem I know how to solve would be a good place to start.

The other question I had is, are there any good 'ruby for X programmers' guides that anyone could suggest, where X in (C#, perl)? I'm already reading the pragmatic programmers guide (finding why's a bit to conversational and verbose for me). I've got a lot of background in perl, and write a bunch of C# for work. I tend to dig into idiomatic programming in any given language, so I'm looking to get up to speed as quickly as I can with idiomatic ruby. Any pointers would be great :)

Definitely start here: http://guides.rails.info/

The best approach to contirbuting to El Dorado would be to set up a fork on github, and then you can do your work over there. Let me know when you've got something working, but take your time and break stuff up into manageable commits.

http://github.com/trevorturk/eldorado/network

Good luck!

Last edited: Tue, 23 Jun 2009, 10:13pm by Trevor

Ok, so I've done some digging, and the more I dig, the more I find two things:

A) Rails is kickass, but requires me to relearn my code reading and navigating skills because of all of the stuff it gives you for free, and trying to figure out where each thing comes from. I have been spoiled by Visual Studio '08 in this regard.

B) I am completely torn between researching best practices (because I don't want to implement hokey crap) and getting stuff done. I think I'm still in the researching phase, because I keep finding new cool stuff (before_filters! ActiveRecord::Migration!).

So, what is your advice with this? Take a random stab at it and get feedback, or do more research before I dive in?

I'd say read through the guides until you get bored and then dive in. If you have a definite goal in mind and you're excited, there's no better time to start coding.

If you're thinking of making a permission system, take a good look at some existing plugins and/or apps. I know of a few, but doing some research on your own might turn up even more.

adva_cms is like El Dorado, but implemented in Engines. They may have a permissions system already, but I'm not sure. http://github.com/svenfuchs/adva_cms/tree/master

Altered Beast is the rewritten version of Beast, which is what I referenced when I was learning Ruby/Rails. It's nice and small, but may have a little bit more permissions than El Dorado: http://github.com/courtenay/altered_beast/tree/...

I won't be mad if you decide to use either of those apps instead of El Dorado :)

Here's two roles/rights plugins I'd bookmarked. Perhaps they'll be a good resource?

http://github.com/timcharper/role_requirement/t...
http://github.com/nakajima/roleful/tree/master

Have a look at them and see what you think. Sometimes a plugin can be exactly what you need. Sometimes, it's just a nice way to see real code to understand how to go about building your own thing.

I'm glad you're enjoying Ruby/Rails so far!

Thanks for the pointers :) Started actually working on this, after many moons of it dropping off of my project list. Currently futzing around to add the features I want, and having fun. May not be the best code I've ever written or will ever write, but as long as I learn something.

That's great. Of course, I would prefer if you did your work in a fork on http://github.com and let me know about it. That way I can see what you're up to and follow along.

Yep, just did my first round of commits. Still figuring out git, and haven't uploaded the updated config.example.yml that I just updated, but far to tired at this point to wrangle with git :)

Also? Never, ever, add a reserved ActiveRecord name as a field to your model :) That is confusing as heck to track down if it ends up in schema.rb :)

Figured out the git thing. Commit locally first, *then* push. Still getting used to git, been using subversion too long.

You're working in this one, right? http://github.com/archangelq/eldorado/tree/master

I'll check it out as soon as I have time.

I just took a peek (will look more later) but I wanted to mention something quickly. It'll be a lot easier for me to integrate features if you do things within branches. For example, your captcha stuff. If I decided to not pull that stuff in, but I wanted to get something else you did later, it would be a bit more of a pain. It'll also help you organize the stuff you're working on. I know it's another git thing to learn, but it'll be worth it! Unlike Subversion, git branches are painless to use :)

Man, even subversion branches are easy to use compared to SourceSafe. I think I'll take the time to learn it. Anything in particular that I can do as of now to go back and mark what I have already commited as part of a branch? I'll go looking through git docs as well, but figured I'd ask.

Also, so far, all the features I am adding are ones deliberately designed to be toggled on or off. I am thinking that my 'admin verified members' feature is probably better toggled in the db, but for now it is in the config. The recaptcha one is specifically meant to be toggled by entering the two keys that recaptcha uses to identify you, which I figured was a fairly painless/obvious way to tell the app that you wanted to use it.

Ok, probably not the most elegant of solutions, but I created a branch (probably the right way to do this), and then individually reverted each of the changes I had made to the master branch/trunk and then commited that (probably a cludgy way to do this). Also, ended up getting some upstream plugin changes, it looks like. Still unsure on how that all works.

This all sounds about right to me. I'll have to time check this stuff out in detail tonight. I'm planning on finishing up the heroku compatibility work, so I'll be digging in.

I'd say avoid putting more into config.yml unless necessary, but I know it's probably easier to just put stuff in there. I was thinking about loosening up the settings table to be a dumb key->val store (a la WordPress) but I'm not sure that would be better. Maybe moving everything into config.yml would make sense instead. I dunno if you have any ideas...

That is always tricky. On the one hand, storing it in the db means that you can more easily have the settings modifiable and persistable from the app itself, meaning that it is easier to expose these settings for non-local admins to configure.

The current config in the db, with the assumption being one column per config item, and only one row, doesn't seem all that different than the config file, honestly. I'm sure there are cases where it would become cumbersome, but another solution doesn't leap out as being really worth moving to with the current number of configuration settings, either. Mainly because of how ActiveRecord works, and the fact that moving to key/value pairs would break that, as well as treating everything stored as a string, which is rather lame, all in all.

Speaking of, I think I'll move the configuration regarding admin authorization into the db in my branch. I think I'll leave the recaptcha stuff where it is though.

Yeah, I don't have any real strong feelings on the config stuff. Let me know if you start leaning one way or the other. I suppose moving from active record config to config.yml would make the upgrade path a little tougher, though.

Ideally, you could have branches with independent features, and merge those all in your master. So, that way, I could pick and choose branches more easily.

I'm almost finished up with getting eldo to work flawlessly on heroku, but I don't think I'll be able to get to your stuff tonight. It's next on the list, though!

Yeah, the two items I am working on right now where both started and going at the same time, as they both touch signup, so I didn't think to before I'd dove in. For future items, I'll create feature branches from the master branch, and merge them into my combined branch for my deployments.

And, no worries :) I'm not even finished with the admin authorizing new members part. The 'new members require auth' part is done, but the 'allow admins to authorize' part isn't, not because it is hard, but just from the dozen other things I do. I've been trying to put about an hour or so each night into plugging away at this, with fruitful results so far. Having a lot of fun learning.

Once this feature is complete, I'll work on getting quality tests built for it.

That sounds great. So, just let me know when you have something ready for me to pull. I think your stuff looks good so far, so I'm happy.

When you do tests, please use Machinist instead of fixtures. I want to transition away from those eventually. The new file uploading stuff uses it and has decent testing, so you can see how I think it should work (uploads, avatars, headers, and themes).

If I ever have enough free time, I'll go back in and fix up some of those older tests. Making El Dorado was a "learn by doing" thing for me, but I can see a lot of room for improvement of my old code at this point :)

Ok! Got the UI for verifying users created, and it is tested and working. I've got some other ideas I'd like to implement for this, such as the ability for the admin to send an email to the user to ask for more info, along with allowing a new, unauthorized member to act as logged into view and edit their own account info, so that at least they can update their bio or email, etc.

Another item to add is the ability to enforce an email confirmation loop: user signs up, email confirmation link is sent, user must follow the link back to the site to confirm their signup. That way at least people haven't fatfingered their email address. But I'll start a new branch for that.

So, where is the email stuff? I tried poking around, but I'm unfamiliar with the ActionMailer conventions as yet.

There's a Mailer class that you can pile into. I prefer to keep all emailing stuff in there. Just give your stuff a descriptive name and you're fine. If you're looking to get an example of how the activation stuff might work, check out the restful_authentication plugin. I wouldn't mind having that integrated back into eldo, but failing that it's still worth checking out how they do activation. I don't think the state machine plugin is necessary, but it's still a good example.

So, I'm looking at Machinist (leaving off investigating the email confirmation/restful_auth/AASM stuff for now). Do you have it installed as a gem locally? It isn't in the vendor/plugin directory, and I'm wondering if that is intentional. Currently, some tests are throwing errors for me, and quite a lot of them are failing in various ways. This is by running rake test.

Still new to RoR's testing frameworks, so if there is some more preferable way to invoke the tests, I'm all ears :)

I thought I'd included it, but maybe I forgot... I'll check, but in the meantime, click the little ruby gem logo in the upper right of this page for instructions on how to install it: http://github.com/notahat/machinist/tree/master