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

51–60 of 117 posts

Re: PHP Commandments

#51

Post by rmrfrmrf »

tabbyjabby wrote: post #42
rmrfrmrf wrote: post #40

Earlier quoted context omitted.

Helper files are a pain in the ass because they're usually all jumbled up and hard to maintain. In my experience with them, they come a zillion functions that are all unrelated, from input sanitization to XML processing to database initialization. Then, when you need to figure out what the hell is going on in your code, you have to wade through a forest of garbage just to figure out what the function is doing. God fo…

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.

Re: PHP Commandments

#52

Post by pilif »

> 7. NEVER send emails directly from web page code Sending emails is slow. Incredibly slow. Don't tie up a precious web front-end process with doing so. Use a message queue instead.

Well. MTAs are message queues. Why use a third party software speaking a third-party protocol, adding more complexity only to eventually be talking SMTP anyways. As such, my message queue is a locally installed MTA listening on port 587, talking SMTP.

This is as fast or faster than any message queuing system you can come up with, but as it's managed by the OS, it's bound to work much better than third-party solutions.

I also get a lot for free in exchange. Stuff like automatic resending, queueing, queue management and so on.

As such, I would not strictly agree with point 7 in the article. Sure - don't send mail by talking to a remote MTA, but if it's running inside of your local network, using any other queuing system provides nothing but overhead.

Furthermore:

>How do you set up Nginx so that it won't die or kill your server when you receive a big burst of traffic? You install it.

No. You are shifting the burden of correct app server configuration from apache to php-fpm or whatever other process manager you're using.

In the end it doesn't matter much whether you're down completely (misconfigured apache) or still somewhat capable of serving static files while unable to serve any dynamic pages (misconfigured php-fpm).

Re: PHP Commandments

#53

Post by ledneb »

aarondf wrote: post #16

Can someone help me understand why a "helpers" or "utilities" file of functions is so bad? Asking humbly because I do that and don't yet understand why it's bad / the alternative.

Since you can't autoload functions who aren't members of a class, you must include/require the file on every request, or otherwise include the file whenever you use those methods. PHP projects have, generally, abstracted the thinking about "what file does this thing come from?" by now - via the autoloader - which, as I said, doesn't work with functions. So functions, annoyingly, create a leak in the abstraction that otherwise allows us to forget about exactly what files our code lives in.

As an aside, to me, it also raises questions regarding the design of your code (how do I inject mock methods?). But that's hard to know without seeing it (if the methods are simple enough, perhaps there's just no need to mock them in your tests).

I encapsulate "helper" or "utility" logic in objects, e.g. RandomGenerator with a getRandom, which can be amazing when it comes to testing, and lets me forget about include/require'ing files.

Re: PHP Commandments

#55

Post by jcampbell1 »

UnoriginalGuy wrote: post #50
jcampbell1 wrote: post #44

Earlier quoted context omitted.

I am totally confused. Who uses an SMTP server written in PHP? mail() just writes a bit of stuff into a mail queue by default.

People set their PHP config to connect to a remote SMTP server rather than a local queue. It isn't something you can control in the code.

Thanks, I understand. Configuring PHP that way would be an unmitigated disaster. If you want that functionality, it makes the most sense to configure Exim or whatever to do that for you.

Re: PHP Commandments

#56

Post by heidar »

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 request for the unless control structure: https://bugs.php.net/bug.php?id=40296

Re: PHP Commandments

#57

Post by jcampbell1 »

ineedtosleep wrote: post #32
jcampbell1 wrote: post #13

Is sending email really that slow? In my experience, it just writes something to a local mail queue if your front ends can send email.

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.

Re: PHP Commandments

#58

Post by Shorel »

tabbyjabby wrote: post #42
rmrfrmrf wrote: post #40

Earlier quoted context omitted.

Helper files are a pain in the ass because they're usually all jumbled up and hard to maintain. In my experience with them, they come a zillion functions that are all unrelated, from input sanitization to XML processing to database initialization. Then, when you need to figure out what the hell is going on in your code, you have to wade through a forest of garbage just to figure out what the function is doing. God fo…

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.

Re: PHP Commandments

#59

Post by yogo »

tabbyjabby wrote: post #42
rmrfrmrf wrote: post #40

Earlier quoted context omitted.

Helper files are a pain in the ass because they're usually all jumbled up and hard to maintain. In my experience with them, they come a zillion functions that are all unrelated, from input sanitization to XML processing to database initialization. Then, when you need to figure out what the hell is going on in your code, you have to wade through a forest of garbage just to figure out what the function is doing. God fo…

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.

This is a problem that goes all the way to the core. It isn't very good OO (some will argue PHP isn't really OO anyway) because core types are not objects. Whether you have substr(..., ...), Helper::substr(..., ...) or getSomeInstance()->substr(..., ...) it's really all the same, with maybe some added benefits if you provide some wrapper functionality as in the last case.

Re: PHP Commandments

#60

Post by WA »

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?

I agree. Also, 8. (no helper functions) contradicts 1. (do the simplest thing).
Post reply on HN