:has_one, :idiot

So, I just learned the following:

:has_one

Specifies a one-to-one association with another class. This method should only be used if the other class contains the foreign key.

I had thought, erroneously, that when you created a :has_one relationship, that you also set :belongs_to on the associated object. This is often shown in examples – but it only works of you’ve set a foreign key field on both Models. I only had it on one, so my code kept breaking trying to access the associated model from the main model. So it comes down to whether you use :has_one or :belongs_to entirely depends on which one of them has the key. At least it’s working now.

Day 2: In which I start with the low hanging fruit

I have coffee, I’m ready to go. Here is the list:

  • appointment model
  • appointment controller
  • refactor appointment into event
  • appointment view for user, with basic CSS
  • expand user registration to handle business name
  • seed data for a few users/appointments/events
  • subdomain handling in dev, and on server
  • appointment view for anonymous patient
  • appointment lis for next two days on Center page
  • patient registration
  • logged in patient appointment scheduling
  • super-simple mailchimp template
  • mailchimp setup for confirmation email

Scopes (Not the Monkey Trial) in Rails 3

OK, bad pun. This is the life I lead.

Tonight was the first time I’ve gotten to use the Scopes feature in Rails. I’d heard about named_scopes a while back, but hadn’t gotten to a point where I needed one, so I didn’t really know how they worked, despite skimming a few articles on them.

I started with the Railscast on named_scope, which is a great intro, but I soon discovered that they’d changed the syntax in Rails 3. Fortunately I had enough of a grasp on it by then that I was able to change my code to the new style with the help of EdgeRails.info.

It was an easy change, and made my code much cleaner.

What I did was add a ‘today’ scope to the slot class, so that I can grab all slots for a given day like so:


scope :today, lambda {
dt = Date.today
where("slots.start_at >= ? AND slots.end_at
dt.beginning_of_day, dt.end_of_day)
}

I had to use a lambda in there so that the date code would evaluate when the scope was called, not when the class was first loaded. The syntactic sugar that Rails adds for date handling is wonderful, it makes the code quite a bit easier to read.

That’s it for tonight, I’ll hit the low hanging fruit on appointments in the morning.

Calendars in Rails, redux

I ended up making a few decisions. First, I figured out how to refactor the appointments and the events into a single Event class that contains many time Slot objects.

Because I didn’t need the day-spanning feature in event-calendar, I decided to kill it and go with a simpler solution based on the Railscasts code I mentioned previously. What that gives me is a nice bare Calendar framework that I can customize all I want without breaking any of the magic that may be hiding under the covers. I hate to end up in Not Invented Here territory, but I think in the end it’ll make me more agile if I really understand the calendaring code. I suspect a lot of my future work will be in that area.

So now I have a calendar grid displaying with time slots listed in it. I need to build a Day View for scheduling hour-by-hour. I also need to finish ripping out he appointment code and replacing it with the Event classes.

I updated to Rails 3.0.4 as well.

appointments

I’ve already created a system to handle ‘Events’ – the generic term for classes and seminars. I’m wonering whether the ‘Appointment’ model and controller are similar enough to the Events that I can use the same code for both. In order to maintain functionlality in the Event code, I’m going to keep them separate for now. It’s possible that as I work the Appointment design will deviate (or converge) from the Event design. In either case I can refactor later once I have working code.

Though I’m not doing TDD yet, I’m going to stick with a red-green-refactor kind of thing and not overthink it before I’ve written a line of code.

It Begins…

So, 7pm Friday night, I’m starting out. My list of tasks is this:

  • appointment model
  • appointment controller
  • appointment view for user, with basic CSS
  • expand user registration to handle business name
  • seed data for a few users/appointments/events
  • subdomain handling in dev, and on server
  • appointment view for anonymous patient
  • appointment lis for next two days on Center page
  • patient registration
  • logged in patient appointment scheduling
  • super-simple mailchimp template
  • mailchimp setup for confirmation email

I have no idea if I’ll get through all of these, or if I’ll need to find 10 more halfway through tomorrow. But I have Starbucks and Pizza to get me through.

Codathon 2011 Part 1: The Codening

I have a 3 day weekend coming up with President’s day. I figured that would be a good time to hit a turbo-boost on the coding for InnerLightTools. So my plan is to start @ 6pm Friday night. I’ll write as much, and sleep as little, as I can between then and Sunday @6pm. I’ll try to blog about it every few hours to fill people in on the progress. My next post will be a schedule of things to tackle over that weekend.

Inner Light Tools

I can agonize forever about when the site I’m building will be ready for public consumption, so I decided that it’s “good enough” now, and I should bite the bullet.

The project I’ve been working on since last spring is Inner Light Tools. A website to help massage therapists, reiki practitioners, and other alternative healers to manage their healing practice. It’s just a landing page right now. Users will be able to manage client information, arrange classes and post sign-up forms, let clients schedule their own appointments. All the good stuff.

I’ll be launching a blog over there for topics relevant to healing and running a healing business. I’ll be posting my technical and business info here, as ever.