So far I’ve got the recipe page with tabs to a users inventory. After writing this I’ll work on getting the tabs fleshed out more, I’m still not sure what elements it makes sense to navigate to. I keep having this internal debate that tabs should take you to content and not actions. For instance it should take you to your recipes but we should not have a tab to start a new recipe. I think I might add tabs for recipes, inventory and brews, and possibly the BJCP guidelines (If I choose to reproduce them here, still up in the air on that too). Each of those tabs will have the list you would expect, as well as action links for deleting, editing and adding / starting a new whatever.

Its funny how little time this took, about an hour but how productive it feels because it changed the way the site looks. In my day job I don’t ever see a user interface change for the work I do…. instant gratification is nice.

One gotcha I don’t particularly understand about Tabnav. Whenever I update what a tab links to, or the text in the tab I have to restart mongrel… what the heck? Not a huge deal but I wasted about 15 min figuring out why my changes wouldn’t take effect.

So I did some reading. The unit tests aren’t as decoupled as I would like them to be (yes Michael Feathers, you have made an impact in my life (his legacy code book is pretty good. I suggest it). I firmly believe that a unit test should not use a database or network. I think you can do that with the model well enough (by avoiding fixtures), but it looks next to impossible for controllers. From what I’ve read testing a controller makes http requests to the web server. I’m not a purist or anything, but its a bummer it has to do that. And I don’t think I can setup an in memory model object for a controller to work with (I’m probably wrong about that, I’d guess there’s some magic) I’d imagine for a full tests suite it would slow things down considerably. The other thing I’m not immediately seeing is a way to sense through a fixture. While not strictly necessary (and may in fact be more trouble than its worth) it sounds like a neat idea. All that said, it looks like the functional testing you can do with the unit test framework is pretty slick. I’m kicking around the idea of setting up some sort of nightly check out / test run just for kicks.

There has been a vanilla crisis in my house ( I think I get cookies!) I’m out.

def initialize(params = {}) #Not def initialize()
    super(params)
    ....
end

So anyway, users now compose inventories. Life is good for them. Still can’t enter recipies, because you know I got side tracked. But eh that’s how it goes.

I’ve got beer to rack & bottle (heff into bottles and racking a brown to secondaries) tomorrow night so I won’t get to work on the site for a day or two. When I get back to it I’ll finish up the recipe stuff and get it out there.

I’ve connected the user and the inventory object… I think for now I’ll leave it at that until I can get a model drawn up somewhere. Paper and pen maybe… lofi.

Anyway.. for as much as I can manage the site will be login free. My working idea is you will only need a login to use the inventory management, and if you want to save a brew session (there will be some sort of save as feature that exports it to a pdf or html too). Other than that the site will hopefully be login (and thus a slight irritation free).

Tonight I decided to start futzing with the authentication systems available for rails. I’m doing this first because it’s the part I’m least interested in… and in thoery if I get it over quickly I can move onto bigger and better things. After wading through documentation that appears to be out of date (this seems to be the status quo for most things rails) I settled on Acts as Authenticated.
I picked it for two reasons, the documentation appears to be reasonably accurate, and it looked easy. So far so good. I’ve got the mvc for it all generated and it looks like it does what it is supposed to do. I’m able to create an account.

So cheers to the Acts as Authenticated folks for making something I didn’t want to spend any time on a relatively quick and painless task. All in all it took about an hour.

Like I said above, its going to be a rails site. I started playing with Ruby about a year ago. I took a rails seminar at school (I’m working on my masters) and thought “eh, what the heck”. It will run of mysql and whatever webserver godaddy puts in front of it. If someone other than me ever uses this… well we will cross that bridge when we come to it.

I’ve been home brewing for about a year now and this seemed like a good idea. There are a lot of tools out there that do some, and possibly all of what I’m anticipating putting on Brew Sessions. I’m not saying those tools are bad (I use a few of em), but for the most part they don’t meet my needs. This is aimed primarily at making me happy, but if you have a feature request feel free to drop me a line (josh at brewmanager.com) and I’ll consider it.

Here’s the feature list in case I get rid of it.

• Inventory Managment
• Brew Session Managment (it does the math for mash calculations, AAU etc
• Recipe Managment (build, save and search)
• Groups/clubs, with all of the above