Posted by Doug
Mon, 03 Oct 2005 23:48:00 GMT
More evidence that nothing is more permanent than a temporary solution: I’ve hacked purchasing photos from Shutterfly into my gallery.
I know I’m supposed to be replacing my gallery with something new and Railsy, but it was much easier to add this into my existing site. It simply adds an “order” button on the bottom of every photo page. Clicking the button uses Shutterfly’s C4P API to add the image to a shopping cart.
It’s not that I’m necessarily endorsing Shutterfly as the best online photo “lab”, but they happen to be the one with the easiest API to code into my site. I just didn’t want to go through the pain of adding all my photos to some other gallery just so that I could get them printed. And no, $0.29/4×6 isn’t the greatest deal. Again, this is the simplest way I could get prints. In the end, that’s my biggest goal right now.
Posted in Programming, Photography | no comments
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
