В недавней статье про производительность Java разгорелась дискуссия на тему измерения производительности. Глядя на неё, с грустью приходится сознавать, что многие люди до сих пор не понимают, насколько сложно правильно измерить время выполнения того или иного кода. Кроме того, люди вообще не привыкли, что один и тот же код в разных условиях может выполняться существенно разное время. К примеру, вот одно из мнений:

Если мне надо узнать, "какой язык быстрее для меня на моей задаче", то я прогоню самый примитивный бенчмарк в мире. Если разница будет существенной (скажем, на порядок) — то скорее всего и на пользовательской машине все будет примерно также.

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

Имеющие дело с прикладными вычислениями знают, какие неприятности может преподносить конечная точность представления вещественных чисел в ЭВМ. Наиболее известные в этом плане проблемы — это решение чувствительных к возмущениям (так называемых, плохо обусловленных) систем линейных уравнений и нахождение собственных значений несимметричных матриц.

Когда речь идет о повседневных арифметических операциях, проблемы с конечной точностью вычислений не выглядят столь пугающими. И наилучшей проверкой того, что результат получен правильно, является сравнение значений полученных на различных точностях.

Если, например, вычисления, полученные на одинарной и удвоенной точностях совпадают, то создается чувство уверенности в результате, по крайней мере с точностью сопоставимой с одинарной. Здесь, я бы хотел привести один интересный пример, демонстрирующий, что даже в сравнительно несложной арифметической задаче подобная устойчивость при переменной точности представления чисел не может служить основанием для такой уверенности.

Сегодня Redux — это одно из наиболее интересных явлений мира JavaScript. Он выделяется из сотни библиотек и фреймворков тем, что грамотно решает множество разных вопросов путем введения простой и предсказуемой модели состояний, уклоне на функциональное программирование и неизменяемые данные, предоставления компактного API. Что ещё нужно для счастья? Redux — библиотека очень маленькая, и выучить её API не сложно. Но у многих людей происходит своеобразный разрыв шаблона — небольшое количество компонентов и добровольные ограничения чистых функций и неизменяемых данных могут показаться неоправданным принуждением. Каким именно образом работать в таких условиях?

В этом руководстве мы рассмотрим создание с нуля full-stack приложения с использованием Redux и Immutable-js. Применив подход TDD, пройдём все этапы конструирования Node+Redux бэкенда и React+Redux фронтенда приложения. Помимо этого мы будем использовать такие инструменты, как ES6, Babel, Socket.io, Webpack и Mocha. Набор весьма любопытный, и вы мигом его освоите!

Удостоверяющий центр «Let’s Encrypt» (далее просто letsencrypt) вышел из беты пару месяцев назад, пообтерся в реальных условиях, избавился от детских болезней и оброс различными клиентами. И к этому моменту выдал 5 миллионов сертификатов. Самое время внедрять, т.е. получать сертификаты на свои домены и обновлять их в автоматическом режиме. Но как внедрить так, чтобы приблизиться к любимому админскому «поставил и забыл»? Чтобы было просто получать новые сертификаты, а старые при этом обновлялись автоматом? Ну и как добавить немного безопасности в этот процесс?
Ответ под катом.

Это третья статья в цикле про создание и использование скриптов для веб-скрейпинга при помощи Node.js:

1. Web scraping при помощи Node.js
2. Web scraping на Node.js и проблемные сайты
3. Web scraping на Node.js и защита от ботов
4. Web scraping обновляющихся данных при помощи Node.js

В первой статье разбирались базовые аспекты веб-скрейпинга, такие как получение и парсинг страниц, рекурсивный проход по ссылкам и организация очереди запросов. Во второй статье разбирались анализ сайта, работающего через Ajax, тонкая настройка очереди запросов и обработка некоторых серверных ошибок.

Также во второй статье затрагивалась тема инициализации сессий, но, там речь шла о предельно простом случае, когда достаточно выполнить один дополнительный запрос и сохранить куки.

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

В прошлых статьях целью было показать весь процесс создания и использования скрипта от постановки задачи и до получения конечного результата. В этой статье большая часть аспектов веб-скрейпинга обходится стороной, а вместо этого показывается многообразие подходов к решению одной, довольно узкой задачи. Различные методы и инструменты, их плюсы и минусы, субъективные оценки, примеры кода, вот это вот всё.

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

К сожалению, большая часть информации на эту тему, которую можно найти на хабре или stackoverflow — уже устарела, поэтому я постарался превратить этот в пост в актуальный мега-гайд по шерингу страниц в соц сетях. Я рассмотрел 5 наиболее популярных в России социальных сетей: контакт, facebook, твиттер, одноклассники и мой мир. Для каждой социальной сети приведен актуальный URL для шаринга, небольшие советы и рекомендации по использованию, а также JS код, позволяющий узнать количество шеров конкретного URL в каждой из соц. сетей.

В конце статьи есть сводная таблица со всеми ссылками и кратким описанием возможностей каждой из сетей.

Случайно в потоке новостей и информации наткнулся на статью в Nature Scientific Reports. В ней представлены данные опроса 1500 учёных, посвящённого воспроизводимости результатов научных исследований. Если ранее данная проблема поднималась для биологических и медицинских исследований, где она с одной стороны объяснима (ложные корреляции, общая сложность исследуемых систем, иногда даже научный софт обвиняют), с другой стороны имеет феноменологический характер (например, мыши склонны вести себя по разному с учёными разных полов (1 и 2)).

Однако не всё гладко и с более естественнонаучными дисциплинами, такими как физика и инженерные науки, химия, экология. Казалось бы, именно эти дисциплины зиждутся на «абсолютно» воспроизводимых экспериментах, проведённых в максимально контролируемых условиях, увы, потрясающий – во всех смыслах этого слова – результат опроса: до 70% исследователей сталкивались с НЕвоспроизводимыми экспериментами и результатми, полученными не только другими группами учёных, НО и самим авторами/соавторами опубликованных научных работ!

Клонирование объектов в JavaScript довольно частая операция. К сожалению, JS не предоставляет быстрых нативных методов для решения этой задачи.

К примеру, популярная Node.JS ORM Sequelize, которую мы используем на backend-е нашего проекта, значительно теряет в производительности на предвыборке большого (1000+) количества строк, только на одном клонировании. Если вместе с этим, к примеру, в бизнес-логике использовать метод clone известной библиотеки lodash — производительность падает в десятки раз.

Но, как оказалось, не всё так плохо и современные JS-движки, такие как, например, V8 JavaScript Engine, могут успешно справляться с этой задачей, если правильно использовать их архитектурные решения. Желающим узнать как клонировать 1 млн. объектов за 30 мс — добро пожаловать под кат, все остальные могут сразу посмотреть реализацию.

Что такое иммутабельность

Неизменяемым (англ. immutable) называется объект, состояние которого не может быть изменено после создания. Результатом любой модификации такого объекта всегда будет новый объект, при этом старый объект не изменится.

Что это и зачем нужно?

Предположим у вас есть крупное новостное издание, у которого много разных типов материалов.

Для каждого типа материала существует своя модель: Topics::Article, Topics::Online, Topics::NewsItem и так далее. У них будут одинаковыми большинство полей, такие как заголовок, обложка, текст, авторы. Различие только в нескольких специфичных полях, уникальных для каждого типа топика.

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

Под катом опыт организации похожих моделей внутри Postgresql, с итогом в виде миграции на наследование таблиц. Стрельба в ногу серебряной пулей тоже присутствует, куда же без нее.

Несколько часов назад Ryan Huber из отдела безопасности Slack анонсировал некую критическую уязвимость в софте, используемом множеством сайтов. Этим софтом оказался ImageMagick — популярный пакет для обработки изображений.

Краткая информация об уязвимостях размещена на сайте imagetragick.com. Да, без названия и сайта для уязвимости не обошлось и в этот раз, хотя изначально Райан писал, что никакого пафоса, включая название и сайт, не будет. (есть ещё и твиттер)

Уязвимость была обнаружена stewie и раскрыта на hackerone 21 апреля в репорте, по всей видимости, Mail.ru, ибо примерно через неделю после этого Николай Ермишкин из команды безопасности Мэйла нашёл возможность выполнить RCE. Обо всём этом, само собой, сообщили команде разработки IM. Те 30 апреля выпустили фикс, но уже 1 мая им сообщили, что фикс немножко не фикс. Поэтому 2 мая уязвимость раскрыли в листе рассылки разработчиков пакетов, основанных на IM, а 3 мая уязвимость раскрыли публично. Спустя несколько часов после этого на openwall появилось подробное описание с примерами эксплойтов. Но об этом чуть ниже.

Большинство создают внешние ссылки через target="_blank" и не знают одного интересного нюанса — страница, на которую мы попадем таким образом, получит частичный контроль над ссылающейся на нее страницей через js свойство window.opener.

Через window.opener.location мы сможем сделать редирект на, к примеру, фишинговую страницу. Это своего рода tabnabbing, только более продвинутый. Так как жертва меньше всего ожидает подмены страницы, в открытой ранее, доверенной вкладке браузера.

Что-то много развелось в последнее время статей про минусы битрикса, и их опровержений. Раз уж пошла такая пьянка, то и я добавлю свои 5 копеек.
В комментариях к статьям писали, что не хватает конкретики, примеров, более глубокого обзора.

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

Кто я такой? Да в общем-то, обычный разработчик. Работаю с битриксом с ноября 2010 года (5.5 лет). Работаю только с битриксом, не сделал ни одного коммерческого проекта на других CMS, не использовал фреймворки в создании сайтов. По роду деятельности я занимаюсь в основном интернет-магазинами, их созданием, поддержкой и развитием.

Abstract: описание видов ребута, рассказ про sysrq, ipt_SYSRQ, ipmi, psu.

Как перезагрузить сервер? — Это вопрос, который обычно задают ну очень начинающим пользователям, которые путаются между halt, shutdown -r, reboot, init 6 и т.д.

Опытный администратор уточнит вопрос: «а что с сервером не так?» Разные виды отказов серверов требуют разных видов ребута — и неверно выбранный вариант приведёт к тяжелейшим последствиям, из которых визит в веб-морду IPMI/DRAC/iLO с целью «доперезагрузить» будет самым лёгким. Самым тяжёлым в моей личной практике была командировка эникейщика в соседний город. С целью «нажать ребут» на одиноко стоящем сервере.

В этой статье: что мешает серверу перезагрузиться и как ему помочь.

Начнём с теории ребута.

При выключении или перезагрузке сервера менеджер инициализации (в большинстве современных дистрибутивов — systemd, в эксцентричной Ubuntu 14.04 до сих пор upstart, в архаичном хламе — sysv-init) в определённом порядке посылает всем демонам команду «выключись». И большинство демонов (например, СУБД, вроде mysql) знают, как выключаться правильно. Например, закончить все транзакции, сохранить все несохранённые данные на диск и т.д. Для in-memory СУБД, наподобие redis, это и вовсе может быть критичным: не сохранил — потерял.

Старые системы иницализации ждали неограниченно долго каждый из инит-скриптов. Например, если «шутник» добавил вам в «stop» веточку «sleep 3600», то ваш сервер будет перезагружаться час с хвостиком. А если там цифра поболе, или просто программа, которая не хочет завершаться, то и ребут никогда не закончится.

К сожалению, не у всех есть браузер/устройство, поддерживающие flexbox. Это руководство в виде шпаргалки, в котором предлагаются альтернативы обратной совместимости для свойств flexbox.

Хотя некоторый CSS-код в этом руководстве, возможно, покажется очевидным, я собираюсь бросить вызов flexbox, а также предложить простые решения проблем, которые возникали, пока он не обрёл популярность.

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

PHP имеет всего одну структуру данных для управления всем. array — сложный, гибкий, гибридный, сочетает в себе поведение list и linked map. Но мы используем его для всего, потому что PHP придерживается прагматичного подхода: иметь предельно правильный, здравый и реалистичный способ решения проблемы, исходящий из практических, а не теоретических рассуждений. array позволяет делать работу, хотя о нем и так много рассказывают на лекциях по информатике. Но, к сожалению, с гибкостью приходит и сложность.

Последний релиз PHP вызвал большое оживление в сообществе. Мы не могли дождаться того, чтобы начать использовать новые возможности и почувствовать вкус ~2х прироста производительности. Одна из причин, почему это случилось — структура array была переработана. Но массивы все также придерживаются принципа «оптимизировано для всего; оптимизировано для ничего», еще не все идеально, есть возможности для совершенствования.

А что насчет структур данных SPL?

К сожалению… они ужасны. Раньше, до PHP7, они предлагали _некоторые_ преимущества, но сейчас мы дошли до точки, когда использование SPL не имеет практического смысла.

Почему мы не можем просто поправить и улучшить их?

Да, мы могли бы, но я считаю, что их дизайн и реализация настолько бедны, что лучше бы найти более современную замену.

«SPL data structures are horribly designed.»
— Anthony Ferrara

---

Введение: php-ds — расширение для PHP7, добавляющее структуры данных. Этот пост кратко охватывает поведение, производительность и преимущества каждой из них. Также в конце вы найдете список ответов на ожидаемые вопросы.

Github: https://github.com/php-ds
Пространство имен: Ds\
Интерфейсы: Collection, Sequence, Hashable
Классы: Vector, Deque, Stack, Queue, PriorityQueue, Map, Set

(у учебника по Основам React вышло второе издание, Redux-учебник в процессе обновления)

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

Курс про Redux попал в официальную документацию.

Оба руководства бесплатны и выложены на gitbook (можно скачать PDF, ePub, mobi).

В текстах нарочно участвуют термины переведенные на русский (например, состояние), английские (state), либо английский термин написанный по-русски — стейт. Считаю это допустимым, и даже более того, удобным для читателя.

О чём речь?

Всё чаще возникает задача научить frontend-приложение работать в автономном режиме. Это значит придать web-приложению свойство mobile- или desktop-программы — функционировать в отсутствии связи с Интернет, а также в случае отказа сервера.

Цель — оградить пользователя от проблем соединения на его устройстве. Как было бы обидно не сохранить созданные в google docs таблицы из-за потери wi-fi в ближайшем фастфуде!

Для этого нужно инициализировать приложение в браузере и затем закэшировать ресурсы, минимально необходимые для функционирования. После этого приложение возможно запустить из кэша в случае недоступности сервера.

Решение задачи заключается в следующем:

Продолжаем перевод серии статей об обработки исключений в C++

1 часть
2 часть

C++ exceptions под капотом: поиск верного landing pad

Это уже 15-я глава в нашей длинной истории. Мы уже изучили достаточно много о том, как работают исключения, и даже имеем написанную работающую собственную персональную функцию с небольшим количеством рефлексии, определяющей где находится catch-блок (landing pad в терминах исключений). В прошлой главе мы написали персональную функцию, которая может обрабатывать исключения, но она всегда подставляет только первый landing pad (т.е. первый же catch-блок). Давайте улучшим нашу персональную функцию, добавив возможность выбирать правильный landing pad в функции с несколькими catch-блоками.