Сергей Кузнецов

В 2024 году в сфере разработки программного обеспечения ожидается быстрый технологический прогресс наряду с растущими проблемами безопасности.Необходимость тщательной оценки рисков, непрерывного тестирования и проверок соответствия перед полномасштабным развертыванием неизбежна. Будущее разработки программного обеспечения требует от компаний подготовки к деликатному танцу между инновациями и надежностью. В этом году мы увидели энтузиазм в отношении искусственного интеллекта и машинного обучения с появлением генеративного искусственного интеллекта и других подобных технологий. Однако по мере того, как год подходит к концу, основной акцент, похоже, сместился на достижение правильного баланса между эффективностью и безопасностью. Этот двойной императив является фундаментальной проблемой, подчеркивающей, что ответственное принятие решений, сохранение конфиденциальности и этические стандарты имеют первостепенное значение. Как и ожидалось, технологии, воплощающие эти принципы, будут иметь преимущество в глобальной сфере разработки программного обеспечения. Поэтому эксперты компании DST Global по разработке программного обеспечения изучили текущие тенденции и сделали некоторые прогнозы относительно ситуации на предстоящий год. Давайте рассмотрим эти прогнозы относительно разработки программного обеспечения на 2024 год.1. Эффективность на основе искусственного интеллекта с осторожностьюОжидается, что в 2024 году разработчики программного обеспечения начнут использовать инструменты искусственного интеллекта и машинного обучения, такие как Python, уделяя особое внимание эффективности искусственного интеллекта. Однако компании будут подходить к внедрению ИИ осторожно, учитывая потенциальные риски безопасности и ограничения в отношении прозрачности, безопасности и доверия. Таким образом, в то время как разработчики программного обеспечения во всем мире будут поощрять внимательное использование инструментов и услуг искусственного интеллекта, заинтересованные стороны бизнеса будут вновь заявлять о необходимости осторожного развития для поддержания стабильности системы. Такие инструменты, как TensorFlow, PyTorch и безопасные среды разработки для ИИ, вероятно, станут более популярными в будущих стратегиях разработки программного обеспечения в 2024 году.2. Устойчивость цифровой иммунной системыВ 2024 году организации будут уделять приоритетное внимание устойчивости при разработке программного обеспечения, уделяя особое внимание CloudOps, DevSecOps и AI/ML. Это означает, что в будущем году индустрия программного обеспечения, похоже, заинтересована в решениях для аварийного восстановления, отказоустойчивых архитектурах и решениях для непрерывного мониторинга. Наши эксперты также прогнозируют, что заинтересованные стороны бизнеса, скорее всего, отдадут приоритет развитию того, что Gartner называет «цифровой иммунной системой». Эта концепция подчеркивает важность построения систем, способных противостоять сбоям и продолжать эффективно работать. Кажется, это отличная новость для разработчиков и компаний, имеющих опыт работы с инструментами непрерывного мониторинга, такими как Prometheus и Nagios.3. Акцент на кибербезопасности и безопасности данных. С появлением мощных моделей AI/ML и анализа данных растет обеспокоенность по поводу кибербезопасности, безопасности данных и конфиденциальности. Следующее поколение разработки программного обеспечения теперь подчеркивает необходимость надежности при разработке программного обеспечения. Таким образом, в 2024 году крайне важно, чтобы проекты разработки программного обеспечения создавали барьеры для совместимых, этических и безопасных конечных продуктов. Такие функции, как шифрование, контроль доступа, обнаружение вторжений и защита данных, будут иметь приоритет.4. Умная и безопасная разработка платформыЧтобы повысить производительность, осведомленность о безопасности и инновационные возможности, индустрия разработки программного обеспечения должна охватить больше, чем просто архитектуру DevOps, Kubernetes и микросервисов. В 2024 году будет больше стимулов для разработки платформ, начиная от самообслуживающихся внутренних платформ разработчиков и заканчивая платформами управления жизненным циклом программного обеспечения. Это обеспечит устранение избыточных инструментов и повысит безопасность и соответствие облачным приложениям и инновациям искусственного интеллекта и машинного обучения. Наши эксперты предполагают, что в наступающем году будет наблюдаться рост спроса на такие специфические для инфраструктуры возможности, как код, оркестровка контейнеров и автоматизация безопасности.5. Ренессанс Python продолжаетсяPython сохранит свое доминирование в 2024 году. Поскольку популярность машинного обучения и обработки данных во всех отраслях продолжает расти, спрос на разработчиков Python будет значительно возрастать. Универсальность Python, от веб-дизайна до машинного обучения, позиционирует его как лучший язык программирования для решения сложных задач. Ожидайте, что Python сыграет ключевую роль в продвижении инноваций в различных областях, от искусственного интеллекта и Интернета вещей до разработки веб-сайтов и мобильных приложений.6. React Native совершает революцию в разработке кроссплатформенных приложенийВ 2024 году React Native продолжит оставаться предпочтительной средой для разработки кроссплатформенных приложений. Его способность создавать высококачественные приложения с единой кодовой базой упростит процесс разработки для компаний, стремящихся выйти на глобальный рынок. Поскольку компании все больше отдают приоритет эффективности и экономичности, влияние React Native будет расти, что делает его жизненно важным активом в постоянно расширяющейся сфере разработки приложений.7. Эволюция облачных технологийОблачные технологии значительно изменятся в 2024 году. С акцентом на гибкость эти технологии упростят управление ИТ-инфраструктурой, что приведет к снижению сложности и повышению масштабируемости. Ожидайте, что облачные решения станут более доступными, а организации выиграют от повышения производительности, экономической эффективности и гибкости своих ИТ-операций.8. Kubernetes лидирует в области оркестрации контейнеровВ 2024 году Kubernetes сохранит лидерство в оркестрации контейнеров. Благодаря быстрому внедрению контейнеров для развертывания приложений Kubernetes продолжит предоставлять автоматизированное и масштабируемое решение для управления контейнерными приложениями. Это позволит организациям оптимизировать свою деятельность, улучшить использование ресурсов и снизить сложность инфраструктуры, укрепив ее роль важнейшего компонента в современной экосистеме разработки программного обеспечения.9. Продолжающийся рост аутсорсинга разработки программного обеспеченияВ 2024 году аутсорсинг разработки программного обеспечения продолжит набирать обороты. Организации, от стартапов до устоявшихся предприятий, обратятся к аутсорсингу, чтобы сократить расходы и получить доступ к огромному пулу специализированных ресурсов. Тенденция аутсорсинга ускорит разработку инновационных программных решений, позволяя компаниям оставаться конкурентоспособными и более эффективно выводить продукты на рынок.10. Эра практик обеспечения безопасности DevSecOpsDevSecOps займет центральное место в 2024 году как важнейший подход к безопасности. Интегрируя безопасность в жизненный цикл разработки, организации будут уделять приоритетное внимание раннему обнаружению угроз безопасности и уязвимостей. Этот сдвиг приведет к более безопасным приложениям, снижению подверженности угрозам и повышению доверия к автоматизированным системам, что усилит важность безопасности в процессе разработки программного обеспечения.11. Оптимизированные операции с CloudOpsCloudOps станет ключевой тенденцией в 2024 году, поскольку организации осознают ценность эффективного управления облачными операциями. Этот подход будет сосредоточен на оптимизации финансовых процессов и внедрении экологически чистых методов, что приведет к экономии затрат, улучшению репутации бренда, соблюдению нормативных требований и устойчивой деловой практике. CloudOps поможет организациям эффективно справляться со сложностями облачных операций.12. Автоматизация контроля качества повышает качество программного обеспеченияВ 2024 году автоматизация контроля качества действительно будет играть решающую роль в обеспечении качества программного обеспечения. Методологии автоматизации контроля качества будут охватывать новые тенденции, такие как интеграция искусственного интеллекта, сплоченность DevOps и раннее обнаружение дефектов для критически важных потребностей. Эта автоматизация позволит своевременно обнаруживать проблемы, что в конечном итоге приведет к повышению качества программного обеспечения, сокращению циклов тестирования и значительному улучшению пользовательского опыта. Синергия этих факторов выведет обеспечение качества программного обеспечения на новый уровень в следующем году.13. Восхождение Интернета вещей в 2024 году.В 2024 году Интернет вещей станет свидетелем многогранного роста, чему будут способствовать периферийные вычисления, внедрение искусственного интеллекта и подключение к 5G. Интернету вещей будет предложено участвовать в преобразующих изменениях в различных отраслях, включая производство, здравоохранение и многое другое. Этот всплеск возможностей Интернета вещей повысит эффективность, автоматизацию и прогнозирование».14. Финтех-революция продолжаетсяВ 2024 году финтех продолжит расширять границы возможного, расширяя свои предложения и влияние в финансовой индустрии. Это расширение будет проявляться в появлении новых цифровых банковских решений, ориентированных на надежные меры безопасности, платежных платформ, использующих технологию блокчейна для безопасных и эффективных транзакций, а также инвестиционных инструментов, которые используют управление рисками на основе искусственного интеллекта, чтобы предоставить частным лицам и предприятиям более эффективные способы управлять своими финансами. Эти достижения в совокупности изменят то, как люди взаимодействуют со своими финансовыми ресурсами и защищают их.15. DST Platform - переход от CMS к CMF системамВ 2024 году откроет для себя более современный подход к системам управления сайтами, это обусловлено появлением в последнее время большим количеством фреймворков, которые на деле достаточно еще сложны для конечного пользователя, по этому скорее всего как разработчикам так и клиентам потребуется среднее звено между CMS и фреймворками. Одной из таких систем является - DST Platform - CMF система (Content Management Framework) с открытым исходным кодом, то есть фреймворк, предназначенный для разработки сложных веб-приложений и веб-интерфейсов с установленной панелью управления.На базе DST Platform можно разработать всё что угодно. В том числе высоконадёжные и максимально безопасные банковские сервисы, маркетплейсы, социальные сети, нагруженные порталы, интерактивные сайты, эко-системы, сервисы государственных структур и т.д. Система очень гибко настраивается под любой тип проекта, ядро обновляется независимо от остального кода, поэтому обеспечивает достаточный уровень защиты и производительности в любой момент времени.Во второй версии платформы имеются все самые необходимые инструменты: отчёты производительности, система управления доступом и ролями пользователей, конструктор макетов, система модерации любого контента, REST API, генерация дополнительных компонентов и модулей, встроенная система тестирования функций, настраиваемые таксономии, управление базами данных и сервером прямо из единой панели панели управления и т.д.Перечислить все возможности DST Platform практически невозможно, но ясно одно – это система корпоративного уровня, разрабатываемая профессионалами. При этом DST Platform имеет открытый исходный код. 15. Цифровая трансформация здравоохранения продолжаетсяВ 2024 году отрасль здравоохранения будет использовать цифровые достижения из-за старения населения. Чтобы удовлетворить потребности в инновационных решениях и специализированных методах лечения возрастных заболеваний, здравоохранение увидит внедрение таких технологий, как Интернет вещей, прогнозная аналитика, телемедицина, носимые устройства и многое другое. В наступающем году также готовится привлечь больше виртуальных помощников и чат-ботов, которые изменят уход за пациентами, обеспечивая раннее выявление заболеваний, персонализированное лечение и улучшение психического здоровья.16. Технологическая эволюция розничной торговлиВ 2024 году розничная торговля будет определяться взаимодействием с клиентами на основе искусственного интеллекта, AR-покупками и прогнозным управлением запасами. Бесшовная интеграция онлайн-офлайн, персонализированные программы лояльности и индивидуальные рекламные акции произведут революцию в процессе покупок, гарантируя удовлетворенность клиентов, их лояльность и увеличение продаж.17. Кибербезопасность в центре вниманияВ 2024 году в сфере разработки программного обеспечения произойдет всплеск внедрения искусственного интеллекта и машинного обучения, при этом особое внимание будет уделяться балансу между инновациями и сохранением особого внимания к безопасности и конфиденциальности. В этом году киберустойчивость будет в центре внимания, превосходя традиционные меры кибербезопасности. Более того, нулевое доверие будет преобразовано в целостный подход на основе искусственного интеллекта, гарантирующий адаптивную безопасность в условиях меняющихся угроз.18. Двойные императивы инноваций2024 год обещает, что будущее разработки программного обеспечения будет удачным с точки зрения взаимодействия пользователей с новейшими технологиями, такими как AI/ML, Интернет вещей, облачные вычисления и многое другое. Организации будут балансировать адаптацию этих технологий с акцентом на преодолении конкретных проблем, связанных с финансовыми технологиями, здравоохранением, розничной торговлей, кибербезопасностью и другими отраслями.В 2024 году индустрия разработки программного обеспечения находится на пороге захватывающих инноваций, но она по-прежнему основана на принципах безопасности, устойчивости и надежности, создавая сбалансированную среду для прогресса и процветания. Будущее разработки программного обеспечения выглядит более ориентированным на использование передовых технологий, продолжая при этом те, которые помогают им поддерживать ценности безопасности, прозрачности и этических стандартов.

Пока нет комментариев

Multi-Process PHP

Let’s talk about asynchronous PHP code. There are more ways to make PHP code execute asynchronously and in parallel than there are reasons you can think of for wanting to do it in the first place.

And while I would love to talk about the many and varied things, let’s just look at the oldest and best supported method: spawning child processes.

Every time your PHP website serves a request, some web server spins up the PHP runtime in the hopes that it will have some PHP code to execute. It lives for that nonsense.

And every time that happens, a single process is dedicated to solving that one problem. The problem of making someone’s PHP code produce a palatable result to some browser.
Creating Processes

You probably know a few of the ways to execute shell commands from PHP scripts. It usually goes something like:

exec(«php child.php»);

Not exactly thrilling stuff. But it is the cornerstone of everything I’m going to show you today. That exec() function causes a separate runtime process to spin up, so that child.php can be executed.

Please escape all command parameters, using something like escapeshellarg()!

Now, in order to manage these child processes, we need some way of…
Getting A Process ID

The exec() function only returns the results of executing the child process. It doesn’t tell us anything about the process as it is running. What we need is the PID of the child process. We can do that will a little bash trickery…

$ echo «hello world» > /dev/null

Redirecting output to /dev/null means we don’t see stuff that would usually go to stdout. See what happens when you enter this in terminal:

$ echo «hello world» > /dev/null & echo $!

What you get is the PID of the process!
Getting Process Load

So we know how to start child processes, and how to get their PID. If we want to tell how much CPU and memory load our child processes are calling, then we can use their PID to check:

$ ps -o pid,%cpu,%mem,state,start -p 123

Replace 123 with the PID of a child process and you’ll get the PID returned, along with % CPU usage, % memory usage, process state and the time the process was started. This is all very useful stuff for working out how healthy child process are, and how many child processes you can reliably spawn before overloading the system.
Killing Processes

Finally, we need a way to kill child processes. Once you know the ID of a process, killing it is simple:

$ kill -9 123

-9 is a strong suggestion to the child process that it needs to stop. You may want to avoid using it if there are clean-up operations that need to be run, or if you want the worker to be able to intercept interrupt codes and gracefully stop.

Putting It All Together

I won’t go into minute detail, but the main loop looks like this:

public function tick()
{
$waiting = array();
$running = array();

foreach ($this->waiting as $task) {
if (!$this->canRunTask($task)) {
$waiting[] = $task;
continue;
}

$binary = $this->getBinary();
$worker = $this->getWorker();
$stdout = $this->getStdOut();
$stderr = $this->getStdErr();

$pid = $this->getShell()->exec(
"{$binary} {$worker} %s {$stdout} {$stderr} & echo $!",
array(
$this->getTaskString($task),
)
);

$task->setId($pid);

$this->running[] = $task;
}

foreach ($this->running as $task) {
if (!$this->canRemoveTask($task)) {
$running[] = $task;
}
}

$this->waiting = $waiting;
$this->running = $running;

return count($waiting) > 0 || count($running) > 0;
}

This tick() method runs at short intervals. It’s the kind of “work” function that you would expect to see in a task or task manager. Each time it is run, it checks for queued (or “waiting”) tasks.

There’s a canRunTask() method (not included) which is used to see if the task can be run. This is where you could put logic about the number of tasks that the manager is permitted to run in parallel.

If a task is not allowed to be run then it is put back in the queue. If it is allowed to be run then the method spawns a new child process and returns the PID. $binary is the path to the PHP binary and $worker is a path to the worker script that unserialises a task for evaluation. We’ll see an example of that worker script shortly…

Once a child process is created, we store the PID and move the task to the “running” array. Then, for each task in the “running” array; we check to see if it can be removed. The canRemoveTask() method (not included) should return true if the process is no longer running or has stalled. It’s also a good place to add logic about whether the task has expired.

Finally, we return true if there are still queued or running child processes. This means tick() will return true until all child processes are completed. It’s best suited to a long-running process, though even if the manager script terminates, the child processes will run to completion.

Now, let’s take a look at that worker script:

if (count($argv) < 2) {
throw new InvalidArgumentException(«Invalid call»);
}

array_shift($argv);

$task = array_shift($argv);
$task = @unserialize($task);

if ($task instanceof Task) {
$handler = $task->getHandler();

$object = new $handler();

if ($object instanceof Handler) {
$object->handle($task);
}
}

The worker script needs to check to make sure a serialised task has been supplied, as an argument. $argv holds all arguments, the first of which is the name of the script PHP is executing (from the command line). If the script is called worker.php and the command being run is php worker.php foo then $argv[0] is worker.php and $argv[1] is foo.

We shift the script off the front of $argv and unserialise the task. If you want to send multi-line data then it’s probably best to base64_encode() and base64_decode() the serialised task before trying to spawn a child process.

We use @ in case the provided task string is invalid, and can’t be unserialised. Then we check the type. If the task implements the interface we expect, and it has the handler we expect, and the handler implements an interface we expect…
Doorman

Recently I put all of this together in a library, called Doorman. It wraps all of these tricks up in a simple, tested package. You can use it like this:

use AsyncPHP\Doorman\Manager\ProcessManager;
use AsyncPHP\Doorman\Task\ProcessCallbackTask;

$task1 = new ProcessCallbackTask(function () {
print «in task 1»;
});

$task2 = new ProcessCallbackTask(function () {
print «in task 2»;
});

$manager = new ProcessManager();

$manager->addTask($task1);
$manager->addTask($task2);

while ($manager->tick()) {
usleep(250);
}

You can install it in your projects with:

$ composer require asyncphp/doorman

There are some detailed docs, but it works on the principles I’ve outlined in this post.
Conclusion

I built this library so that SilverStripe queued jobs can be executed in parallel. We’re in the process of integrating it with queued jobs module, which is a fundamental part of the SilverStripe framework and CMS.

Users can issue jobs to be run in the future, and those jobs are stored in a database. Once a minute, a cron job runs a script which starts a manager. This manager fetches jobs from the database, and executes them in parallel (assuming parallel execution has been enabled).

It’s one small way in which asynchronous code execution can be used in every-day applications.

One of the challenges, when writing this library, was that we wanted to allow SilverStripe developers to be able to upgrade (with a minor version) and have all this shiny new stuff. That meant using as few extensions (like PCNTL and Pthreads) as possible, and supporting PHP 5.3.

I had loads of fun working within those constraints. Ultimately, the only feature I really missed was traits. The exec() function is just a really old part of PHP, and yet it’s all we need for this kind of execution model.

I intend to continue developing Doorman. There are already some awesome ideas being suggested by my co-workers. I’m also looking for ways to use it in my other projects, and suggesting it where I think it could be useful for others.

Пока нет комментариев

The Evolution of PHP Developer

Пока нет комментариев

PHPStan: Find Bugs In Your Code Without Writing Tests!

I really like how much productivity a web developer gains by switching from compiled languages like Java or C# to an interpreted one like PHP. Aside from the dead simple execution model (start, handle one request, and die) and a much shorter feedback loop (no need to wait for the compiler), there’s a healthy ecosystem of open-source frameworks and libraries to help developers with their everyday tasks. Because of these reasons, PHP is the most popular language for web development by far.

But there’s one downside.
When do you find out about errors?

Compiled languages need to know about the type of every variable, return type of every method etc. before the program runs. This is why the compiler needs to make sure that the program is “correct” and will happily point out to you these kinds of mistakes in the source code, like calling an undefined method or passing a wrong number of arguments to a function. The compiler acts as a first line of defense before you are able to deploy the application into production.

On the other hand, PHP is nothing like that. If you make a mistake, the program will crash when the line of code with the mistake is executed. When testing a PHP application, whether manually or automatically, developers spend a lot of their time discovering mistakes that wouldn’t even compile in other languages, leaving less time for testing actual business logic.

I’d like to change that.
Enter PHPStan

Keeping up with modern PHP practices leads to codebases where we can be sure about types of a lot of data, converging with statically typed languages, although the dynamic nature is still present. Modern PHP codebases are similar to the ones in languages people make much less fun of. Object-oriented code, dependency injection and usage of established design patterns are truly common nowadays.

Which led me to the idea of a static analysis tool for PHP that would substitute the role of the compiler from other languages. I’ve spent a lot of time working on it and I’ve been employing its various development versions checking our codebase for more than a year.
It’s called PHPStan, it’s open-source and free to use.
What it currently checks for?

Existence of classes used in instanceof, catch, typehints and other language constructs. PHP does not check this and just stays instead, rendering the surrounded code unused.
Existence and accessibility of called methods and functions. It also checks the number of passed arguments.
Whether a method returns the same type it declares to return.
Existence and visibility of accessed properties. It will also point out if a different type from the declared one is assigned to the property.
Correct number of parameters passed to sprintf/printf calls based on format strings.
Existence of variables while respecting scopes of branches and loops.
Useless casting like (string) ‘foo’ and strict comparisons (=== and !==) with different types as operands which always result in false.

The list is growing with every release. But it’s not the only thing that makes PHPStan useful.
PHPStan is fast…

It manages to check the whole codebase in a single pass. It doesn’t need to go through the code multiple times. And it only needs to go through the code you wish to analyze, e.g. the code you written. It doesn’t need to parse and analyze 3rd party dependencies. Instead, it uses reflection to find out useful information about somebody else’s code your codebase uses.

PHPStan is able to check our codebase (6000 files, 600k LOCs) in around a minute. And it checks itself under a second.
…and extensible

Even with current static typing practices, a developer can sometimes justify using dynamic features of PHP like __get, __set and __call magic methods. They allow to define new properties and methods dynamically in runtime. Normally, static analysis would complain about accessing undefined properties and methods, but there’s a mechanism for telling the engine the rules how exactly the new properties and methods are created.

This is made possible thanks to a custom abstraction over native PHP reflection which allows the user to define extensions. For more details, check the Class reflection extensions section in the README.

Some methods’ return type depends on its arguments. It can depend on what class name you pass to it or it may return object of the same class as the object you passed. This is what Dynamic return type extensions are for.

And last but not least, if you come up with a new check PHPStan could perform, you can write and use it yourself. It’s possible to come up with framework-specific rules like checking if entities and fields referenced in a DQL query exist or if all generated links in your MVC framework of choice lead to existing controllers.
Choose your level of strictness

Other tools I tried out suffer from the initial experience of trying to integrate them into existing codebases. They spill thousands and thousands of errors which discourage further use.

Instead, I looked back to how I integrated PHPStan into our codebase during its initial development. Its first versions weren’t as capable as the current one, they didn’t find as many errors. But it was ideal from the integration perspective — When I had time, I wrote a new rule, I fixed what it found in our codebase and merged the new version with the fixes into master. We used the new version for a few weeks to find errors it was capable to find and the cycle repeated. This gradual increasing of strictness proved to be really beneficial, so I set out to simulate it even with current capabilities of PHPStan.

By default, PHPStan checks only code it’s sure about — constants, instantiation, methods called on $this, statically called methods, functions and existing classes in various language constructs. By increasing the level (from the default 0 up to the current 4), you also increase the number of assumptions it makes about the code and the number of rules it checks.

You can also create your own rulesets if the built-in levels do not suit your needs.
Write less unit tests! (but focus on the meaningful ones)

You don’t hear this advice often. Developers are forced to write unit tests even for trivial code because there is an equal chance to make a mistake in it, like write a simple typo or forget to assign a result to a variable. It’s not very productive to write unit tests for simple forwarding code that you can usually find in your controllers and facades.

Unit tests come with a cost. They are code that has to be written and maintained like any other. Running PHPStan on every change, ideally on a continuous integration server, prevents these kinds of mistakes without the cost of unit tests. It’s really hard and not economically feasible to achieve 100 % code coverage, but you can statically analyze 100 % of your code.

As for your unit testing efforts, focus them on places where it’s easy to make a mistake that doesn’t look like one from the point of static analysis. That includes: complex filtering of data, loops, conditions, calculations with multiplication and division including rounding.
On the shoulders of giants

Creating PHPStan wouldn’t be possible without the excellent PHP Parser created by Nikita Popov.

PHP in 2016 has established and widely used tools for package management, unit testing and coding standards. It’s a mystery to me there isn’t yet a widely used tool for finding bugs in code without running it. So I created one that is easy enough to use, fast, extensible, and doesn’t bother you with strict requirements on your codebase while still allowing you to benefit from various checks it performs. Check out the GitHub repo to find out how you can integrate it in your project today!

It’s already used by Slevomat, Hele and Bonami —several of the most prominent Czech startups. I hope yours will be next!
If you’re a PHP developer, give PHPStan a shot. If you’re interested in various insights about software development, follow me on Twitter. If you’re interested in my consulting services on code quality, continuous delivery, hiring developers, open-source and plethora of other topics, please get in touch.

Пока нет комментариев

Who uses PHP anyway?

Each Thursday at my office we hold a one hour ‘tech talk’ after lunch to discuss something technical of interest. These tech talks are pretty informal, it’s really just a bunch of us sitting around a projector talking shop with one person facilitating the conversation. I get a lot out of them and it’s one of the reasons I really value working at Vehikl.

This week we chose Object Calisthenics as our source material and we stepped through the list of heuristics discussing why the application of these rules tend to produce cleaner more maintainable code. Afterwards, one of our junior developers sent me a message in Slack with a screenshot from the post we were working through.

Read through the whole article this time on Object Calisthenics, and saw this… How do you feel when people say this about PHP? Is it because they’re not developing web applications? Just curious, and if you have nothing to say that’s okay too

It really kinda sucks that given the value the post delivers to its readers, this is the one thing that made enough of an impact that it caused the junior dev to ask me about it.

Here’s my reply.

People shitting on PHP isn’t going to go away, it’s a symptom of a few things.

PHP has a ridiculously flat learning curve so just about anyone can write code using it, this means a lot of amateurs and ‘get it done’ developers will choose php but won’t really ever level up their skills when it comes to software development.

PHP is ridiculously easy to deploy software with. This means that all those amateurs writing less than professional code can get their apps out into the real world. There are a lot of nasty people on the internet and these types of amateur applications are ripe for malicious attacks. This tends to give PHP a bad rap when it comes to building secure and robust applications.

Since PHP is easy to write and easy to deploy, a lot of people are trying to do that but they need help. They post to stack overflow or other message boards and other amateurs help them out with solutions that they’ve made themselves which is also amateur. So the shitty code propagates quickly and lots and lots of terrible examples are posted out there for everyone to see.

People are insecure assholes looking to make themselves feel better by shitting on people they don’t know because that’s easy and seemingly without repercussions. These are generally the same people who troll the internet wasting time and taking up space instead of building useful tools and generally being productive. Note that these trolls are shitting on people who actually are building useful tools and being productive, kinda ironic (if I know what irony means).

So how do I feel when people say shitty things about PHP? I can’t say that it doesn’t bother me because it does; it doesn’t make me angry though, it just makes me kinda sad. It makes me sad because they’re taking time out of their day to point out “if you’re doing X then you’re an idiot” and that isn’t helpful in anyway. In this particular instance, I don’t think that the author was trying to be malicious, it looks like the statement was made in jest, like they’re in on the joke that people shitting on PHP is a waste of time.

The key take away though is try not to identify yourself as any kind of X developer, PHP developer, Laravel developer, Symfony developer, JavaScript developer, Vue, React, Python whatever. All that does is create tribalism and pulls people further apart which is the opposite of what we should be striving towards. The product of software development is the same no matter what tools are used to make it, many of the core ideas and philosophies are applicable to all sorts of languages, so sharing this information across disciplines works to benefit the industry as a whole. If you silo yourself, you’re doing yourself a disservice and limiting your opportunities for growth.

Further, learning multiple different programming languages only makes you a better developer. While the core ideas and philosophies may be the same, the ways in which they are applied tend be slightly different because different languages have different language constructs. This is why developers will ask “whats the idiomatic way to do X in Y?”. Learning new languages will expose you to these “new” ways of accomplishing common tasks. You can take these experiences back to other languages and see how well they apply. It’s a win win.

Пока нет комментариев