Posted by Doug
Thu, 29 Sep 2005 18:31:00 GMT
My partner and I are trying to implement the state changes of two people initiating a meeting and negotiating the time. Thanks to TDD we worked through it!
For a while we sat there talking about “what if”, “and then”, “but what about” trying to get our minds around the whole process. We had tried coding a couple of times only to whack half-baked ideas.
Finally I came to my senses, “Even if we don’t understand the whole process, we know what this simple case should look like.” I wrote a five line functional test, and went and hard-coded the controller to make it pass. Success! We made something work!
So Dave says, “OK, if that’s the way that should work, this case should look just like this,” and codes another test. We then go and hard-code an elsif clause for that test. Four tests later and some refactoring we had our logic working the way it should.
A couple things we experienced. First, we didn’t really know what to do but was able to code an ultra simple test. That was enough to get us moving in the right direction. Second, we didn’t have to code the final, elegant solution. We just hacked together something that would work for the simple test we had. It wasn’t until we had done that a couple times that we could effectively “triangulate” what the elegant solution should be.
Posted in Programming, Test Driven Development, Ruby on Rails | no comments
Posted by Doug
Tue, 27 Sep 2005 14:44:00 GMT
My client wants to coordinate scheduling meetings between members of her website. She has a definite flow she wants the invitations to go through. She even supplied a flow chart of the process!
I’ve been stumped for a few days how to model this. I can create the invitations, but wasn’t sure how to track the progress through the scheduling process. Between last night’s coding and this morning in the shower I think I’ve got something that will work.
I’ve been stuck on this for a few days. So last night I decided to try a different tact. Usually, I start from the data model and work my way to the view. Last night I worked in reverse.
Members will get the invitation by email with a link to the invitation to view and edit. So I decided to start with what I wanted that url to look like. That led me to a controller and new function. The logic for that function was pretty simple: if the user is the initiator, show one page; if the user is the recipient, show another. But wait, only certain times can a user edit the invitation. It depends on who’s waiting on who for a response. So if the invitation is waiting on the current user, show the edit page; otherwise just show the status page.
That led me to implement a Invitation#waiting_on?(user) method. I messed around with a couple implementations of this method I wasn’t really very happy with. I was trying to correlate the invitation’s status with the user and which states were valid for which user. Blech; too messy.
That’s when the idea hit me this morning. My assumption is that the invitation can only be modified by one party at a time. So, on the invitation, I’ll implement a modified_by attribute. Every time the invitation is saved, I’ll update that attribute. Then waiting_on? is just:
class Invitation
belongs_to :modified_by, :class => "User"
def waiting_on?(user)
return true if self.modified_by == user
return false
end
end
It was a nice switch tackling development from the view first. Well, I didn’t actually code the view. I just had in mind what I wanted the views to do and wrote the controller accordingly. The “problem” with View first development is I’m tempted more to develop without testing. Rails is very good for controller tests, but I haven’t really figured out how to do view testing.
I suppose if I’d been pairing I would have been better about writing functional tests to demostrate what I was trying to accomplish. That’s one good thing about pairing: it keeps you doing what you should be doing.
Posted in Programming | no comments
Posted by Doug
Sat, 17 Sep 2005 06:05:04 GMT
It’s been a pretty good couple of days for Rails coding. I’ve done a bunch of validation tweaks, mostly finished the calendar, and begun on group scheduling.
I was having problems using embedded hidden forms for all my edit and add links on events. I did a couple things to improve the performance of the page. First, I ditched the embedded forms and made them separate page loads. It was cool to have the embedded forms the magically appear and disappear; I miss it. Several people suggested I just embed a single edit form and a single add form and use Javascript to update the values before it’s submitted. If I were a Javascript stud that’s what I’d do. Maybe when I’m all grown up I’ll be smart enough to do that.
The other thing I did was change how I tested for events on calendar days. I had a find_by_day method that would basically find(:all).select { |expr| expr.occurs_on?(day) }. I’d then loop over the calendar days calling that function. What I decided to do instead was simply collect all the TimeExpressions into a single list in the controller and let the view do the select for each day. This exposes more of the model’s logic a little. I like the way the code looks to simply calll find_by_day for each day. However, only doing one find and then doing the selects in the view shaved a fair amount of time off the page load.
So I’m doing some “group scheduling” too. It’s quite limited. The TimeExpressions I’ve been working with is really to build a “free-busy” schedule of available times to book appointments. What I need to do is allow a user to invite another user to an appointment. These two users may have to negotiate an appointment time. So, it makes sense for my Invitations to acts_as_versioned. I had seen acts_as_versioned discussed a couple times on the maling list. Let me just say, I’m really happy with it. I was able to set it up without too much fuss. It works pretty much exactly as advertised. Thanks technoweenie!
Finally, to send out the initial invitations I finally got around to coding some AJAX stuff. It’s quite simple; just a link that makes a single request to send the invitation. I felt so sophisticated! Only about an hour or so to get it studied, written, tested and committed.
Posted in Programming, Ruby on Rails | Tags AJAX, Calendars, Rails, Ruby | no comments
