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

71–80 of 117 posts

Re: PHP Commandments

#71

Post by eru »

Shorel wrote: post #58
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.

And very fortunately so. 'Pure' OO is the madness that created Java. Encapsulation is overrated. So overrated that you need another fancy concept like 'dependency injection' when it just gets in the way. The static function is simple and because of that, it is good.

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

Re: PHP Commandments

#72

Post by krapp »

heidar wrote: post #56
adamors wrote: post #12

Are people still using PHP without frameworks these days?

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…

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

Re: PHP Commandments

#73

Post by ineedtosleep »

jcampbell1 wrote: post #57
ineedtosleep wrote: post #32

Earlier quoted context omitted.

Yes it's slow in that it's a blocking call. Since it takes more than a fraction of a second put a message in the mail queue, it'll _feel_ slow.

I am trying to verify your claim: php -r '$s = microtime(1);mail("jcampbell1@gmail.com","test","text");printf("%d\n ms",(microtime(1)-$s)*1000);' > 20 ms 20 ms doesn't _feel_ slow. You spend far more time fetching the data and rendering the email.

Just realized I edited out (before I posted) my qualifcation for my statement, but it should've been prefaced as "from what I've noticed with no hard numbers."

The reason I assume that it has the feeling of being slow, from the applications I've had to clean up, is because many times there's processing happening right before the mail() function. So while, yes, its relatively fast the the total time is what feels slow.

And for comparison I've ran your commandline test as well with two of my cheap-o VPS instances, one of which is a Linode instance:

Linode: 50ms, 13ms, 14ms

Crappier VPS: 677ms, 149ms, 188ms

Re: PHP Commandments

#74

Post by EvilTerran »

daniloassis wrote: post #8

I would add the following: General tips: * Understand how HTTP works (sounds trivial for a PHP developer, but at least here in Brazil, a huge portion doesn't do) * ALWAYS keep php.ini with production settings and replicate the same into your development environment (Vagrant is a great option here) * ALWAYS keep Apache or Nginx configs in sync among every environment * NEVER trust $_SERVER['REMOTE_ADDR'] to get client…

Don't use $_POST and $_GET globals directly

May I ask why not?

Re: PHP Commandments

#75

Post by eru »

heidar wrote: post #56
adamors wrote: post #12

Are people still using PHP without frameworks these days?

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…

Just to be smug: In Haskell and Lisp you can add those control structures yourself in your source code (without having to hack up the compiler).

(Haskell even does it as a function, and not as a macro.)

Re: PHP Commandments

#76

Post by Shorel »

eru wrote: post #71
Shorel wrote: post #58

Earlier quoted context omitted.

And very fortunately so. 'Pure' OO is the madness that created Java. Encapsulation is overrated. So overrated that you need another fancy concept like 'dependency injection' when it just gets in the way. The static function is simple and because of that, it is good.

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.

Re: PHP Commandments

#77

Post by kijin »

Piskvorrr wrote: post #2

As for #6, I'd go as far as "NEVER use include, period." I've seen about 1 actual use case out of the bazillions out there; almost certainly, require() is the droid you're looking for. I'd also add a #10: Use E_ALL | E_STRICT , and don't ignore it. PHP is trying to tell you of many problems, shutting it up is not the right answer.

Even better, set error reporting to -1. This will catch every error, even if PHP devs decide to add a new type of error that isn't included in E_ALL | E_STRICT. (They already made E_STRICT not part of E_ALL, so there's no guarantee they won't do it again.)

The reason this works is because -1 is 0xFFFFFFFF.

Re: PHP Commandments

#78

Post by heidar »

krapp wrote: post #72
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…

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.

Re: PHP Commandments

#79

Post by krapp »

EvilTerran wrote: post #74
daniloassis wrote: post #8

I would add the following: General tips: * Understand how HTTP works (sounds trivial for a PHP developer, but at least here in Brazil, a huge portion doesn't do) * ALWAYS keep php.ini with production settings and replicate the same into your development environment (Vagrant is a great option here) * ALWAYS keep Apache or Nginx configs in sync among every environment * NEVER trust $_SERVER['REMOTE_ADDR'] to get client…

Don't use $_POST and $_GET globals directly May I ask why not?

If they aren't sanitized or validated they can generate exceptions or contain malicious data which leads to XSS or SQL injection after they've been reflected back to the user or added to a database. Since the values in these arrays come from the user, they should always be considered actively hostile and treated as such.

Re: PHP Commandments

#80

Post by Joeri »

Dylan16807 wrote: post #69
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…

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.
Post reply on HN