Even MORE Scrum-esque

Scrum is an "agile" process for software development. Part of the Scrum methodology is The Scrum Meeting.

My team uses Scrum, but we do it even more scrum-esque

At first, we held daily meetings at a consistent time. The purpose of these short meetings were to:

  • Inform the team of your status

  • Help you organize and prioritize your tasks

  • Overcome issues. An issue is not a bug or problem. An example of an issue would be something like, “My ssh access to the QA server stopped working.”


When Scrum meetings work, it is like a well-oiled machine. You should be able to determine the project's status just by listening to everyone else.

Scrum meetings eliminate the cruft, and focuses on the important issues.

But, for my team, we needed to be even MORE Scrum. Meeting everyday was too tiresome, and boring. And, we often discussed other interesting topics, such as "Why Iron Eagle is such an awesome movie."

200px-Iron_eagle


So, we do our Scrum meetings like this:

  • No meetings.
  • Just email.


The emails look like this:

  • What you did yesterday
  • What you will accomplish today
  • Issues


The scrum email should answer the following:

  • Does it inform the team of your status?
  • Does it help you prioritize your tasks?
  • If you were doing the wrong thing, does it let others know that you are doing the wrong thing?


So far, it has been working out pretty well.

Posted at on 8/5/08 by | 0 comments | Filed under:

Mac Keyboard Shortcut: Bringing an Application back from a Minimized State

One of my life goals is to completely remove the mouse from my daily interfacing with my Mac.

Ok. So, you all know how to minimize an application window.

Command + M

So, how do you bring it back? Command + Tab does not work. That just puts the focus on the minimized application.

Use:

Command + Tab . . . to switch to the application you want. Then, before you let go of the Command key, press the Alt key, then let go of the Command key while keeping the Alt key down.

It is a little weird, and takes a bit to get used to it. But, once you do, it'll be like second nature.

Out.

Posted at on by | 4 comments | Filed under:

Can an ActiveRecord object destroy itself?

Without getting into real detail, I need this behavior because of a legacy database (Actually, it is not all that "legacy". It is more "enterprise-esque".).

Anyway . . .

Question: Can an ActiveRecord object invoke an instance method, then, while executing that method, destroy itself?

Code example:

@some_object.some_method

Class SomeObject < ActiveRecord::Base
def some_method
...Some really awesome stuff happens here...
self.destroy
end
end

At first, I thought it would work. There are plenty of times where I have invoked a destroy method on an AR object, then use that same AR object later. I do this in controller action methods often.

But, even as I was writing that logic, it did not feel correct. But, Ruby has a tendency to surprise me. So, I gave it a shot.

It turns out that you cannot do this. I am not sure if this is a Ruby or ActiveRecord behavior. If anyone knows, please comment.

To me, it seems like appropriate behavior.

You should not be able to start some set of tasks, one of which causes you to kill yourself, but requires you to finish off the rest of the tasks.

I accomplished the same behavior by creating another object within the instance method, and destroying that object.

Code Example:
@some_object.some_method

Class SomeObject < ActiveRecord::Base
def some_method
...Some really awesome stuff happens here...
SomeObject.find(self).destroy
end
end

Has anyone else come up against this? Am I solving this problem correctly?

Posted at on 8/1/08 by | 5 comments | Filed under: ,