![php[architect] logo](/wp-content/themes/phpa/images/new_logo_mark_nav.png){kind=logo}
One of the best feelings you can have is a “lightbulb moment.” Whether it’s a great idea or clarity of understanding on a problem you are working on, coding practice, architecture, design pattern, or some other paradigm, that moment when you can connect the dots and make sense of something that moments earlier seemed utterly confusing.
PHP is becoming more popular for controlling Internet Of Things devices like home automation, cameras, doorbells, and even light bulbs. In this article, we’ll shed some literal and figurative light on controlling Philips Hue smart light bulbs using an existing PHP library.
Each business has its set of problems that developers need to solve. In DDD, those problems describe how the business works and the user flows – the so-called Problem Space. On the other side, when we want to provide functionality by writing the code to solve those problems, this is Solution Space. DDD is about those two things. We need to have a problem in order to apply a solution.
In the last two months, we saw how to control randomness. This month, we let users guess the random sequence created by the program.
One of the interesting things about programming is that when faced with a similar problem, developers tend to build the same solution. They may call their implementations different names, or there may be slight differences at a superficial level, but ultimately the architectural design is the same. At a base level, we tend to call these Patterns.
Symfony is one of the stalwarts of modern PHP, dating back to 2005. Symfony has continued to evolve into a framework of components focused on building web applications using decoupled and reusable components. Their philosophy of embracing professionalism, best practices, standards, and interoperability of applications is an exciting statement. Backing up that statement is years of open source community contribution and cooperation among the Symfony team, open-source contributors, partners, and enterprise developers. This month we’re diving into Symfony 6 with a tour of the ecosystem and building our own demo application.
Designing for failure is difficult because it’s usually not practical to predict every possible thing that could go wrong. Last month we got the preliminary “spadework” out of the way. This month we begin our first feature. This feature creates a mechanism for capturing those “random and rare” failures.
Every application will, one day, be exposed to a cybersecurity risk. Learning how to categorize and rate those risks is critical to keeping your team focused on the things that matter most.
Everywhere I look, there are articles targeting programmers with suggestions and plans for how to be “better.” Some articles promise to make you a better co-worker, while others extol the virtues of being a better manager. Some will make you better at communicating while others will make you better at coding. In all cases, though, the message is the same: you programmers need to be “better.”
Accessing backend system…
We're sorry, but your session has expired due to inactivity. Please use your browser to refresh this page and log in to our system again.
Leave a comment
Use the form below to leave a comment: