I.NFECTIO.US comments

"Working with the PeoplePicker Data Values in SharePoint" by Zach Rosenfield

Tue, 30 Oct 2007 11:58:36 -0700

Great to see these cool PowerShell tricks for SharePoint being posted online (and thanks for adding the Dispose!).

"Deprecations in Rails 1.2" by Joe Ruby

Mon, 07 May 2007 16:28:48 -0700

It's a major pain in the ass trying to read the code in that box with its tiny horizontal scroll bar.

"Implement acts_as_threaded without a plugin" by Michael Carney

Tue, 27 Mar 2007 09:12:55 -0700

Sorry about the formattingg above. I couldn't figure out how to get paragraphs and code in. But the idea is to set lft=1, rgt=2, and depth=3 in the after_create callback at the same timee that you set root_id=id. Any thoughts are appreciated. Thanks.

"Implement acts_as_threaded without a plugin" by Michael Carney

Tue, 27 Mar 2007 08:33:27 -0700

I ran into a similar problem to Philip Tsai above where I was getting the first response to an item having a lft child with a value of zero. I followed his advice, but then ran into a different problem. If you have a post with no children and call children_count, you end up with a problem because of the NULL values for lft and rgt. I ended up with a different solution which I think feels better. I modified the original code from above as follows: [code] def after_create # Update the parent root_id with its id if self[:parent_id].to_i.zero? self[:root_id] = self[:id] self[:lft] = 1 self[:rgt] = 2 self[:depth] = 0 self.save else parent.add_child self end end [/code] The values of 1 or 2 are the default values that are assumed by nested_set if lft or rgt is NULL, but by setting them here all of the code works properly even if there are no children. For instance, calling all_children returns an empty array rather than barfing because of a poorly formed SQL query (with things like "(rgt )" because the value of rgt is NULL). This seems pretty bullet proof. Does anybody see any problems with it? Thanks.

"Macbook Battery Dead" by osric

Sun, 04 Mar 2007 07:05:43 -0800

so I went to a nearby Apple Store yesterday (Saturday) AM and ended up being the first to see a Genius. He tried out one of their batteries, booted into single user mode, checked inventory and gave me a new battery. Took all of ten minutes. I was pleasantly surprised -- my invoice was $0.

"Macbook Battery Dead" by osric

Fri, 02 Mar 2007 20:17:58 -0800

my battery just stopped being recognized this evening. just a black x on the battery indicator on the menu bar. this is a 1/11/06 vintage black macbook. kind of sad that its battery is already wasted.

"RAILS_ROOT and Dir.chdir" by jteam

Fri, 02 Mar 2007 02:18:45 -0800

I had the same problem - I was building a Ferret search index in a controller (I believe Ferret is doing Dir.chdir at some point) and afterwards ror couldn't compile/resolve the *.rhtml files anymore... My solution was to set the RAILS_ROOT in environment.rb. It does the job for now.

"ActiveRecord Calculations" by Eric

Thu, 01 Mar 2007 04:22:26 -0800

Hi! Is this still possible to use this patch with Rails 1.2?

"Defining Numericality" by PMc

Thu, 22 Feb 2007 15:07:16 -0800

There is some strangeness here:
1.
A not-equal operator is missing. I do not see the real sense in an equal operator - if there should be a predefined specific value for a field, then why open a field at all? But I see lot of sense in a non-equal operator, especially in each shopping system you do not want an item-count 0 entered.
2.
There is no longer checked against general numericality as soon as there is a comparison added. I do not see why an erroneous entry like maybe "19%0" should still be compared but not be detected as erroneous.
3.
If I request ":gte => 2.5" and enter 2.5, I still get an error. This is obvious from the code, as there is a conversion to_i done. I do not see why.
4.
As soon as one of the comparisons is used, the error message given by :message is no longer used, instead a static one from the plugin is used.
5.
I do not understand the code.

"Testing Gotchas in Rails" by matt

Thu, 22 Feb 2007 11:15:39 -0800

I most often run my tests seperatly, during development, so I experience this problem from the other direction. Loading up the fixtures returns the db to an expected state that tests depend on. What ends up happening when you forget to include the fixtures is that an earlier test will run, loading up the db and manipulating the records, then when it gets to the next test, the db isn't in expected state, so the test fails. Yea, first time, it was really confusing why individual tests passed, but the entire test suite failed.