Печально, что it-сообщество ввязалось в политические игры.
И самое неприятное, что авторы опенсорс проектов позволяют себе размещение подобных баннеров, не спрашивая мнение соавторов, и не проявляя уважение к разработчикам, которые будут работать с этими инструментами.
Есть такой сегмент заказов, где клиент не хотел бы, чтобы его дорогой подарок с букетом был доставлен произвольным курьером, на первой попавшейся машине.
Доставка - это "подача", и для некоторых важно, кто и каким образом будет доставлять подарок.
Согласен в комментариями выше - функционал действительно не помешает, и есть ряд задач, для которые приемлемо выполнение арифметических выражений над объектами, работа с теми же множествами, длинная арифметика и прочее..
Что касается варианта реализации: с одной стороны, хорошо бы придерживаться тех. же магических методов, но с другой стороны: 1. будут сложности с неймингом операторов. 2. кол-во маг. методов будет сильно возрастет.
Органика зависит от множества факторов, в т.ч. и поведенческие факторы, используя рекламу, вы увеличиваете трафик, в зависимости от от рекламы, к вам может приходить целевая аудитория, которая увеличивает поведенческие факторы, так и не целевую аудиторию, из-за которой возрастает процент отказов. В результате реклама косвенно влияет на органику.
Спасибо, обратили внимание на достаточно важные моменты.
Единственное, заголовок "Практические рекомендации по работе с Docker для Python-разработчиков" можно заменить, например на "Практические рекомендации по работе с Docker на примере с Python". Т.е. основной текст статьи несет в себе информацию по Docker полезную не только python-разработчикам.
Достаточно часто замечаю, в различных примерах используют объединение типов, таким же образом, как и вы:
public function getAudio() : bool | string;
но сам тип bool используется только для возвращения false. Если же ваш метод вернет true, то вся логика приложения будет нарушена. Как минимум мы можете использовать ?string и возвращать null.
Читал обе книжки, могу добавить, что первая книга подходит именно для изучения паттернов, где описаны проблемы при разработке, и постепенно рефакторингом приходят в конечном итоге к решению проблемы с помощь определённого паттерна.
А вторая книга - подходит в качестве справочника.
я не утверждаю, что паттерны проектирования безусловно необходимы, и что если человек не прочитал паттерны Банды Четырех, то он не может называться разработчиком
Паттерны проектирования - не серебряная пуля, но их знание по-моему необходимо для разработчиков, которые работают в команде. Т.к. зная паттерны - вы владеете терминами, под которыми понимаете одно и тоже решение, и это очень упрощает при коммуникации.
Вам потом проще кому-то сказать "возьми библиотеку http-клиента, и напиши к ней декоратор логов" или "для использования такой библиотеки-логирования в нашем проекте, необходимо написать к нему адаптер".
Простите, но зачем ?
У каждого инструмента должны быть область применения, в которой она лучше подходит для решения своих задач.
Если для личных экспериментов - забавы ради,
то наверное, стоит в таких статьях оставлять соответствующее примечание.
Начинающие frontend разработчики сейчас подумают о страшных вещах.. уже не начали это делать))
Есть точное определение этому подходу — замести под ковер.
Печально, что it-сообщество ввязалось в политические игры.
И самое неприятное, что авторы опенсорс проектов позволяют себе размещение подобных баннеров, не спрашивая мнение соавторов, и не проявляя уважение к разработчикам, которые будут работать с этими инструментами.
На мой взгляд основные события в мире php за текущий год — это,
Формирование фонда — PHP Foundation.
Релиз PHP 8.*
Активная движуха в комьюнити, которую организуют PHP Channel, PHP Point, Skyeng ITeam, Badoo Tech и т.д.
Интересно, спасибо!
Логистика почти всегда большая боль..
«что дальше?»
Есть такой сегмент заказов, где клиент не хотел бы,
чтобы его дорогой подарок с букетом был доставлен произвольным курьером, на первой попавшейся машине.
Доставка - это "подача", и для некоторых важно, кто и каким образом будет доставлять подарок.
Согласен в комментариями выше - функционал действительно не помешает, и есть ряд задач, для которые приемлемо выполнение арифметических выражений над объектами, работа с теми же множествами, длинная арифметика и прочее..
Что касается варианта реализации:
с одной стороны, хорошо бы придерживаться тех. же магических методов,
но с другой стороны:
1. будут сложности с неймингом операторов.
2. кол-во маг. методов будет сильно возрастет.
мне кажется, вариант с operator лучше.
Органика зависит от множества факторов, в т.ч. и поведенческие факторы,
используя рекламу, вы увеличиваете трафик, в зависимости от от рекламы, к вам может приходить целевая аудитория, которая увеличивает поведенческие факторы, так и не целевую аудиторию, из-за которой возрастает процент отказов.
В результате реклама косвенно влияет на органику.
Спасибо за статью!
Подскажите, а рассматривали еще какие-то варианты параллельных запросов к сервисам,
например, через очереди ?
Спасибо, обратили внимание на достаточно важные моменты.
Единственное, заголовок "Практические рекомендации по работе с Docker для Python-разработчиков" можно заменить, например на "Практические рекомендации по работе с Docker на примере с Python".
Т.е. основной текст статьи несет в себе информацию по Docker полезную не только python-разработчикам.
Достаточно часто замечаю, в различных примерах используют объединение типов, таким же образом, как и вы:
но сам тип bool используется только для возвращения false.
Если же ваш метод вернет true, то вся логика приложения будет нарушена.
Как минимум мы можете использовать
?stringи возвращатьnull.Кстати, я сейчас сделал более бесполезную вещь — написал кликер для стометровки на чекбоксах.
Иногда бывают задачи от клиентов, которые на много бесполезнее, чем эти бесполезные сайты :)
Честно говоря, на tutrial вообще не тянет.
Только в двух абзацах (2-3 предложения) главы "Как это сделано в Roxy-WI" описано, как это устроено.
У меня нет цели оставлять токсичный комментарий, просто меня заголовок заинтересовал,
а в результате абсолютно никакой информации не получил.
Читал обе книжки, могу добавить, что первая книга подходит именно для изучения паттернов, где описаны проблемы при разработке, и постепенно рефакторингом приходят в конечном итоге к решению проблемы с помощь определённого паттерна.
А вторая книга - подходит в качестве справочника.
Паттерны проектирования - не серебряная пуля, но их знание по-моему необходимо для разработчиков, которые работают в команде. Т.к. зная паттерны - вы владеете терминами, под которыми понимаете одно и тоже решение, и это очень упрощает при коммуникации.
Вам потом проще кому-то сказать "возьми библиотеку http-клиента, и напиши к ней декоратор логов" или "для использования такой библиотеки-логирования в нашем проекте, необходимо написать к нему адаптер".