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

Go with PHP

gowithphp.com

Post reply on HN
Print view View original

321–330 of 532 posts

Re: Go with PHP

#321

Post by Gigachad »

jjice wrote: post #273
Gigachad wrote: post #193

Earlier quoted context omitted.

Unit testing is a poor mans compiler. Our medium size rails app has 40,000 unit tests and constantly we have issues where an updated library changed the name or parameters of a method without warning causing breakages.

Yikes. Is there a static analysis tool for Ruby (along the lines of MyPy or PHP Stan) that could have caught this? Also, out of curiosity, are all of those tests hand written, or is there some generation in there?

All hand written over 10 years. They catch a lot of stuff, but stuff still slips through. Generally the area of the breakage even has tests over it but didn’t manage to catch the particular issue or they had mocked out parts which ended up being the issue.

I can’t see how static analysts could solve it really.

Re: Go with PHP

#322

Post by polyamid23 »

Gigachad wrote: post #195
Uptrenda wrote: post #54

Also: lets not forget one very important and under-rated side-effect of PHP -- it lets you write server-side code that can leverage a 'public' address. You might think 'well, doesn't everything let me do that?' Not quite. On 'free' VPS servers they usually have 'ephemeral' IPs or IPs that change. So while you get free bandwidth and compute -- it's hard to actually do anything useful with it like run a service if you…

Being able to host for free on dodgy free hosting is hardly a benefit anyone should care about.

Might be useful for teenagers / people with no disposable income to start trying web related stuff from a public library.

Re: Go with PHP

#323

Post by randshift »

o1y32 wrote: post #307

"500,000 orders per month" That's like, what, 12 orders per minute? Is this meant to be impressive or something? I bet any language run on a modern laptop can handle that.

I thought the same thing. PHP is a fine tool but that is not a value add statement. The code can "handle" anything, it's the underlying OS and related systems that limit the load.

Re: Go with PHP

#324

Post by hk1337 »

janmo wrote: post #38
nstart wrote: post #9

Earlier quoted context omitted.

Just made the same comment and deleted it seeing that you already stated it. Protecting against all of these is hard and no tech is going to automatically protect for all of this on its own. Such a weird statement to make that takes away from the message of the site entirely.

I worked for a company and we used the PHP ORM Propel. So in theory no SQL injections you would think, WRONG. We used a function like findOne() (I don't recall exactly). It looked like this: $resetTokens->findOne($GET['password-reset-token']); The issue was that findOne would accept wildcards, so one could use ?password-reset-token=% in the URL and reset the password of any random users.

In both Symfony and Laravel these days they have their own request objects to help you get information on the request. You shouldn’t be reaching into the get or post variables directly like that.

i.e. $request->query(‘password-reset-token’);

Re: Go with PHP

#325

Post by muglug »

jwdunne wrote: post #100
muglug wrote: post #58

Earlier quoted context omitted.

> To note, you'll need strict mode for type hints to be useful This is not really true — those type hints can be read by static analysis tools, preventing you from many of the issues that would also be caught in strict mode at runtime.

You’re right. Psalm has been a god send on the project I’m working on. Unfortunately, it’s taking far too long for Laravel to catch up so parts of its API are a black hole for types. Especially things like request input, which returns a union of string and array as opposed to using a conditional return type. You end up with assertion soup every time you touch Laravel so over time the project uses less and less of it.…

> Psalm has been a god send on the project I’m working on.

Thanks!

Re: Go with PHP

#326

Post by keen_poincare »

VWWHFSfQ wrote: post #304

That PHP code right there at the very top of the page that is supposed to be representative of how great it is has multiple TOCTOU authorization and validation bugs. In fact, nearly every piece of code on that entire page is riddled with transactional bugs

If you may, could you point out what are the TOCTOU bugs you have mentioned?

Re: Go with PHP

#327

Post by hk1337 »

cutler wrote: post #228
nstart wrote: post #9

Earlier quoted context omitted.

Just made the same comment and deleted it seeing that you already stated it. Protecting against all of these is hard and no tech is going to automatically protect for all of this on its own. Such a weird statement to make that takes away from the message of the site entirely.

Rails does a pretty good job.

PHP has come a long way and I have since changed my mind about Laravel but I love Ruby, and Rails does an awesome job. Laravel actually seems to try to mimick Rails in PHP

Re: Go with PHP

#328

Post by paledot »

o1y32 wrote: post #307

"500,000 orders per month" That's like, what, 12 orders per minute? Is this meant to be impressive or something? I bet any language run on a modern laptop can handle that.

Or smartphone.

Re: Go with PHP

#329

Post by EGreg »

stef25 wrote: post #241
EGreg wrote: post #128

Earlier quoted context omitted.

You seem to know what you’re talking about. I checked out payloadcms though, that site is pretty terrible…

Could do with some improvements, a template, maybe a CSS framework if you're not using one yet https://i.imgur.com/RYEo7Gv.png

I agree about the developer portal. Have you seen the other sections of the site? Start at the welcome page

Re: Go with PHP

#330

Post by njovin »

VWWHFSfQ wrote: post #304

That PHP code right there at the very top of the page that is supposed to be representative of how great it is has multiple TOCTOU authorization and validation bugs. In fact, nearly every piece of code on that entire page is riddled with transactional bugs

Do you mind elaborating? I can see how the user's ability to 'place-order' might be rejected between the access check and the order creation but that would be an extraordinary edge-case that does not need to be accounted for in 99% of applications.

If you're developing an application that needs to account for such an edge case you could easily do so with an insert w/ join method on the Order model. The author isn't trying to show that the code is bulletproof for every scenario.

Post reply on HN