So last weekend I visited the Dutch Magento Unconference 2017. For those of you who don’t know what an unconference is: it’s like a conference, only the topics are not pre-determined; the topics are determined by the audience that attends an unconference.
For example, if you want to talk about something, want to learn more about something, start or share a discussion, you can simply bring in such a topic and if it gets enough votes, it gets a timeslot and you can start the talk, discussion or whatever.
So this year I attend some talks, but I also gave some talks. The talks I attended are summarized in this article; the talks I gave will be covered in future blog posts.
So let’s start with the first one:
This talk was given by Matheus Gontijo, a brilliant Brazilian speaker and was really inspiring.
Object Calisthenics (man what a difficult word for a dutchman) are not something new in the coding world. They are a set of 9 rules / advices that help you write better, leaner, cleaner code. Some of these rules I already applied in practice without even knowing there is a name for it, but others made you think and re-evaluate your own coding practices.
In short, these rules are:
- Only use one level of indentation per method.
- Don’t use the
- Wrap all functional primitives and strings.
- First class collections (don’t use arrays for collections, but create a unique (iterable) class.
- Use one
->per line (talk to friends, not strangers).
- Don’t abbriviate (write self-documenting code).
- Keep all entities small (keep your classes short).
- Don’t use more than 2 to 5 instance variables in a class.
- Don’t use getters and setters.
If you want to read more about Object Calisthenics, I’d advise you to read this article by William Durand.
Errors vs. Exceptions
I love semantics, so during the talk of Object Calisthenics a mini discussion started about the semantics of throwing erros and exceptions. After the discussion settled this was what my interpretation of it was:
- Errors are for user errors that can happen and ought to be caught by your application. For example: a user enters an invalid e-mail address. These thing can happen because the application allows them to happen.
- Exceptions are things that should not / never happen. For example: a database that went missing.
The touchpad of my 2015 MacBook Pro
I always thought that the touchpad of my MacBook Pro was actually pressable. I mean, it feels like a real click when I press it right? But it’s all a lie! It’s just a touchpad with a small motor under it that pushes back a physical bump so you think you clicked.
Try it yourself: turn off your MacBook Pro and click the touchpad. All of a sudden it doesn’t click anymore. It’s crazy! All lies!
How come I never heard of this one before? It’s ideal for setting up a local development environment to develop Magento. That was another interesting fact: almost everyone I spoke to on the Magento Unconference agreed that Docker is a shitty solution for local development of Magento 2. It makes sense for CI, because then you want to have the same environment as production, but for local development it just makes no sense (on Mac that is). It’s slow
(due to filesystem stuff), hard to setup/manage/maintain and a bitch with SSH keys (also a Mac/Docker related issue).
Valet Plus on the other hand is a simple composer library that you install globaly, that installs everything you need for the local development of Magento 2: nginx, mysql, redis, mailhog, etc. The only thing it doesn’t install for you is PHP, so you have to install PHP7 yourself (with Homebrew).
Credits and my respect go to Tim Neutkens
Dump configuration of Magento
The commando already exists since Magento 2.1.6 but I wasn’t aware of it. This is useful for the deployment of Magento in a CI process, because at the moment of writing, Magento still needs (at least that’s what I thought) a running database to compile it’s assets.
Bit this command exports the config and removes the dependency of a working database when compiling assets. It’s ideal. Just don’t forget to delete the file from your production server because it effectively overwrites the admin config, rendering it immutable.
This by the way is a nice example of what a Magento Unconference can offer: Magento is so big that it’s impossible for a developer to know all the ins and outs. But put a bunch of Magento 2 developers together and this kind of simple knowledge sharing happens. Perfect!
Also thanks to Tim for this one!
Template Bridge was also a nice thingy build by Jeroen Boersma. It’s a composer library that makes it easy to implement any given template language into any given framework. Jeroen built it and showed how he uses it to use Twig as a templating engine in Magento 2, while he kept the link between template and block class transparent.
I have to admit I was skeptical about this one because I tried applying Twig as a template engine into Magento before and the result was the same as it is everytime you try outsmart Magento: Do it the Magento Way, because otherwise you’re in a world of hurt.
But the talk of Jeroen convinced me to at least analyze and try out template bridge because it looked very promising.
MSI / Multiple Source Inventory / CQRS
This was a talk that was a bit hard for me to follow. It was given by the Magento Community Engineering team, and they where talking about a new feature they are working on: Multi Source Inventory (presentation from Magento UK 2017 can be found here).
The new feature basically adds support for multiple warehouses in Magento 2, but the main focus of the talk was about implementing CQRS (Command Query Responsibility Segregation) into Magento. This was all very new to me, so I’ll have to dive deeper into what it actually does, but the main idea of CQRS is that you separate your read and write queries into different objects. This goes hand-in-hand with Event Sourcing: where you store the events that manipulate your data, rather and manipulate your objects directly.
For example: in the Multi Source Inventory feature they’re working on, they’re using Event Sources to store the increments and decrements of the stock. The stock itself is aggregated according to those events. This way you have a history of how a stock became manipulated, but also from which source (in this practical example, from which warehouse). So Magento keeps track of the multiple inventories in different warehouses, but the stock itself will always be one number. And further down the chain you can use this feature to determine which shipping method or not is available or what the shipping costs are (since you’re working with multiple warehouses).
If I understood it correctly, this functionality will not be limited only to this new feature, but it will also be a core concept that can be used in your own modules as well. But that’s most likely to become a Magento 2.3 or later feature.
Of course there was a lot more interesting stuff on the Magento Unconference, but the above items are the things I found the most interesting. Up to next year!
Visitors give this article an average rating of 4.2 out of 5.
How would you rate this article?
★ ★ ★ ★ ★