Предыдущие публикации:

→ Пудра для мозга или как сделать порошок для посудомойки в 9,7 раз дешевле
→ DIY порошок для посудомойки: разбираем промышленные средства и улучшаем рецепт

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

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

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

Человек работающий и музыка

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

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

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

Занимаясь программированием рендеринга графики, мы живём в мире, в котором обязательны низкоуровневые оптимизации, чтобы добиться GPU-фреймов длиной 30 мс. Для этого мы используем различные методики и разработанные с нуля новые проходы рендеринга с повышенной производительностью (атрибуты геометрии, текстурный кеш, экспорт и так далее), GPR-сжатие, скрывание задержки (latency hiding), ROP…

В сфере повышения производительности CPU в своё время применялись разные трюки, и примечательно то, что сегодня они используются для современных видеокарт ради ускорения вычислений ALU (Низкоуровневая оптимизация для AMD GCN, Быстрый обратный квадратный корень в Quake).


Быстрый обратный квадратный корень в Quake

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

Эта статья — не исчерпывающее хардкорное руководство по железу. Это всего лишь введение, напоминание, свод базовых принципов написания эффективного кода для CPU. Я хочу «показать, что низкоуровневое мышление сегодня всё ещё полезно», даже если речь пойдёт о процессорах, которые я мог бы добавить.

В статье мы рассмотрим кеширование, векторное программирование, чтение и понимание ассемблерного кода, а также написание кода, удобного для компилятора.

Задача: отправка и обработка файлов с помощью FormData и FileReader в форме со всеми возможными полями и пересылкой дополнительных параметров для каждого поля c объединением всех данных формы (кроме файлов и системных полей) в общий массив.

Поддержка: все современные браузеры, IE 10+.

Плагины: jquery-2.1.4

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

Зачем нужно адаптировать письма для мобильных устройств

Значительная часть аудитории различных компаний, занимающихся email-маркетингом, просматривают письма на мобильных устройствах. Во время исследования Campaign Monitor от 2011 года выяснилось, что почти 20% открытий писем происходили на смартфонах и планшетах — в 2009 году эта цифра находилась на уровне всего в 4%. Почти 90% от этих открытий осуществлялись на устройствах под iOS. Сейчас цифры еще выше.

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

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



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

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

Будучи человеком, который продает настройки таргетинга и услуги по продвижению как во Вконтакте, Фейсбуке, Инстаграмме, Youtube и немножечко SEO, я с ним полностью согласен. Более того, уверен, что это занятие доступно абсолютно любому человеку, имеющему хоть небольшие аналитические способности. И если у вас они есть (раз уж читаете Хабр, то с большой вероятностью есть), добро пожаловать под кат. Возможно, однажды вам придется самостоятельно разместить рекламу в соц сетях, или, как минимум, оценить адекватность работы того, кто попросит у вас за эту настройку деньги. И я искренне надеюсь, что вам пригодится эта серия публикаций. Итак, поехали!

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

Благодаря стараниям разработчиков, эта проблема была успешно пофикшена в течение нескольких дней, но на этом наша сага не закончена. Напомню, что согласно официальному прайс-листу Хабра стоимость 1000 показов банера для пользователей ресурса колеблется от 400 до 550 рублей. За гео-таргетинг по Москве и Питеру придется доплатить 20 и 15 процентов соответственно.

Но всё еще существует способ рекламироваться на эту же аудиторию платя 30-150 рублей за тысячу показов. Давайте думать, как исправить и эту фичу:

В продолжении статьи "Идеальный каталог, набросок архитектуры", я покажу на примерах как можно использовать предложенную структуру БД для хранения произвольных данных и выполнения произвольных поисков по этим данным. Скрипты лежат в репозитории — universal_data_catalog_idea.

Приглашаю под кат, тех кому интересно посмотреть на эти скрипты с авторскими комментариями.

На конференции HighLoad++ 2016 руководитель разработки «М-Тех» Вадим Мадисон рассказал о росте от системы, для которой сотня микросервисов казалась огромным числом, до нагруженного проекта, где пара тысяч микросервисов — обыденность.

Тема моего доклада — то, как мы запускали в продакшн микросервисы на достаточно нагруженном проекте. Это некий агрегированный опыт, но поскольку я работаю в компании «M-Tех», то давайте я пару слов расскажу о том, кто мы.

Если коротко, то мы занимаемся видеоотдачей — отдаём видео в реальном времени. Мы являемся видеоплатформой для «НТВ-Плюс» и «Матч ТВ». Это 300 тысяч одновременных пользователей, которые прибегают за 5 минут. Это 300 терабайт контента, который мы отдаем в час. Это такая интересная задача. Как это всё обслужить?

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

Александр Лебедев выражает всю нетривиальность дизайна REST API. Это — расшифровка доклада Highload++ 2016.

Всем здравствуйте!

Поднимите руку те, кто фронтенд разработчик в этом зале? Кто мобильный разработчик? Кто бэкенд разработчик?

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

Пару слов о себе

Кто я такой? Чем занимаюсь?

Я фронтенд team lead компании «Новые Облачные Технологии». Последние 5 лет я писал веб фронтенд, который работает с REST API и который должен для пользователя работать быстро. Я хочу поделиться опытом о том, какие API должны быть, которые позволяют этого добиться.

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

Алексей Акулович объясняет жизненный путь высоконагруженного проекта на PHP. Это — расшифровка Highload ++ 2016.

Меня зовут Лёша, я пишу на PHP.

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

Начнём.

Вы уже используете прогрессивную загрузку? А как насчёт технологий Tree Shaking и разбиения кода в React и Angular? Вы настроили сжатие Brotli или Zopfli, OCSP stapling и HPACK-сжатие? А как у вас обстоят дела с оптимизацией ресурсов и клиентской части, со вложенностью CSS? Не говоря уже о IPv6, HTTP/2 и сервис-воркерах.

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

И ведь это только фронтенд, а есть ещё бекенд и база данных. Везде разные законы и логика. Подробнее об эксплуатации highload-проектов в докладе Николая Сивко (okmeter.io) с конференции HighLoad++ Junior.

Валентин Васильев (Machinio.com)

Что же такое Browser Fingerprint? Или идентификация браузеров. Очень простая формулировка — это присвоение идентификатора браузеру. Формулировка простая, но идея очень сложная и интересная. Для чего она используется? Для чего мы хотим присвоить браузеру идентификатор?

• Мы хотим учитывать наших пользователей. Мы хотим знать, пришел ли пользователь к нам первый раз, пришел он во второй раз или в третий. Если пользователь пришел во второй раз, мы хотим знать, на какие страницы он заходил, что он до этого делал. С анонимными пользователями это невозможно. Если у вас есть система учета записей, пользователь логинится, мы все про него знаем — мы знаем его учетную запись, его персональные данные, мы можем привязать любые действия к этому пользователю. Здесь все просто. В случае с анонимными пользователями все становится гораздо сложнее.
  

Ныне FreePBX — крайне популярная обертка к Asterisk, который не менее популярен как телефонный цифровой сервер. Отдельный плюс таких систем — возможность развернуть на недорогих vds-серверах (я клиентам разворачиваю на vds стоимостью 299р/месяц, 2Гб ОЗУ, 2,8 GHZ процессор, 20Гб место на диске). Такая система запросто обслуживает 10-20 одновременных звонков, пишет аудио, позволяет внедрять телефонную часть бизнес-процесса в остальную логику (взаимодействие с crm, звонки с сайта/браузера, автоинформаторы на основе данных в субд, выяснение поисковых данных по номеру о звонящем за доли секунд, даже распознавание и синтезация речи!).

Все бы хорошо, но при «обильных» обзвонах через полмесяца заканчивается место на диске. Те самые 20Гб улетают у некоторых клиентов за неделю! А хостер, к сожалению, не предоставляет fuse на тарифах OpenVZ, который крайне необходим для работы «реалтайм — сетевых файловых систем», вроде ftpfs.

Ниже изложу мой комплекс мер по борьбе с проблемой. Работать будем с каталогом /var/spool/asterisk/monitor, где лежат .wav файлы, заботливо разложенные asterisk по каталогам: год, месяц и день.

Хочу поделиться с Вами одним из вариантов настройки и использования Postfix’a, когда в нашем распоряжении есть несколько IP с которых можно вести доставку писем.

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



Прошу пожаловать под кат, кому эта тема интереса.

WordPress — это удобная блог-платформа для публикации статей и управления ими, на которой базируется огромное число различных сайтов. Из-за своей распространенности эта CMS уже давно является лакомым куском для злоумышленников. К сожалению, базовые настройки не обеспечивают достаточного уровня защиты, оставляя многие дефолтные дырки незакрытыми. В этой статье мы пройдем типичным путем «типового» взлома сайта на Wordpress, а также покажем как устранить выявленные уязвимости.

Уже много статей в интернете есть про sql триггеры, но добавлю еще одну с адекватными примерами, что бы закрепить материал для тех, кто «в теме» и что бы лучше понять материал тем, кто только начал постигать «дзен sql». Заодно и создам дискуссию по теме.

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

Привет Хабр! Хочу рассказать в статье мой опыт реализации бизнес логики (БЛ) в MySQL.

Есть разные мнения насчёт вопроса стоит ли хранить БЛ в базе. Я много лет работаю с Oracle и философия Oracle подразумевает, что БЛ в БД это Best Practices. Приведу пару цитат Тома Кайта:

Tom Kyte. Effective Oracle by Design
If the database does something, odds are that it does it better, faster and cheaper, that you could do it yourself

Том Кайт. Oracle для профессионалов.
Прежде чем начать, хотелось бы объяснить вам мой подход к разработке. Я предпочитаю решать большинство проблем на уровне СУБД. Если что-то можно сделать в СУБД, я так и сделаю. [...] Мой подход состоит в том, чтобы делать в СУБД все, что возможно. [...]
При разработке приложений баз данных я использую очень простую мантру:

• если можно, сделай это с помощью одного оператора SQL;
• если это нельзя сделать с помощью одного оператора SQL, сделай это в PL/SQL;
• если это нельзя сделать в PL/SQL, попытайся использовать хранимую процедуру на языке Java;
• если это нельзя сделать в Java, сделай это в виде внешней процедуры на языке C;
• если это нельзя реализовать в виде внешней процедуры на языке C, надо серьезно подумать, зачем это вообще делать...

В то же время в среде web-разработчиков приходится слышать мнения, что БЛ в БД это чуть ли не антипаттерн. Но я не буду останавливаться на вопросе стоит ли реализовывать БЛ в БД. Пусть каждый решает сам. Тем, кто хочет посмотреть, что у меня получилось в свете не столь обширного (по сравнению с Oracle) инструментария MySQL, добро пожаловать под кат.