Last week I attended the 2016 edition of the PHP Unconference Europe, taking place in Palma De Mallorca. This post contains my notes from various conference sessions. Be warned, some of them are quite rough.
Overall impression
Before getting to the notes, I’d like to explain the setup of the unconference and my general impression.
The unconference is two days long, not counting associated social events before and afterwards. The first day started with people discussing in small groups which sessions they would like to have, either by leading them themselves, or just wanting to attend. These session ideas where written down and put on papers on the wall. We then went through them one by one, with someone explaining the idea behind each session, and one or more presenters / hosts being chosen. The final step of the process was to vote on the sessions. For this, each person got two “sticky dots” (what are those things called anyway?), which they could either both put onto a single session, or split and vote on two sessions.
Voting starts at #phpuceu pic.twitter.com/XRs7vp85nZ
— Matthias Vianden (@mavia) May 28, 2016
One each day we had 4 such sessions, with long breaks in between, to promote interaction between the attendees.
Onto my notes for individual sessions:
How we analyze your code
Analysis and metrics can be used for tracking progress and for analyzing the current state. Talk focuses on current state.
- Which code is important
- Probably buggy code
- Badly tested code
- Untested code
Finding the core (kore?): code rank (like Google page rank): importance flows to classes that are dependent upon (fan-in). Qafoo Quality Analyzer. Reverse code rank: classes that depend on lots of other classes (fan-out)
Where do we expect bugs? Typically where code is hard to understand. We can look at method complexity: cyclomatic complexity, NPath complexity. Line Coverage exists, Path Coverage is being worked upon. Parameter Value Coverage. CRAP.
Excessive coupling is bad. Incoming and outgoing dependencies. Different from code rank in that only direct dependencies are counted. Things that are depended on a lot should be stable and well tested (essentially the Stable Dependencies Principle).
Qafoo Quality Analyzer can be used to find dependencies across layers when they are in different directories. Very limited at present.
When finding highly complex code, don’t immediately assume it is bad. There are valid reasons for high complexity. Metrics can also be tricked.
The evolution of web application architecture
How systems interact with each other. Starting with simple architecture, looking at problems that arise as more visitors arrive, and then seeing how we can deal with those problems.
Users -> Single web app server -> DB
Next step: Multiple app servers + load balancers (round robin + session caching server)
Launch of shopping system resulted in app going down, as master db got too many writes, due to logging “cache was hit” in it.
Different ways of caching: entities, collections, full pages. Cache invalidation is hard, lots of dependencies even in simple domains.
When too many writes: sharding (split data across multiple nodes), vertical (by columns) or horizontal (by rows). Loss of referential integrity checking.
Complexity with relational database systems -> NoSQL: sharding, multi master, cross-shard queries. Usually no SQL or referential integrity, though those features are already lost when using sharding.
Combination of multiple persistence systems: problems with synchronization. Transactions are slow. Embrace eventual consistency. Same updating strategies can be used for caches.
Business people often know SQL, yet not NoSQL query languages.
Queues can be used to pass data asynchronously to multiple consumers. Following data flow of an action can be tricky. Data consistency is still a thing.
Microservices: separation of concerns on service and team level. Can simplify via optimal tech stack per serve. Make things more complicated, need automated deployment, orchestration, eventual consistency, failure handling.
Boring technology often works best, especially at the beginning of a project. Start with the simplest solution that works. Hold team skills into account.
How to fuck up projects
Before the project
- Buzzword first design
- Mismatching expectations: huge customer expectations, no budget
- Fuzzy ambitious vocabulary, directly into the contract (including made up words)
- Meetings, bad mood, no eye contact
- No decisions (no decision making process -> no managers -> saves money)
- Customer Driven Development: customer makes decisions
- Decide on environment: tools, mouse/touchpad, 1 big monitor or 2 small ones, JIRA, etc
- Estimates: should be done by management
During the project
- Avoid ALL communication, especially with the customer
- If communication cannot be avoided: mix channels
- Responsibility: use group chats and use “you” instead of specific names (cc everyone in mails)
- Avoid issue trackers, this is what email and Facebook are for
- If you cannot avoid issue trackers: use multiple or have one ticket with 2000 notes
- Use ALL the programming languages, including PHP-COBOL
- Do YOUR job, but nothing more
- Only pressure makes diamonds: coding on the weekend
- No breaks so people don’t lose focus
- Collect metrics: Hours in office, LOC, emails answered, tickets closed
Completing the project
- 3/4 projects fail: we can’t do anything about it
- New features? Outsource
- Ignore the client when they ask about the completed project
- Change the team often, fire people on a daily basis
- Rotate the customer’s contact person
Bonus
- No VCS. FTP works. Live editing on production is even better
- http://whatthecommit.com/
- Encoding: emjois in function names, umlaut in file names. Mix encodings, also in MySQL
- Agile is just guidelines, change goals during sprints often
- Help others fuck up: release it as open source
- git blame-someone-else
The future of PHP
This session started with some words from the moderator, who mainly talked about performance, portability and future adoption of, or moving away from, PHP.
- PHP now fast enough to use many PHP libraries
- PHP now better for long running tasks (though still no 64 bit for windows)
- PHP now has an Abstract Syntax Tree
The discussion that followed after was primarily about the future of PHP in terms of adoption. The two languages most mentioned as competitors where Javascript and Java.
Java because it is very hard to get PHP into big enterprise, where people tend to cling to Java. A point made several times about this is that such choices have very little to do with technical sensibility, and are instead influenced by the eduction system, languages already used, newness/ hipness and the HiPPO. Most people also don’t have the relevant information to make an informed choice, and do not do the effort to look up this information as they already have a preference.
Javascript is a competitor because web based projects, be it with a backend in PHP or in another language, need more and more Javascript, with no real alternatives. It was mentioned several times that not having alternatives it bad. Having multiple JS interpreters is cool, JS being the only choice for browser programming is not.
Introduction to sensible load testing
In this talk the speaker explained why it is important to do realistic load testing, and how to avoid common pitfalls. He explained how jMeter can be used to simulate real user behavior during peak load times. Preliminary slides link.
Domain Objects: not just for Domain Driven Design
This session was hard to choose, as it coincided with “What to look for in a developer when hiring, and how to test it”, which I also wanted to attend.
The Domain Objects session introduced what Value Objects are, and why they are better than long parameter lists and passing around values that might be invalid. While sensible enough, all very basic, with unfortunately no information for me whatsoever. I’m thinking it’d have been better to do this as a discussion, partly because the speaker was clearly very inexperienced, and gave most of the talk with his arms crossed in front of him. (Speaker, if you are reading this, please don’t be discouraged, practice makes perfect.)
Performance monitoring
I was only in the second half of this session, during which two performance monitoring tools where presented. Tideways by Qafoo and Instana.
Some tweets
Watching the sunrise in Palma, great way to be coding in the morning. A big THANK YOU to the organisers #phpuceu ? pic.twitter.com/37tyHovtJS
— Eddie Jaoude (@eddiejaoude) May 30, 2016
#phpuceu family photo 2016 pic.twitter.com/9zlAsoGas8
— Eddie Jaoude (@eddiejaoude) May 29, 2016