Есть шутка о типичной карьере разработчика:

1. Не использует фреймворки
2. Обнаруживает фреймворки
3. Пишет свои фреймворки
4. Не использует фреймворки

Пункт 4, конечно же, ссылается на новоприобретенные способности использовать Composer для построения собственных фреймворков, создавая их из различных компонентов третьих сторон.

Все мы знаем, что экосистема PHP не страдает от нехватки различных фреймворков, и поэтому я немного удивился, когда увидел еще один, созданный сравнительно недавно.


Он называется Webiny, и, будучи упакованным до краев усовершенствованиями и изменениями, которые они считают необходимыми, фреймворк имеет некоторые действительно интересные компоненты, на которые стоит взглянуть. В этой вводной статье мы не будем обращать внимание на структуру в целом, но осветим самые основные ее компоненты — StdLib.
Читать дальше →

Давайте подумаем о том, для каких сайтов или соцсетей было бы полезно организовать кросс-публикацию своих (или размножение чужих, строго в рамках приличия, конечно) статей. Кросс-публикация — это генерация исходного образца статьи в форматах, подходящих для публикации на двух или нескольких не связанных между собой ресурсах.

Это востребовано довольно часто по разным причинам: защита публикации от недоступности к прочтению на одном-двух ресурсах (из-за поломки сервера, бана администрацией или периода модерации), для повышения популярности своей публикации за счёт массовости (спама, но, конечно, добросовестно-дилетантского; о недобросовестном — чуть ниже), для экономии времени публикации, для сбора своих статей на каком-либо одном авторском ресурсе. Большой плюс будет и в том, что базу исходных образцов статей легко будет хранить в виде архива в копиях и восстановить при необходимости прочтения или повторных публикаций, даже если исчезли все другие прежние копии.

Несомненно, это нужно для каждого ресурса вообще, но никто (или почти никто) этим не «заморачивается», потому что чаще всего вопрос решается методом «как вывезет» — или автор хранит тексты статей в архиве, или надеется на проверенную надёжность места публикации (сайт, не предвещающий годами своего краха, Google Wave или что-нибудь попроще и малоизвестнее). Часто и сами статьи теряют актуальность. В любом случае, текстов в любом оформлении и картинок к ним в архиве бывает достаточно, чтобы вопросом дублирования публикаций не задаваться.
а как же, если грянет гром?

Все чаще и чаще я вижу, что люди уклоняются от новейших технологий, делая выбор в пользу обратной совместимости. «Мы не можем повышать минимальные требования к PHP до 5.5, потому что у нас 50% пользователей еще на 5.4» говорят они. «Нет никакого способа обновиться до Guzzle 4+, у нас бекенд на версии 3 и переделывать его слишком долго и дорого». И самый лучший аргумент от WordPress: «Мы не может придти к полному ООП, потому что большинство пользователей сидят на shared-хостингах с 5.1 или не знают про MVC».

Нонсенс.

Legacy-код – это большое НЕТ

Возможно, это спорный вывод, но я твердо уверен, нет места для legacy-кода в современных системах. Скажу несколько слов, прежде чем вы начнете точить свои вилы и зажжете факелы. Я имею ввиду, что не должно быть ни малейшего повода поддерживать старый функционал, вы добавляете обновления задним числом к старой версии только потому, что некоторые люди все еще используют ее. Даже если этих людей большинство — не делайте так.
Читать дальше →