Yes, you know, you should have written that test! But what If you already do writing tests, but you don't see the result of your actions. Tests run slow, they are fragile, hard to read and maintain. Fixing a test is harder than disabling it.
Don't blame yourself. It's not about you, it's about some points you should have taken into account while your testing codebase grew. In this talk I will tell you about
Contributing to PHP is a subject shrouded in the mystery of mailing list subscriptions, and a magical place named "internals".
But it doesn't have to be: PHP is on github, and anybody can open a pull request to fix almost anything.
We'll start at the beginning: Looking at the process of fixing old features and getting new features into PHP; from opening a PR against the right branch, to starting an internals discussion, to writing your own RFC.
In hardly any other area we've had as much change and improvement as in the field of databases. Just a few years ago everyone had "their" database that was used for each project. Today you are confronted with a variety of approaches and implementations.
We start off with a brief look at the theoretical background of distributed systems and databases in particular. On the basis of this, we take a look at traditional relational databases such as PostgreSQL. Additionally, we dive into newer NoSQL systems like MongoDB, Redis, Cassandra, or Elasticsearch.
After that, we discuss possible scenarios as well as the advantages and disadvantages of several databases:
The right choice of database(s) hasn't become easier through the wide range of possibilities, but all the more interesting!
Everybody knows how to install a debugger in PHP. But yet very few professional PHP developers have embraced step debugging, and instead do it the old-fashioned way. For many, this is because they simply don't know how to step-debug effectively.
In this talk we will see how to debug common issues to speed problem resolution, and spend less time troubleshooting and more time coding. Attendees will walk away with the fundamentals to get up and running quickly once they get a debugger installed.
Developing an application does not end once the coding is finished. Deploying it to production, and making it available to the users should be a part of the development process, not an afterthought.
Can you be sure that your application will behave the same way it did in your test environment? Is the configuration correct? What about server settings? Database changes? What would you do if things go wrong.
In this workshop we will try to find the answers to this questions, analyze some different concepts, available tools and important principles. Let's share our experiences together, and try to come up with a solution(s) that best fit the needs.
When faced with a challenging legacy code base, tightly coupled and void of discernible structure: a big ball of mud, it is common to decide to refactor this monolith to a microservice architecture to separate concerns and split the codebase up, however without any clear boundaries you are in danger of creating a distributed big ball of mud.
You may recognise the symptoms of a distributed ball of mud: a large unfocused 'common' library shared between multiple services; performance issues as your front end makes calls to multiple back end API's to serve a single request; dependency hell on deployments as you have to release multiple code bases simultaneously and uptime issues as a single microservice going down brings down your entire application.
In this talk I'm going to cover some of the common pitfalls you might encounter when building a microservice architecture and show you how to use an event driven architecture to build truly scalable microservices.
What if you as a developer don't have to talk to tech ops person ever again. What if you as a developer could move closer to a business and further away from the hardware.
Devops culture improved processes and collaboration and brought lot of other benefits. But can we go step or two further?
Let's explore possibilities of infrastructure abstraction and complete automation of provisioning, deployment, running and monitoring. In this talk we will look at some of the solutions available today. We are going to see how can we use tools like kuberneties, deis workflow and cloud functions on our quest for NoOps!
We will create a fun and useful development and deployment tool.
We’ll set up Jenkins on a Raspberry Pi, which will be a local CI server. Then we’ll create an API in Laravel that will be able to send commands to Jenkins. Raspberry Pi will shine a light while a build is in progress, and produce different sounds if a job was successful or not (if PHPUnit tests pass or fail).
We will have a second Raspberry Pi which will have a motion sensor, so when you wave, it will send a request to the API, which will trigger a build on the Jenkins Raspberry Pi.
What does Java, Python, Ruby,… have in common that PHP doesn’t? They are general purpose languages while PHP is primarily designed for web development!
That said, it means you can use PHP as a framework, but should you?
What are the consequences of going that way?
In this session, we are going to investigate the building blocks of frameworks (Routing, MVC, Dependency Injection,…) leveraging features that PHP provides natively and how a project can be realised with PHP as the only framework while respecting principles like: “Don’t reinvent the wheel”, KISS, DRY, YAGNI, …
More often than not, in software development there are situations with long running sequential operations which can be avoided utilizing parallelization. During the workshop we'll go through the challenges and pitfalls we had during the development of a system that handles messages from multiple queues asynchronously. Building a daemon process in PHP which spawns custom handlers for different queues, processing them all in parallel.
Everybody likes Object-Oriented Programming and wants to keep the source code clean and clear, but there are cross-cutting concerns that can not be solved easily such as logging, caching, authorization, transaction control and more. Are there any ways to solve them? Yes. One of them is Aspect-Oriented Programming.
This is a talk about Aspect-Oriented Paradigm with presentation of Go! AOP framework, that was inspired by Lithium, Java Spring and famous AspectJ frameworks. And for now AOP is possible in PHP.
I will show some new techniques such as inter-type declarations (dynamic traits for classes, dynamic interfaces, adapters), such as method interception, AOP caching, logging and much more. Are you tired of implementing of logging or caching in all methods? Do you want to extract this code to the one place? Join me and learn the elegant ways of solving cross-cutting concerns in PHP.
For the last few years, PHP community has been buzzing about ES/CQRS, pretty much there was a talk on every conference. Now it's time to see how it worked out for me in practice.
ES/CQRS is a different approach to building applications from what we all have been thought to do for years. I'm not going to introduce Event Sourcing and Command Query Responsibility Segregation (ES & CQRS) but speak about my experiences in developing & running it on production.
I have implemented it on few projects: in some I run it as a part of bigger application, while in some it's just the core and one where everything is event driven. The shift in architecture and mindset is pretty big: while code structures and logic became simple, amount of code and workflows get complicated to the point of 'where did I loose this input?'.
Not to go into too many details, I've had to learn lot of DDD practices that I feel have made me a better developer and use some of the knowledge gathered in this projects into 'everyday' code of projects that I work on.
Jenkins has been one of the most popular continuous integration systems out there for many years. It was perfectly functional, but the UI wasn't the friendliest in the world and configuring jobs through a UI or XML files was just painful.
In late 2016, Jenkins finally made it to version 2.0 which brought a huge number of improvements. From the new Blue Ocean UI to being able to define build configurations in your repo, it's a massive step up from version 1.
In this talk, we'll go from an empty machine to a Jenkins install that automatically detects repos, branches and pull requests and builds them according to the Jenkinsfile in each branch. We'll be running tests, linting and packaging applications in parallel where possible, and even running things on Linux, Windows and MacOS all at the same time!