4 ms·

People telling you to do the wrong thing is undoubtedly a large problem. For example, one of the things I don't like about the CakePHP framework is the advice y

People telling you to do the wrong thing is undoubtedly a large problem. For example, one of the things I don't like about the CakePHP framework is the advice you find when searching for seemingly simple questions, like how to use the database's current timestamp with Cake's ORM. You typically see one of two responses - either call one of your columns "modified" or "created" and hack it in like that. Or, use PHP's built-in date() function, ignoring the issues that brings (e.g. the current timezone could be anything - not always what the database is operating under). This is an ongoing problem, and is likely related to PHP's ease-of-use; for new users, it's easy to get a sense that you know more than you think you do, and give advice accordingly. The bigger problem is that it keeps building upon itself. People who don't know better, taking advice at face value, then giving that advice increases the number of people writing crap code. Try searching for password storing advice, and you'll see masses of varients of md5('salty_' . $password);

jere 14y ago
I think Jeff Atwood is singlehandedly responsible for that last one: http://www.codinghorror.com/blog/2007/09/rainbow-hash-cracking.html http://www.codinghorror.com/blog/2007/09/rainbow-hash-cracki... >hash = md5('deliciously-salty-' + password)
teresko 14y ago
Well .. if you are looking for high quality code, anywhere related to CakePHP is the wrong place.
- mootothemax 14y ago
  Well .. if you are looking for high quality code, anywhere related to CakePHP is the wrong place. Hehe, that's might be related to why I wrote one of the things and not the only thing ;-)
- oinksoft 14y ago
  What's with the CakePHP FUD the last couple days on HN?
josegonzalez 14y ago
A couple ways to do that date thing in CakePHP (ymmv and of course you may not like the options): - Use the db schema to enforce a value: "ON INSERT/UPDATE CURRENT_TIMESTAMP". Note that doing so will not allow you to simply set an arbitrary column to the current timestamp - Use the php `date()` function. Your server time should be UTC, your app time should be UTC, your datastore time should be UTC. Doing anything else is poor practice. And if you can't do this because your Sysadmin is stupid, fire him and get a new one. This is how the created/modified fields work. - Use created/modified fields. These obviously won't work if you want some random field to be the current time that isn't actually the created/modified field, but I cannot for the life of me think of such a use-case. - Use "DboSource::expression('NOW()');" as the value of the column. A little more verbose than just doing "NOW()", but at least it won't be interpreted as a string when saved by the "ORM". I think the biggest problem with PHP is developers not truly understanding the API they are using, and then writing spaghetti code that happens to work. Ease-of-use backfires, since your code actually works and you have no intention of learning to improve it. Also, I recommend doing "md5($salt) . $password" to hash passwords. Set $salt to 4, I guarantee that is a random number. ;)
- mootothemax 14y ago
  Use the php `date()` function. Your server time should be UTC, your app time should be UTC I think that this is advice that should never be given; it's too easy for someone else to change the timezone PHP uses somewhere else in the code. I agree that the servers should all be on UTC - and sync'd at that! - but it's unrealistic to hope that this will be the case in all instances; I've seen all kinds of weirdness from clients' codebases after taking their first steps off shared hosting / "my first VPS." Use "DboSource::expression('NOW()');" Basically, the only realistic option - and last time I searched (I admit, a while ago) really buried away ;) I think the biggest problem with PHP is developers not truly understanding the API they are using, and then writing spaghetti code that happens to work. Agree 100% with you. From some of the client code I've repaired, I've also stumbled over PHP developers apparently not understanding the very basics of programming, and crossing their fingers when it comes to running it ;)
oinksoft 14y ago
> either call one of your columns "modified" or "created" and hack it in like that. Hack it in like that? CakePHP is convention over configuration, and the framework manages "modified" and "created" for you which is pretty nice. Not something I expected somebody to complain about, but perhaps I'm misunderstanding the issue.

jere 14y ago

I think Jeff Atwood is singlehandedly responsible for that last one: http://www.codinghorror.com/blog/2007/09/rainbow-hash-cracking.html http://www.codinghorror.com/blog/2007/09/rainbow-hash-cracki... >hash = md5('deliciously-salty-' + password)

teresko 14y ago

Well .. if you are looking for high quality code, anywhere related to CakePHP is the wrong place.

mootothemax 14y ago
Well .. if you are looking for high quality code, anywhere related to CakePHP is the wrong place. Hehe, that's might be related to why I wrote one of the things and not the only thing ;-)
oinksoft 14y ago
What's with the CakePHP FUD the last couple days on HN?

josegonzalez 14y ago

A couple ways to do that date thing in CakePHP (ymmv and of course you may not like the options): - Use the db schema to enforce a value: "ON INSERT/UPDATE CURRENT_TIMESTAMP". Note that doing so will not allow you to simply set an arbitrary column to the current timestamp - Use the php `date()` function. Your server time should be UTC, your app time should be UTC, your datastore time should be UTC. Doing anything else is poor practice. And if you can't do this because your Sysadmin is stupid, fire him and get a new one. This is how the created/modified fields work. - Use created/modified fields. These obviously won't work if you want some random field to be the current time that isn't actually the created/modified field, but I cannot for the life of me think of such a use-case. - Use "DboSource::expression('NOW()');" as the value of the column. A little more verbose than just doing "NOW()", but at least it won't be interpreted as a string when saved by the "ORM". I think the biggest problem with PHP is developers not truly understanding the API they are using, and then writing spaghetti code that happens to work. Ease-of-use backfires, since your code actually works and you have no intention of learning to improve it. Also, I recommend doing "md5($salt) . $password" to hash passwords. Set $salt to 4, I guarantee that is a random number. ;)

mootothemax 14y ago
Use the php `date()` function. Your server time should be UTC, your app time should be UTC I think that this is advice that should never be given; it's too easy for someone else to change the timezone PHP uses somewhere else in the code. I agree that the servers should all be on UTC - and sync'd at that! - but it's unrealistic to hope that this will be the case in all instances; I've seen all kinds of weirdness from clients' codebases after taking their first steps off shared hosting / "my first VPS." Use "DboSource::expression('NOW()');" Basically, the only realistic option - and last time I searched (I admit, a while ago) really buried away ;) I think the biggest problem with PHP is developers not truly understanding the API they are using, and then writing spaghetti code that happens to work. Agree 100% with you. From some of the client code I've repaired, I've also stumbled over PHP developers apparently not understanding the very basics of programming, and crossing their fingers when it comes to running it ;)

oinksoft 14y ago

> either call one of your columns "modified" or "created" and hack it in like that. Hack it in like that? CakePHP is convention over configuration, and the framework manages "modified" and "created" for you which is pretty nice. Not something I expected somebody to complain about, but perhaps I'm misunderstanding the issue.