SymfonyCon day two.
We were wellcomed with a coffee, juices and hot croassans. A nice way to start this day.
I was expecting less people today, being a second day and all, at least in the morning, but the rooms are full.
Actually it makes sense, since first part of the day is filled with interesting topics.
You can find description of SymfonyCon day one here.
PHPUnit Best Practices – Sebastian Bergmann at SymfonyCon
One great presentation at SymfonyCon by the creator of PHPUnit himself. Twitter contact: @s_bergmann
A year from now we will have PHP 8. Once again, as other authors mentioned yesterday, using the latest supported version of PHP is a must!
Sebastian explained difference between active support (bugfixes) and security support. He pointed out that Long term support is not a solution, but an possible problem.
This actually makes sense, because it keeps you “sleepy” instead of investing time to keep up with valid PHP versions.
PHP and PHPUnit tips
Related to PHPUnit, same rule goes. Use the supported version and utilize good new features of new version. Furthermore, updating to major version can not be done without a process.
For example, ” * in composer is not a version constraint. That is somewhat of a Deathstar from StarWars for your code.
Do not install PHPUnit globally, because this is “per project” dependency and it different projects can require different versions. One size does not fit all.
Before updating to new major versions (and for minors as well), read the ChangeLog. 🙂
Some important PHP technical hints:
- Ensure that your PHP configuration displays errors at all. (Configuration of php.ini file, error reporting to -1)
- log.errors_max_lenght = 0, to ensure getting full length of error message
- show_exception_trace = 0
- memory_limit = -1 (only in development, never in production)
- Firstly, utilise phpunit.xml configuration as much as possible. Sebastian presented examples of good configuration, you can find them on his slides. I won’t be screenshoting them here.
- Secondly, think about possibility of reordering tests. For example, if one test fails, on next execution that test will be executed first. Eesentially, there are several different ordering strategies (including random).
- Thirdly, use strict annotations, this can be forced within configuration.
- Furthermore, PHPUnit test has wizard to automatically create skeleton configuration, so this is a nice feature.
- As a sidenote make meaningful test names, Love your test code. 🙂
- Finally, utilize data providers for data intensive tests. Use @covers annotation, code coverage is a great tool. Use PCOV.
Using API Platform to build ticketing system – Antonio, Peric-Mazar at SymfonyCon
What is API platform?
API platform is full stack framework dedicated to API-Driven products. Antonio gave a detailed overview of this platform.
Personally, this part of presentation was too fast with lots of details and fast talk in couple minutes. It is a personal preference, but I would prefer less information but in more structured way. For technically complex topics, sometimes Less is More.
API platform tips
Tips, as provided my lecturer:
- Firstly, use Yaml (actually, presented screenshot looked like Swagger/OpenAPI specification, which can be written in Yaml format).
- Secondly, using JWT (Jason Web Tokens) for authentication. This was followed by explanation on how JWT works. There was a quick explanation of how token works (but without mentioning grant policies or commenting on which grant was used in presented project).
- Thirdly, resource and operation level using voters.
- Fourthly, tip was to use “database-less user” to get authentication speed.
- Fiftly, automate translation process if possible
- Finally, manipulate context, do not build separate api/admin resources.
Symfony Messanger Controller is mentioned (it is SymfonyCon after all), as other lectures did as well, with a very good note of praise.
All in all, interesting presentation, but with lots of details and screenshots of code. I guess that real value of this presentation can be utilised by slowly reading presentation and trying out one of many examples.
Integrating performance management in your development cycle by Marc Weistroff, CTO of Blackfire
“We have huge performance issues” is one of the common sentences.
Performance is how well a person or machine does a piece of work or an activity.
Slow performance is always a bug. Good performance is a feature.
Bar performance means bad business.
Bad performance COSTS a lot (charts drop, higher infrastructure costs). “BBC losts 10% users for each second they lost.”
“AutoAnything improved performance for 50% which resulted in 12-13% increase in revenue”.
Performance work is an investment.
Furthermore, maybe new feature is not what we need, maybe we first need better performance.
Therefore, performance tests should be part of CI (Unit tests for performance).
Better performance means less servers, less electronic waste and less CO2.
Performance work requires measurements on multiple environments.
Measure what matters:
- request time
- memory usage
- number of HTTP calls
- size of HTTP response in bytes
Perfect tool to measure performance is profiler (blackfire.io is a profiler).
Blackfire hooks into PHP engine by being a PHP extension.
Furthermore, it has 400 and more built-in metrics (for WordPress for example).
Multisteps functional calls and profile at each step.
Marc made a nice presentation of use case for profiling.
Building really fast applications – Thobias Nyhalm at SymfonyCon
The last lecture for a day. Full house, people are sitting on the ground, room is full.
What is a framework?
A framework is basically a code that we are responsible of.
Three rules of performance optimization
- Buy a better server (hardware is always cheaper than software). Previous lecturer would not agree. 🙂
- Use Varnish (handling kzilion of requests)
- Run less code (only way to really make faster code)
Defining project complexity
Whenever we start new project we need to think about complexity. Basically, what level of framework support do we need. Maybe something is an overkill for us?
Do we need ORM (i.e. Doctrine) or can simple PDO do the job?
Are we trying to cover all edge cases or should we cover only edge cases that we actually have?
Thobias presented “SuperSlim framework” strictly in educational purposes.
For a complete list of tips and code examples, please find this lecture and slides if and when available.
- Firstly, postpone work. Use async for basically anything possible.
- Secondly, use lazy services.
- Thirdly, use Subscriber services
- Furthermore, proper usage of indexes (and SQL explain query for analysis)
- Then, keep in mind that dehidration is expensive in Doctrine (keep an eye of number of created objects by ORM queries)
- Data transfer concerns (partial objects, split entities with 1 to 1 mapping, create “simpler model”, i.e. for Doctrine it is NEW keyword)
- Proper configuration of php.ini and caching
- Run less code in frontend.
- Limit cookies.
- Only include JS scripts that are actually needed.
- Use font swap (load first, change later)
- Optimaze and lazy load images
- Use proper cache control and immutable keyword (indicating that resource will never change).
Bonus tip: Lie and cheat. 🙂
Example: Laggy logging in PayPal with message “Logging you in safely”. It’s not a performance issue, it is a security feature.
Great and funny lecture, several very good points and ideas. In mu opinion, one of the best lectures within whole SymfonyCon.