Thursday, November 12, 2015
Second have a project-specific php-cs config file. As an example take a look here.
In PHPStorm click "File" -> "Settings" -> "Tools" -> "File Watchers"
Fill out the provided view:
Name: PHP CS Fixer
Description: fixes php code style
Show console: Error
File type: PHP
Scope: Project Files
Arguments: --config-file=$ProjectFileDir$/.php_cs fix $FileDir$/$FileName$ -v --diff --dry-run
Working directory: $ProjectFileDir$
It should look like this:
Hint: You can also ommit the --dry-run option, to let PHP-CS-Fixer automatically fix your code.
Wednesday, October 28, 2015
In a real-word application you might want to record some additional metadata, like "who" issued the command, what was his IP address, which user-agent did he use, and so on. This is especially useful when you want to know, which commands "John Doe" sent to the system. The simplest way to achieve this, is to use an EventStore-Plugin. Here is an example for Zend Framework 2, using the Zend\Authentication component to get the issuer and Zend\Http\PhpEnvironment\RemoteAddress to get the client's IP address.
This will add "issued_by", "ip_address" and "user_agent" to the metadata of all recorded events. Now you still need to enable the plugin. If you use the provided container-factories, you simply add the plugin there:
Keep in mind, that the domain model is unaware of the domain event's metadata. Therefore if you need to know the issuer f.e. in your domain model, you should write this as a CommandBus-Plugin that manipulates the command. This way you can get the issuer from the command in your command handler within the domain. An example:
In this case you need to add the enricher as CommandBus-Plugin instead of an EventStore-Plugin of course:
You noticed perhaps that we need to use a special command class that knows the issuer. That is easy to achieve:
Now you only need to extend your commands from this base-class.
Note: If you work with Prooph EventStore, you don't need to extends the base-classes from Prooph, like Command. You're free to implement them by yourself for your needs.
Tuesday, October 27, 2015
- History Replay
- Snapshot Support
- Apply Events Late
- EventStream Iterator
- interop config support
- AggregateRepository Factory
History ReplayThe read model can be regenerated from history at any point in time by replaying recorded events.
Snapshot SupportIf you have way to many events to replay in order to reconstruct the aggregate root, why not take a snapshot? The prooph components ship with different snapshot adapters like MongoDB, Doctrine DBAL and even Memcached backends. So replaying of thousands of events is not a burden any more.
Apply Events LateEvents are only applied after transaction commit to ensure that the aggregate root can never reach an invalid state. This is especially useful for long-running CLI scripts.
EventStream iteratorThe event stream is now implemented as an Iterator instead of a simple array. This reduces the memory usage a lot when replaying big event streams.
Interop config supportThe components ship with ready-to-use container-interop factories using https://github.com/sandrokeil/interop-config. This makes it really simple to configure the factories.
Want more? Visit getprooph.org to check out the documentation or try out our demo application proophessor-do. Pick up a task and at the sample application to get started with event sourcing and get your hands a little dirty.
The producer interface is very simple:
On the other hand we have an extendable consumer interface: The consumer supports the following:
- defer message for later decision whether to ack or nack
- ack & nack blocks of messages
- configure prefetch count
- automatic exchange and queue creation
- set callback for handling delivery of messages
- set callback for handling flush deferred messages
- set error callback
- set configurable logger
- idle timeout
- configurable wait timeout
- unix signal handler support
- generic cunsumer controller and cli integration
- supervisor support
- integration in HumusSupervisorModule
Even more to come....
There is also a manual at Read the Docs and a Demo-Module incl. RPC-Client & -Server Example. Thew manual and the demo module will help you getting startet with Queuing in Zend Framework 2 without any pre-existing knowledge and guide you how to create topic-exchanges, header-exchanges, fanout-exchagesn, how to set up dead-lettering, message timeout, and so on.
Your contributions are welcome!
Sunday, February 22, 2015
Thursday, July 18, 2013
- Fight for Pareto's law, look for the 20% of effort that will give you the 80% of results.
- Prioritize, minimalism isn't about not doing things but about focusing first in the important.
- Perfect is enemy of good, first do it, then do it right, then do it better.
- Kill the baby, don't be afraid of starting all over again. Fail soon, learn fast.
- Add value. Think constantly how you can help your team and position yourself in that field/skill.
- Basics, first. Follow always a top-down thinking starting by the best-practises of CS.
- Think different. Simple is harder than complex, which means you'll need to use your creativity.
- Synthesis is the key of communication. We have to write code for humans not machines.
- Keep it plain. Try to keep your designs with few layers of indirection.
- Clean kipple and redundancy. Minimalism is all about removing distractions.
I am currently working on the german translation and will get the russian translation from a friend, too.
Sunday, February 24, 2013
Sending stream responses is a new feature in Zend Framework 2.1. This short introduction will help you getting startet on how to send stream responses in Zend Framework 2.
Most times an application would deliver file downloads or video streaming with static assets, delivered directly frm Apache or Nginx. But sometimes there are restrictions: Only logged-in users should be able to download this file, watch this content, perhabs even a more complicated permission system. Then the application needs to do some permission checks and stream the response.
In this example we assume a simple file download, we deliver the file as stream response, because this is much less memory consuming and more efficient, compared to grabbing the file content and pushing it to the response body of the default response object.
Even more complex use cases with download resume and speed limits are also possible in the future, but this is part of my next blog post about this topic. However you can see how easy it is to send stream responses with Zend Framework 2. As we return the response object directly in the controller, no view is created and rendered, too, so this is really a very fast operation.