Disqus - Latest Comments for weierophinney

Re: mwop.net :: Goodbye Twitter

Matthew Weier O'Phinney — Tue, 29 Nov 2022 16:12:40 -0000

Yet another argument for me to remove comments entirely. 😠

Don't dump your garbage in someone else's house. You have no idea what circumstances led me to use Disqus, nor the effort it would take to migrate to another system. If you don't like Disqus, don't comment, and don't use them on your own site.

Re: mwop.net :: Goodbye Twitter

Matthew Weier O'Phinney — Tue, 29 Nov 2022 16:01:52 -0000

Good catch - thanks! Rectifying that now...

Re: phly, boy, phly :: TailwindCSS Tips

Matthew Weier O'Phinney — Wed, 15 Jun 2022 09:23:25 -0000

I wondered if you find a workaround for building and committing the assets when you need to regenerate them, but without worrying about accidentally pushing a dev build versus a production build ?

I did: I have .gitignore rules for the generated assets, and have a multi-stage Docker build that builds the production assets and copies them into the final container image.

Re: Running cronjobs via an Openswoole timer

Matthew Weier O'Phinney — Fri, 11 Feb 2022 13:23:47 -0000

Yeah, addProcess() functions similarly to pcntl, which is fine if you want to spin off another subprocess to run, say, a system command. But when the work I want done is built in to the PHP application, it makes more sense to do it within one of the server processes — i.e., a worker or a task worker.

When you add a tick inside a Swoole server, my understanding is that it gets processed inside one of the server workers — in the case of mezzio-swoole, that would be the Swoole HTTP Server, and one of its web workers. That means that if your process takes a long time, you're down a web worker for processing incoming requests. By dispatching to a task worker, I can ensure that no web workers are being consumed by a cron process.

Re: Managing Multiple PHP versions via the ondrej/php PPA

Matthew Weier O'Phinney — Thu, 16 Apr 2020 12:49:50 -0000

Thanks - fixed!

Re: From Zend Framework To The Laminas Project

Matthew Weier O'Phinney — Tue, 05 Nov 2019 09:55:30 -0000

We plan to launch the technical project by the end of November. :)

If you want more information, there's a webinar on the 21st: https://resources.roguewave...

Re: Registering Module-Specific Routes in Expressive

Matthew Weier O'Phinney — Fri, 25 Jan 2019 17:28:29 -0000

I wrote both that class and that documentation. ;-)

I've never really liked the configuration driven approach; it's very easy to introduce typos which then become difficult to debug. Add in the fact that it can be overwritten during config merging, sometimes with unexpected results (what happens when one config specifies an array and another a string for the middleware?), and you have a recipe for a difficult debug session. There's a reason why we've been recommending the programmatic approach.

Re: Registering Module-Specific Routes in Expressive

Matthew Weier O'Phinney — Fri, 25 Jan 2019 07:18:07 -0000

Because that method does not have access to the application instance; it's called before that instance has even been created.

Honestly, this could even just be a function; I used the ConfigProvider as it's where other configuration for the module already exists, which allowed me to keep it all in one place.

Re: Creating Exception types on-the-fly in modern PHP

Matthew Weier O'Phinney — Mon, 07 Jan 2019 15:40:54 -0000

I'm fine with opposing points of view, as long as we can acknowledge where each is valid. I totally get where you're coming from with exception handling; I also totally get where others disagree. But you've been intimating that the other point of view is patently invalid, based solely on your own experience, and constantly moving the goal posts in terms of how you define what is valid and what is not. That's what I'm arguing against.

Your last statement would have been sufficient: "I don’t believe exceptions or exception handling should be generalized," particularly if you'd opened with that and acknowledged that this view point may not be universal.

That said: it has pretty much zero to do with this particular post (other than the fact that I was creating a PSR-11-based exception type as an example), and I have no idea why you felt it necessary to beat that particular drum in the comment section of it.

Re: Creating Exception types on-the-fly in modern PHP

Matthew Weier O'Phinney — Mon, 07 Jan 2019 09:48:32 -0000

You're moving the goal posts, Rasmus. You asserted that you'd "never seen a single case where it made sense for an exception class to implement more than one of these interfaces. Have you?" I demonstrated I had, with examples. You then changed the argument, arguing about the specifics of the PSR-11 exception types, and asserted that my "concern seems to be about new types of exceptions being added in the future," an entirely different question — and one I also answered above, but you've now skipped over the answer entirely.

You don't like how something was done. That's fine. You don't have to. But please don't argue that everybody else's view point is incorrect; it's disrespectful and denies very real use cases.

Re: The Future of Zend Framework

Matthew Weier O'Phinney — Wed, 19 Dec 2018 10:51:52 -0000

Under a new organization (which could be a foundation), yes. RW retains the trademarks for Zend, so a rename is required.

Re: Creating Exception types on-the-fly in modern PHP

Matthew Weier O'Phinney — Thu, 13 Dec 2018 10:46:47 -0000

> I’ve never seen a single case where it made sense for an exception class
to implement more than one of these interfaces. Have you?

Yes, I have. Many times.

When a library that existed prior to a specification already exists, it generally has already defined its own exception types, and potentially, **AS I NOTED IN THE WRITE-UP ABOVE** its own package-level exception interfaces. This allows for both generalized and granular exception handling when required. When you then adopt a specification, you cannot simply throw the new exception types from the specification; users are already relying on the existing ones from the package.

By having these defined in the specification as interfaces, implementors can continue to throw the exceptions they have been all along, while having them implement the appropriate exception interfaces from the specification. They retain backwards compatibility while simultaneously fulfilling the specification.

Just because YOU have never had a need for it does not mean others have not. The reason they exist is because people indicated during the specification process that they had a need.

Re: The Future of Zend Framework

Matthew Weier O'Phinney — Tue, 23 Oct 2018 09:38:22 -0000

It will! Just likely under a different organization.

Re: The Future of Zend Framework

Matthew Weier O'Phinney — Tue, 23 Oct 2018 09:38:02 -0000

No - read above. We're looking for a new home for the project, whether that's a new foundation, or another company. The project will continue to live on.

Re: Async Expressive with Swoole

Matthew Weier O'Phinney — Wed, 17 Oct 2018 11:04:21 -0000

Yes, it does.

When you enable coroutine support, a large number of functions and classes immediately benefit. These include PDO and any TCP/UDP/websocket calls. As an example, I use predis in one site, and that uses TCP streams. As such, it immediately benefits from coroutine support. My understanding is that the Swoole team is working hard to expand this to all I/O.

With regards to the shared nothing architecture for which PHP is so well-known, Swoole has a number of protections. First, the architecture under which it works means that it has either a master + workers or a process manager + master + workers. In each case, when a fault occurs that would normally stop the engine (e.g., uncaught exception), that worker dies, and a new one is respawned. It also has an internal memory manager that will restart worker processes if the memory limit is hit. As such, it is quite resilient, and, better, requires little to no extra configuration by the user for these to "just work".

You DO need to be careful about aggregating state in your container services, however, as that can lead to problems with subsequent or concurrent requests. As such, we actually explicitly recommend writing your container services to be stateless, and provide some approaches to use if this is not possible: https://docs.zendframework....

I'd argue this is just a good development practice, though.

Re: Coddiwomple: Kadoka, SD -> Austin, MN

Matthew Weier O'Phinney — Sun, 26 Aug 2018 11:21:12 -0000

Great to see you, Kerri, even if only for a short bit!

Jen uses primarily alcohol ink and acrylics, though there's often a lot of other media in her art as well. She's got an online shop at https://jwo-designs.com

Re: PSR-7 By Example

Matthew Weier O'Phinney — Wed, 02 Aug 2017 15:57:00 -0000

zend-inputfilter doesn't yet understand PSR-7, only zend-http. We'll be working on its PSR-7 support in the coming weeks, however, as we're working on content validation middleware for Expressive.

Re: Using Monolog with Zend Service Manager — Nikola Poša - Blog

Matthew Weier O'Phinney — Wed, 14 Jun 2017 10:06:56 -0000

Great post!

I have two comments.

First: use `config`, not `Config` (notice the casing!) when referencing the configuration service. In zend-servicemanager v3, we stopped normalizing names, as it was confusing and sometimes led to incorrect or invalid lookups. When we did so, we updated zend-mvc to register the service as `config`; we chose the same convention for Expressive.

Second: I'd demonstrate how you would compose such a logger in other objects in your application. As you note, Monolog fulfills PSR-3, which means that your own code can typehint on that; your factories would then pull the relevant logger service and pass it in for the PSR-3 requirement.

Re: Programmatic Expressive

Matthew Weier O'Phinney — Tue, 04 Apr 2017 09:29:28 -0000

I just blogged on this subject on the ZF blog last week: https://framework.zend.com/...

Re: Using Anonymous Classes to Write Middleware

Matthew Weier O'Phinney — Tue, 04 Apr 2017 09:27:25 -0000

That's the plan. We already have decorator classes for callable double-pass as well as callable PSR-15 middleware, so developers can start migrating to use those, which will make their code forwards compatible. v3 will target the final PSR-15 specification, at which point `pipe()` will only accept the PSR-15 `MiddlewareInterface`.

Re: Using Anonymous Classes to Write Middleware

Matthew Weier O'Phinney — Tue, 04 Apr 2017 09:26:12 -0000

We actually have this capability already in Stratigility (`Zend\Stratigility\Middleware\CallableMiddlewareWrapper` for double-pass middleware and `Zend\Stratigility\Middleware\CallableInteropMiddlewareWrapper` for PSR-15 compatible middleware).

The benefit to using anonymous classes is twofold: performance (one method/function call — to `process()` vs `process()` + callback invocation), and debug capability (callstacks with composed callables are difficult, as you cannot easily identify _where_ in your code base they were defined).

Re: Using Anonymous Classes to Write Middleware

Matthew Weier O'Phinney — Fri, 31 Mar 2017 06:33:26 -0000

It doesn't need to be. Since the try block has a return statement, the only way the log statement is reached is if an exception is caught, by which point $e is in scope.

Re: Using the ZF2 EventManager

Matthew Weier O'Phinney — Wed, 22 Feb 2017 17:59:33 -0000

Please note that this post is SIX YEARS OLD. APIs have changed. Your best source is the official documentation: https://docs.zendframework.... and https://docs.zendframework....

Re: How To Do RAD Prototyping and Development With The ReflectionBasedAbstractFactory

Matthew Weier O'Phinney — Tue, 07 Feb 2017 11:21:16 -0000

One note: you can use the factory as either a factory for specific services, AND/OR as an abstract factory. In the latter case, you add additional performance overhead, as abstract factories are queried last, and the service manager has to loop over each until one indicates it can handle the service. Since this factory can handle any existing class, you should likely ensure it registers _last_ as a result.

The nice thing about it being an abstract factory is you can set it up early during prototyping, and map individual classes to it later. Coupled with the `generate-factory-for-class` tool you demonstrated in a previous blog post, you can create a _concrete_ factory for classes you managed previously with the _abstract_ factory very quickly once the service and its dependencies have stabilized. In other words: abstract factory -> generated factory gives you a development -> production pipeline, which is the goal of RAD tools.

Thanks for the write-up!

Re: PSR-7 By Example

Matthew Weier O'Phinney — Mon, 06 Feb 2017 15:42:03 -0000

Diactoros (https://github.com/zendfram... and on packagist as zendframework/zend-diactoros) provides a ServerRequestFactory that will marshal these values from superglobals, or from values passed to the factory.