Absolutely agree with logging function or class (i ofcourse prefer the
latter) for persistent logging that is to be present in the end product;
however its is not the best of ideas to spend time developing logging code
and using it for debug purposes that will only be used during  the initial
development cycle of the said code. I can define debug just before or in the
beginning of a method or class, say one that i suspect is using up too much
memory, and throw a couple of these debug lines in there to avoid further
obfuscating code. Needless to say that there is only one line to remove
before publishing that code to production, say i do this 15 times in a block
of code, the "oh this is much more clean" version would mean that i would
have to go back through and remove 60 lines of code, and I, for one, am lazy
and dont like to do extra work.

I never said it was a good coding practice to use this kind of logic, infact
the "if" is on average about 20% faster, so i would recommend an inline if,
all i said is that it reads much quicker and cleaner, that said i would
normally write it as: if(DEBUG) ... Works just as well, actually better, i
just like to improvise, figure out new ways to do something, that kind of
spans my approach to thinking about programming in general, but i wont go
into that as i doubt its interesting to anyone, and certainly to some
extent, i like to confuse people with crazy code so that they dont stare
over my shoulder, especially code that i know i am going to remove. Oh and
in terms of performance, a callout to a function is about 40% slower then my
crazy code, and about 75% slower then an if check. Calling out to a logging
class is about 2 times slower then my logic, and almost 3 times slower then
an if.

Actually i accidentally left the debugs spanning from tracing through memory
use issues in someone else's code *caugh*PHPExcel*/caugh* in my class linked
above, so Adam (and/or others if you were looking at it) new pastebin link:

Also to tedd, i would say that you should make it a series of tutorials of
how to make simple user auth progressively more and more secure, i would say
that would be a good learning experience for someone. Start with your basic
code, introduce new concepts that will teach novice a little bit more about
how the internet works, how sessions work, how it can all be exploited
conceptually, and introduce ways to fix those issues with progressively more
hardened code...? I think that that would be a great way of learning for a
novice, i would say maybe 3 more tutorials, each progressively more secure;
suggesting next one to introduce hashing, cleaning the code, and some of the
initial concepts outlined above, then a system setup for https, going over
tls renegotiation, setting up rewriting rules, etc, and changing the code
with securing the session code and introducing login limits, and finally
perhaps how to take make all of this system a bit more web 2.0 with jquery,
ajax, and perhaps use that as the introduction of the next set of tuts of
how to do this same thing with a database back end with references back to
this auth system? I would have certainly liked to read a tutorial like that
when i was starting out... And, i'm up to help, i'm sure others as well
would not mind chiming in their $.02 :)

P.S. I like to play around with programming concepts, actually just gave up
of playing with a radix sort implementation in PHP, that deals with both
positive and negative numbers as well as floats, which are a pain in the
butt in php when you are dealing with binary operations, amongst other
things i had to write my own dec2bin that deals with float. It's mostly
working, still a couple of quirks that would need to be fixed, but its slow
in PHP as opposed to C++, where it can be many times faster then
library-provided sorting functions, so it's not really worth any more of my
time, but it was kind of fun to figure out how to do all of that, especially
converting signed ints and floats to positive ints and back :)

-- Alex --
The trouble with programmers is that you can never tell what a programmer is
doing until it’s too late.  ~Seymour Cray

On Fri, May 20, 2011 at 9:14 AM, Joshua Kehn <josh.k...@gmail.com> wrote:

> On May 20, 2011, at 4:41 AM, Tim Streater wrote:
> > On 20 May 2011 at 04:03, Alex Nikitin <niks...@gmail.com> wrote:
> >
> >> but here is a brief example:
> >>
> >> (!DEBUG) || error_log("Fetch Data: ".memory_get_usage()/1048576);
> >>
> >> reads and writes a lot better and faster then:
> >>
> >> if(DEBUG) {
> >>   $memory = memory_get_usage()/1048576;
> >>   error_log("Fetch Data: ".$memory);
> >> }
> >
> > Not to me it doesn't. I find such usage incomprehensible.
> >
> > tim
> I understand what you're doing, and I think it's a bad shortcut to be
> taking. Make a dedicated class for logging and handle all this there.
> Regards,
> -Josh
> ____________________________________
> Joshua Kehn | josh.k...@gmail.com
> http://joshuakehn.com

Reply via email to