FYI: Not sure if the author will see this but some spelling mistakes in the article. [0] E.g. s/reslease/release/
Thanks, I saw it :)
HN user
FYI: Not sure if the author will see this but some spelling mistakes in the article. [0] E.g. s/reslease/release/
Thanks, I saw it :)
I know you're trolling, but FYI the `static` before function has nothing to do with the `static` return type. Like other programming languages the term `static` is used to denote two things.
WP recently said they'll support 5.6 for an unknown amount of time. So not soon
Still no support for my audio interface over USB… You can add it, but no signal comes true. I know about virtual audio routing, but I'm so sad this bug hasn't been fixed after years…
solely on the The Pulfrich effect
Did you read the whole post? There's
- The Pulfrich effect
- The way human eyes are built
- The case of astigmatism
- Studies targeted towards computer screen use
'What am I becoming?' rather than 'What am I getting?'
That's a great insight. Thanks for sharing!
Hope you're in a better place now!
Is it really a question of whose responsibility it is though? If you're feeling stuck, it's your right to find ways getting unstuck. If that means changing jobs, who can blame you?
Unless you're a manager at your company it's not your responsibility to fix it.
There definitely are stages before being stuck. I worked for three and a half years in that company, and only felt stuck for the last year.
I went to all three stages you describe, feels very familiar.
I feel like company's like that are shooting themselves in the foot: the delivered product is of lesser quality, developers aren't happy and quit sooner or later.
Looking at it from a manager's perspective, I think you'd want to do everything in your power to prevent such situations. Feels like there's a general lack of future perspective in many companies.
The only benchmarks done before adding it to the core were on maths-heavy code samples, something PHP is seldom used for.
You can read about it here: https://stitcher.io/blog/php-jit
Woops, forgot to remove that last line; thanks for pointing it out!
The only benchmark I know of testing async PHP was flawed big time and was debunked a few days later.
Some background information about the JIT in PHP: it was clear from the start that it wouldn't affect classic web applications all that much, since there's not a lot of "hot code" to be found over there, especially since by default PHP doesn't use any long running processes to handle requests.
There are some benchmarks out there that claim the JIT has an immense impact on PHP performance, but these only measure specific code samples in isolation. The JIT _can_ open doors for PHP to venture into new areas of programming, but we shouldn't expect it to significantly impact our day-to-day web programming.
Thanks, that's good feedback! I also added a section just now explaining how MBTI is just an example to discover how we differ from each other, not as a way of telling you who you really are.
It makes diffs easier to read, and ensures you never forget to add one of you'd add a new line to the parameter list.
It's the standard release cycle of PHP: https://www.php.net/supported-versions.php
6. Maybe PHP Doesn’t Suck
Being a PHP programmer, I can concur: https://stitcher.io/blog/php-in-2020
I share the same doubts…
Everything starts with trust, of course. We've proven ourselves in several large projects and within our open source community before. The client knows that.
There's never any estimate of "so much hours will be spent in total on this research", we just honestly communicate with the client along the way, and they give us their trust.
Whether we can keep that trust is up to us.
Believe me: a whole new world will open once you've discovered it.
It took several hours of individual research, watching talks, reading blog posts; and took several pair-programming sessions of several hours over the span of four weeks to come up with a solution we liked.
We informed our client that this was a new area for us and that we didn't have hands-on experience with, but that we believed it would be beneficial to spend time to explore it, as it would be an elegant solution to several of their business problems. They agreed and we kept them in the loop with weekly meetings.
We're now in the phase of actually implementing real-life processes, the project will probably be in active development for another year or two.
I think that the biggest win with this feature, is not that PHP will do more runtime type checks, but that the syntax is valid.
The past years we've seen several static analysers become more and more popular in the PHP community. Tools like phpstan (https://github.com/phpstan/phpstan) and psalm by Vimeo (https://github.com/vimeo/psalm).
Allowing this syntax is a great way to write cleaner code that can be statically analysed, which is far more superior than the runtime type checker.
A complete list of new features, changes and deprecations can be found here: https://stitcher.io/blog/new-in-php-74
I appreciate you sharing this. The goal of my post was not to convince people to "switch to PHP right now", but rather to tell them you can do pretty cool things with it, and that it's actually fun to work in.
For what it's worth, here's the source code of one of my personal side projects, written in PHP and Laravel: https://github.com/brendt/aggregate.stitcher.io
its defenders should focus on actually showing what modern PHP code looks like
This is one of my personal side projects, written in PHP and Laravel: https://github.com/brendt/aggregate.stitcher.io
Here's a list of all OSS package we maintain at work: https://github.com/spatie
You're absolutely right. I think it's fair to say that I was closing in on a burnout, which made me think irrational.
Like I said: I was lucky being able to switch jobs, and re-discover my passion for programming