NYCPHP Meetup

NYPHP.org

[nycphp-talk] Module Organization ideas...

Tom Melendez tom at supertom.com
Tue Aug 26 11:05:46 EDT 2008


Hi Mike,

> I have noticed that one or both of the conditionals that write the IP
> and email address will occasionally write a blank record to the
> database but when I check the email report I send to myself, it contains
> both records?
Can you log the actual query that is sent to the database?  Is is
valid, meaning, if you run it by hand does it populate those fields
correctly?  Are they really blank or are there spaces or non-printable
characters in the query?

> From what I have read about object coding, this seems like it might be
> a candidate for a class structure but I don't know object coding that
> well to sort it out. I feel like what I have now is an "orderly mess"
> and would like to restructure the module to make it easier to debug
> and more efficient to execute.

It does sound like you could reorg this into one or more classes, but
neither is a guarantee of "easier debugging" or "efficient execution".
 On the contrary, I would bet you'll end up refactoring quite a bit of
it to achieve that.  However, with those goals in mind at the start
you will ultimately get what you want.  Don't forget the reuse aspect
as well.

>
> Given the ideas presented, I would appreciate any feedback. Given that
> I have not provided any coding examples, I am only looking for ideas
> on how to reorganize this module. BTW, if you haven't guessed it, this
> is a bad guy trap code so posting the code has a risk that the bad guy
> will see the code and adjust his robot code to circumvent my code
> which has a 100% success rate currently even with the annoying
> database write bug that I am chasing.

Well, congrats on your success rate, but, what you describe is
"security through obscurity", my friend.  When moving towards your OO
version of this, you may want to reconsider your algorithm/checks so
it depends less on "I know something you don't" and more on "I know
you are doing something bad because...".

Tom
http://www.liphp.org



More information about the talk mailing list