¯\_(ツ)_/¯
Хуки жизненного цикла (lifecycle hooks) — важная часть любого серьёзного компонента. Нам часто нужно знать, когда компонент был создан, добавлен в DOM, обновлён или уничтожен. Хуки жизненного цикла показывают нам, как работает «за кулисами» выбранная библиотека. Они часто вызывают у новичков трепет или беспокойство. К счастью, понять принцип работы хуков несложно, см. схему:
Каждый год мы стараемся тщательно измерять производительность разных версий PHP и HHVM на различных платформах. В этом году мы измерили четыре версии PHP и HHVM на 20 платформах/конфигурациях, включая WordPress, Drupal, Joomla!, Laravel, Symfony и многие другие. Также мы протестировали популярные решения для электронной коммерции вроде WooCommerce, Easy Digital Downloads, Magento and PrestaShop.
Мы всегда рекомендовали пользователям WordPress не пренебрегать преимуществами свежайших поддерживаемых версий PHP. Не только ради безопасности, но и ради повышения производительности. Причём речь идёт не только о WordPress, это по большей части справедливо для всех платформ. И сегодня мы продемонстрируем, как PHP 7.2 одерживает сокрушительную победу!
Предлагаем вашему вниманию коллекцию полезных CSS-сниппетов, в которых вы можете разобраться за 30 секунд, а то и быстрее.
Я знаю, о чём вы подумали: «Ещё одна скучная статья про DRY? Нам их мало, что ли?».
Возможно, вы правы. Но я встречаю слишком много разработчиков (junior и senior), применяющих DRY так, словно они охотятся на ведьм. Либо совершенно непредсказуемо, либо везде, где можно. Так что, судя по всему, в интернете никогда не будет достаточно статей о принципе DRY.
Если кто не знает: принцип DRY — это "Don't Repeat Yourself" (не повторяйся), и впервые о нём упомянуто в книге The Pragmatic Programmer. Хотя сам по себе этот принцип был известен и применялся задолго до появления книги, однако в ней ему было дано название и точное определение.
Итак, без лишних рассуждений отправимся в путешествие по чудесной стране DRY!
Новые системы формирования изображений, микроскопы и видеоматрицы генерируют цифровые изображения, опираясь на компьютерные вычисления, а не на традиционные линзы.
Ещё средневековые ремесленники умели создавать стеклянные линзы и искривлённые зеркала для проецирования изображений. Такие конструкции использовались для изготовления микроскопов, камер-обскур, телескопов и прочих инструментов, позволяющих нам лучше увидеть очень маленькие и большие объекты, расположенные вдалеке и поблизости, на Земле и в небесах. Следующая революция в формировании изображений произошла примерно в середине XIX века: была изобретена фотография. Появилась возможность запечатлевать «остановленные моменты», воспроизводить их и тиражировать. Сегодня эра химической фотографии подходит к завершению, расцветает новая эпоха — цифровое формирование изображений. Его корни лежат в технологии телевидения, но мы будем считать началом эпохи 1975 год, когда появилась первая цифровая фотокамера. Сегодня миллиарды веб-камер и камер в мобильных телефонах по всему миру снимают более триллиона изображений в год, и многие из них сразу же выкладываются в интернет. Несмотря на взрывной рост количества, разнообразия и способов применения систем формирования изображений, задачи инженеров-оптиков остаются по большей части неизменными: создавать высококачественное оптическое изображение, как можно точнее передающее снимаемую сцену — чтобы «выглядело хорошо».
Нейросети используются уже довольно широко. Чат-боты, распознавание изображений, преобразование речи в текст и автоматические переводы с одного языка на другой — вот лишь некоторые сферы применения глубокого обучения, которое активно вытесняет другие подходы. И причина в основном в более широких возможностях обобщения при обработке больших объёмов данных.
Недавно я выступал в Анахайме (Калифорния) с докладом «Industry Lifecycles». Планировалось, что это будет коротким изложением моей публикации в блоге с небольшой порцией материала из другой моей недавней публикации об игровой экономике. Она наделала довольно много шума. На форумах развернулись дискуссии, в которых часто выражался скепсис в отношении представленных мной данных и сделанных выводов. Изначально статья была ответом на комментарии на разных сайтах, которые я собрал в виде вопросов-ответов. То есть я не опирался на единое исследование.
Недавно я осознал нехватку вводных обучающих материалов о современной сетевой балансировке и проксировании. Я подумал: «Почему так? Балансировка нагрузки — одна из ключевых концепций для построения надёжных распределённых систем. Ведь должна быть доступна качественная информация об этом?» Я поискал и обнаружил, что информации мало. Статьи в Википедии о балансировке и прокси-серверах содержат обзоры некоторых концепций, но не могут похвастаться последовательным описанием предмета, особенно в том, что касается современных микросервисных архитектур. Поиск в Google информации о балансировке в основном возвращает сайты вендоров, заполненные модными терминами и скупые на подробности.
В этой статье я постараюсь восполнить нехватку постепенного введения в современную сетевую балансировку и проксирование. По правде сказать, это объёмная тема, достойная целой книги. И чтобы статья не получилась безразмерной, я постарался ряд сложных задач подать в виде простого обзора.
Долгое время меня интересовала тема машинного обучения. Меня удивляло, как машины могут обучаться и прогнозировать безо всякого программирования — поразительно! Я всегда был очарован этим, однако никогда не изучал тему подробно. Время — ресурс скудный, и каждый раз, когда я пытался почитать о машинном обучении, меня заваливало информацией. Освоение всего этого казалось трудным и требовало много времени. Также я убедил себя, что у меня нет необходимых математических знаний даже для того, чтобы начать вникать в машинное обучение.
Но в конце концов я решил подойти к этому иначе. Мало-помалу я буду пытаться воссоздавать в коде разные концепции, начиная с основ и постепенно переходя к более сложным, стараясь охватить как можно больше базовых вещей. В качестве языка я выбрал Go, это один из моих любимых языков, к тому же я не знаком с традиционными для машинного обучения языками вроде R или Python.
Несколько лет назад я разрабатывал для одного большого телекома новую информационную систему. Нам приходилось взаимодействовать со всё нарастающим количеством веб-сервисов, открываемых более старыми системами или бизнес-партнёрами. Как вы понимаете, мы получили добрую порцию SOAP-ада. Заумные WSDL, несовместимые библиотеки, странные баги… Где только возможно мы старались продвинуть — и использовать — простые RPC-протоколы: XMLRPC или JSONRPC.
Приближается 2018 год, и технари — в частности веб-разработчики — должны отбросить многие старые методики и верования в сфере разработки защищённых PHP-приложений. Особенно это относится ко всем, кто не верит, что такие приложения вообще возможны.
Это руководство — дополнение к электронной книге PHP: The Right Way с сильным уклоном в безопасность, а не общие вопросы программирования на PHP (вроде стиля кода).
При создании PHP-приложения или библиотеки обычно у вас есть три вида зависимостей:
Как управлять этими зависимостями?
Я большой поклонник Prometheus и Grafana. Поработав SRE в Google, я научился ценить хороший мониторинг и за прошедший год предпочитал пользоваться комбинацией этих инструментов. Я использую их для мониторинга своих личных серверов (black-box и white-box мониторинг), внешних и внутренних событий Euskal Encounter, для мониторинга клиентских проектов и много другого. Prometheus позволяет очень просто писать кастомные модули экспорта для мониторинга моих собственных данных, к тому же вполне можно найти подходящий модуль прямо из коробки. Например, для создания симпатичной панели имеющихся метрик Encounter-событий мы используем sql_exporter.
Все знают о стандартной аутентификации пользователя в приложении. Это олдскульная процедура регистрации — пользователь вводит адрес почты, пароль и т. д., — а затем при входе мы сравниваем почту и/или пароль с сохранёнными данными. Если совпадает, даём доступ. Но времена изменились, и сегодня появилось много других методов аутентификации. Если хотите оставаться востребованным программистом/разработчиком в этом меняющемся, словно калейдоскоп, мире разработки ПО, то вы должны знать обо всех этих новых методах.
Нельзя отрицать, что в любых приложениях и ОС «аутентификация» — крайне важный элемент обеспечения сохранности пользовательских данных и регулирования доступа к информации. Чтобы понять, какой метод аутентификации для вас лучше, нужно разбираться в достоинствах и недостатках всех методов, а также неплохо представлять, как же они работают.
Здесь я постараюсь рассказать о большинстве распространённых сегодня методов аутентификации. Это не подробное техническое руководство, а лишь способ познакомить вас с ними. Хотя методы описаны с учётом применения в вебе, эти идеи можно реализовать и в других условиях.
В предыдущей статье я описал несколько алгоритмов эволюционных стратегий (evolution strategies, ES), помогающих оптимизировать параметры функции без необходимости явно вычислять градиенты. При решении задач обучения с подкреплением (reinforcement learning, RL) эти алгоритмы можно применять для поиска подходящих наборов параметров модели для агента нейросети (neural network agent). В этой статье я расскажу об использовании ES в некоторых RL-задачах, а также опишу методы поиска более стабильных и устойчивых политик.
Сервис-ориентированная архитектура (service-oriented architecture, SOA) придумана в конце 1980-х. Она берёт своё начало в идеях, изложенных в CORBA, DCOM, DCE и других документах. О SOA написано много, есть несколько её реализаций. Но, по сути, SOA можно свести к нескольким идеям, причём архитектура не диктует способы их реализации:
SOA — это набор архитектурных принципов, не зависящих от технологий и продуктов, совсем как полиморфизм или инкапсуляция.
Когда я начинал карьеру разработчика, то очень удивился, прочитав фразу, которую приписывают Филу Карлтону (Phil Karlton): «В информатике есть лишь две сложности: инвалидация кеша и присвоение имён». Я отнёсся к этому недоверчиво, поскольку не понял сути фразы. Но немного позже я начал понимать.
Я хочу рассказать о проблеме, с которой мы столкнулись не так давно в нашей production-инфраструктуре. Сразу после успешного развёртывания при обновлении страниц, изменённых новым релизом, какое-то время не отображался новый код. Вообще-то такое далеко не редкость для веб-приложений, написанных на PHP. Мы сталкивались с подобным и раньше, а после перехода на новую production-среду проблема стала заметнее. Поэтому мы решили заняться расследованием.
Некоторое время назад я начал делать утилиту, которая упростила бы мне жизнь. Она называется gomodifytags. Утилита автоматически заполняет поля структурных тегов (struct tag) с помощью имён полей. Пример:
Эта утилита облегчает управление многочисленными полями структуры. Она умеет добавлять и удалять теги, управлять их опциями (например, omitempty), определять правила трансформации (snake_case, camelCase и пр.) и многое другое. Как эта утилита работает? Какие Go-пакеты она использует? Наверное, у вас есть много вопросов.
В этой очень длинной статье я подробно расскажу о том, как написать и собрать такую утилиту. Здесь вы найдёте много советов и хитростей, а также кода на Go.
Налейте кофе и начинайте читать!
В C++ в изобилии встречаются подводные камни, ловушки, оговорки и западни. В подземельях С++ скрываются многочисленные подозрительные персонажи. Хэллоуин — правильное время для встречи с некоторыми представителями этой многочисленной своры чудовищ.