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: http://pastebin.com/2qg4qJRh 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.kehn@xxxxxxxxx> wrote: > On May 20, 2011, at 4:41 AM, Tim Streater wrote: > > > On 20 May 2011 at 04:03, Alex Nikitin <niksoft@xxxxxxxxx> 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.kehn@xxxxxxxxx > http://joshuakehn.com > >
