Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP Commandments

biasedphp.com

Post reply on HN
Print view View original

81–90 of 117 posts

Re: PHP Commandments

#81

Post by heidar »

ihsw wrote: post #68
heidar wrote: post #56

Earlier quoted context omitted.

The "cool kids" in PHP are using Laravel 4. It's a well made framework. I'm doing a REST API in it at work and the lack of mind share and docs is probably the worst part about it (it's still in beta to be fair). Most of the time I ended up reading the framework code. PHP leaves a lot to be desired though. It boggles my mind how developers who love what they do have the patience to stick with it. Example: Feature requ…

I'm curious, why did you choose Laravel over Symfony?

We used Symfony 2 on projects previously. I find that it makes simple things hard to do and it is too verbose.

Laravel 4 uses many of the Symfony 2 components but makes nice facades that you can call as static methods so you never have to worry about namespace importing and it makes things a lot less verbose and easy to use.

Re: PHP Commandments

#82

Post by kijin »

grobolom wrote: post #26
bru wrote: post #14

Earlier quoted context omitted.

>Where would something like this fit, if not a general helpers.php type file? In debugging.php alongside with other debugging helpers?

Maybe if it's used solely for debugging, but there are cases where simple functions aren't easy to place. Consider implementing the array_column function for pre-5.4 PHP. Or things like method pull, index grouping, or array_select_keys functions. What helper library should a function like the following exist in? function array_select_keys(array $dict, array $keys) { $result = array(); foreach ($keys as $key) { if (ar…

I have a similar dilemma with some of my helper functions. For example, I have starts_with(), ends_with(), and contains() for super easy string comparisons, is_between() for numerical comparisons, and custom implementations for a few built-in functions such as hex2bin() that don't exist in older versions. These are so general in scope that it would be awkward to place them in their own \Namespace\Class.

Re: PHP Commandments

#83

Post by z92 »

rmrfrmrf wrote: post #51
tabbyjabby wrote: post #42

Earlier quoted context omitted.

I'd just like to note that that is not a particularly OO solution. You've essentially created a namespaced function. While this is still preferable to a bare function in a heterogenous helpers function file, it's certainly not a pure OO way of accomplishing the encapsulation of the InputSanitizer.

$username = InputSanitizer::getInstance()->getPostData('username'); There. Now it's OO ;P.

I would rather use Java in that case.

Re: PHP Commandments

#84

Post by krapp »

heidar wrote: post #78
krapp wrote: post #72

Earlier quoted context omitted.

Is anyone using Laravel 4 in production already? I thought it was still in beta.... I'm still messing with 3.

I've seen a few people doing it. The API is quite stable since the end of last year or so I've heard. I didn't start using it until recently and I haven't encountered any bugs and whenever I gear up to do a pull request someone else has already done it.

ooh, neat. I'll have to start on that then.

Re: PHP Commandments

#85

Post by hdctambien »

Shorel wrote: post #76
eru wrote: post #71

Earlier quoted context omitted.

tabbyjabby didn't say it's bad. They just said it's not OO.

I know. It implies the assumption that not complying with OO is something code should avoid as a rule of thumb. I'm the one saying that strict OO is bad because it's verbose and its slower than the alternative.

I think it more implies that object oriented things should be called OO and not-object-oriented things should be called something that isn't OO.

Re: PHP Commandments

#86

Post by smacktoward »

potatolicious wrote: post #43
jcampbell1 wrote: post #17

Earlier quoted context omitted.

You should install xdebug, and then var_dump will do what you want and a lot more.

Isn't that just letting someone else write your helpers.php?

No, it's moving debugging into a discrete, well-understood debugging package (Xdebug) rather than jumbling it together with a bunch of unrelated stuff in a big grab bag labeled "Miscellaneous".

Re: PHP Commandments

#87

Post by smacktoward »

Jleagle wrote: post #19

Wow, this guy really hates CakePHP. If you know what you're doing and don't just presume Cake has done it for you, none of those problems should exist.

I have no brief for or against Cake (never used it myself), but input filtering seems like exactly the sort of tedious-but-necessary infrastructure code that a good framework is supposed to let you avoid having to write from scratch for each new project. If Cake doesn't do that, I don't think it's unreasonable to count that as a strike against it.

Re: PHP Commandments

#88

Post by alan_cx »

martin_ wrote: post #54

The comments pretty much sum up how useful this blog post is... The upvotes merely show how educated a lot of the PHP community isn't

Or just up front and honest. Which leads to open discussion. Which improves things. Maybe...

Re: PHP Commandments

#89

Post by Dylan16807 »

Joeri wrote: post #80
Dylan16807 wrote: post #69

Earlier quoted context omitted.

MD5 for password storage isn't broken. It's still incomparably better than encrypting passwords. The problem is that it requires you to have a very strong password to start out with. This is 'acceptable' in that the security works with MD5, but 'unacceptable' in that it makes security much harder than it should be for no benefit. And it has always been this way, regardless of what people have thought about it in the…

Hashcat can do 5 billion md5 hashes per second on a single gpu. Even difficult passwords are crackable in md5.

Adding six lowercase characters/numbers increases the difficulty by a factor of a billion. So if you look at a typical 8 character rule and go up to 14 random characters you're perfectly safe on md5.

Re: PHP Commandments

#90

Post by UnoriginalGuy »

chacham15 wrote: post #64
UnoriginalGuy wrote: post #45

> NEVER hash passwords with MD5/SHA-1/Hash-of-the-day > PHPass will make life easy for yourself and keep your users' passwords secure. MD5/3DES/SHA-1 are relatively broken. But saying "use this magical library" is really far from a solution. Who's to say that that library won't be broken tomorrow and then someone else won't write an article next week saying "don't use PHPass!" Programmers just need to stay up-to-date…

No. >MD5 was very much acceptable for the longest time. MD5 was never a good password hash. Neither is SHA1,256,etc. The reason is that they are crypto hashes optimized for speed. This is bad for passwords. What you should be using is the opposite: an expensive hash to compute. This is bcrypt which has been in use since 1999 (and what the PHPass is based on). This is a clear example of "Dont do your own crypto" becau…

> MD5 was never a good password hash. Neither is SHA1,256,etc. The reason is that they are crypto hashes optimized for speed.

That's strange to hear you say that, because I remember people having huge arguments in the 1990s about how they couldn't use MD5 because it was /so/ slow and how 3DES was the only way to go!

I swear people love to re-write history.

> This is a clear example of "Dont do your own crypto" because you dont know all the details.

That doesn't even make any sense. MD5 is a standard cryptographic function. If someone had used it they wouldn't be making their own crypto.

Hell, many of the standard libraries implemented MD5 when you asked them to protect a password by default. That's so far from rolling your own it isn't even logical to try and make the argument you're making.

Your entire post reads like someone who knows nothing about the history and is just spouting "OMG USE bcrypt IT IS THE BESTEST AND WILL BE SECURE FOREVER!"

bcrypt too will fall from grace and then you'll have someone making a post like yours saying "how could anyone use bcrypt, it is SOOO fast!"

Post reply on HN