В одной из статей опубликованных на хабре я в комментах вычитал, что на gitlab.com есть копии deepNude, чисто из любопытства нашел ее и сделал форк «на всякий случай». Через 3 часа после этого я не смог запушить код, т.к. улетел в бан…

О технологии websocket часто рассказывают страшилки, например что она не поддерживается веб-браузерами, или что провайдеры/админы глушат трафик websocket — поэтому ее нельзя использовать в приложениях. С другой стороны, разработчики не всегда заранее представляют подводные камни, которые имеет технология websocket, как и любая другая технология. По поводу мнимых ограничений сразу скажу, что технологию websocket сегодня поддерживают 96.8% веб-браузеров. Вы можете сказать, что оставшиеся за бортом 3,2% — это много, это миллионы пользователей. Я с Вами вполне соглашусь. Только все познается в сравнении. Тот же XmlHttpRequest, который все и уже не первый год используют в технологии Ajax, поддерживается 97.17% веб-браузеров (не сильно больше, правда?), а fetch — вообще, 93.08% веб-браузеров. В отличие от websocket, такой процент (а раньше он был еще меньше) уже давно никого не останавливает при использовании технологии Ajax. Так что использовать в настоящее время fallback на long polling не имеет никакого смысла. Хотя бы потому, что веб-браузеры, которые не поддерживают websocket — это те же самые веб-браузеры, которые не поддерживают XmlHttpRequest, и в реальности никакого fallback не произойдет.

Вторая страшилка, про бан на websocket со стороны провайдеров или админов корпоративных сетей — также необоснована, так как сейчас все используют протокол https, и понять что открыто соединение websocket (не взломав https) невозможно.

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

«Пентестер» — слово вообще-то не русское, заимствованное. Что приходит на ум людям не из ИТ, боюсь представить. Поэтому мы себя «на Руси» гордо зовём «специалисты по тестированию на проникновение». Что ещё за «проникновение» и зачем его нужно тестировать? В этой статье я постараюсь приоткрыть завесу тайны для непосвященных.

Работа программиста настолько сложна и разнообразна, что в ней просто не обойтись без помощи различных инструментов. Подготовил список из 34 полезных расширений Google Chrome, которые облегчат вашу жизнь и сэкономят время.



1. Octotree

Если вы любите GitHub и помногу читаете код, то, вероятно, знаете, как неудобно устроен обзор GitHub-файлов онлайн. Теперь этот процесс можно упростить при помощи расширения Octotree. Здесь предоставляется панель инструментов с удобной навигацией, также поддерживающая приватные репозитории.

2. PerfectPixel by WellDoneCode

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

3. GitHub Repository Size

Удобный и простой плагин, отображающий как объем отдельного репозитория, так и размер кажого файла в нем.

Проверка платных сервисов — один из ключевых инженерных вопросов в тестировании Badoo. Наше приложение интегрировано с 70 платёжными провайдерами в 250 странах мира, и баг хотя бы в одном из них может привести к непредсказуемым последствиям. 

В этой статье я расскажу о методах тестирования, которые мы используем в Badoo, и о границах применимости этих методов — этапах тестирования, на которых они максимально эффективны. 

Статья будет полезна тестировщикам, разработчикам и продакт-менеджерам, чьи проекты уже интегрированы с платёжными провайдерами, или процесс интеграции только начинается. Если в своей работе вы сталкиваетесь с проблемой выбора методов тестирования таких интеграций, добро пожаловать под кат! 

Неделю назад я выступал на митапе по Node.JS, и многим обещал выложить запись выступления. Уже потом я понял, что мне не удалось вместить в регламентированные полчаса некоторые интересные факты. Да и сам я больше люблю читать, а не смотреть и слушать, поэтому решил выложить выступление в формате статьи. Впрочем, видео тоже будет в конце поста в разделе ссылок.

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

• Во-первых, нашему монолиту уже 9 лет.
• Во-вторых, всю жизнь он провёл под хайлоадом (сейчас это 23 млн запросов в час).
• А в NaN-ых, мы пишем наш монолит на Node.JS, который за эти 9 лет изменился до неузнаваемости. Да, мы начинали писать на ноде в 2010, безумству храбрых поём мы песню!

Так что всякой специфики и реального опыта у нас довольно много. Интересно? Поехали!

В статье показано, как создать нерекурсивную zip-бомбу, которая обеспечивает высокую степень сжатия путём перекрытия файлов внутри zip-контейнера. «Нерекурсивная» означает, что она не зависит от рекурсивной распаковки декомпрессорами файлов, вложенных в zip-архивы: здесь всего один раунд. Выходной размер увеличивается квадратично от входного, достигая степени сжатия более 28 миллионов (10 МБ → 281 ТБ) в пределах формата zip. Ещё большее расширение возможно с помощью 64-разрядных расширений. Конструкция использует только наиболее распространённый алгоритм сжатия DEFLATE и совместима с большинством парсеров zip.

• zbsm.zip 42 kB → 5.5 GB
  
• zblg.zip 10 MB → 281 TB
  
• zbxl.zip 46 MB → 4.5 PB (Zip64, менее совместима с парсерами)

Исходный код:

git clone https://www.bamsoftware.com/git/zipbomb.git

zipbomb-20190702.zip

Данные и исходники иллюстраций:

git clone https://www.bamsoftware.com/git/zipbomb-paper.git

Кратко о спецификациях:

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

На сегодня существует два (если знаете другие проекты, напишите пожалуйста в комментариях) успешных и популярных проекта на PHP, позволяющих описывать бизнес-правила в спецификациях и фильтровать наборы данных. Это RulerZ и Happyr Doctrine Specification. Оба проекта являются мощными инструментами со своими преимуществами и недостатками. Сравнение этих проектов потянет на целую статью. Здесь же я хочу рассказать, что нам привнес новый релиз в Doctrine Specification.

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

Сегодня на протяжении примерно 30 минут посетители сайтов Cloudflare могли видеть ошибку 502, вызванную резким скачком загрузки CPU нашей сети. Это произошло по причине неудачного развертывания программного обеспечения. Мы провели откат изменений, и сейчас сервис функционирует в обычном режиме, как и прежде, а все домены, использующие Cloudflare, вернулись к нормальному уровню трафика.

Если бы меня попросили дать один универсальный совет всем, кто ищет работу в IT, я бы сказал: не стесняйтесь задавать побольше вопросов. Мало приятного в том, чтобы через месяц осознать, что новая компания/должность — совсем не то, что вы искали. А если это вакансия с релокацией, цена ошибки возрастает в разы.

Узнав как можно больше о компании и должности, вы уменьшаете риск оказаться «в неправильном месте». Вместе с командой экспертов по поиску работы за рубежом из Relocate.me, мы собрали 20 вопросов, которые стоит задать, прежде чем пойти на работу в новую компанию.

Иван работал в большой организации в отделе, связанном с DevOps. Ежедневно тысячи сотрудников пользовались инструментами DevOps для создания, проверки и внедрения своего программного обеспечения.

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

Естественно, многим не нравились инструменты DevOps. Кто-то говорил, что они слишком глючные, а другие считали, что можно обойтись совсем без них, и это будет гораздо быстрее.

Руководство компании понимало, что все 100% команд не могут быть довольны DevOps-ом, однако точных данных не было. Хорошо было бы увидеть наличие проблем на конвейере, однако не было известно даже обычное количество дистрибутивов, проходящих через него в день. Что уж тут говорить о серьезных метриках.

Вопрос о метриках DevOps поднимался постоянно — они были всем очень нужны.

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

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

В результате родилось полноценное техническое решения, которое Иван представил руководству.

Всё пропало

Приходилось ли вам запинаться в работе? Вот берёте таск: зафигачить красивый отсчитыватель времени "До конца супер предложения осталось всегда 2 часа". Открываете редактор… и щёлк: а как делать-то? Вроде я что-то слышал, что мы лэндинги начали на Vue делать. Или тут еще реакт?

Хорошо, когда вы в опенспейсе сидите через два стола. Всегда можно встать, и тихо спросить соседа "Напомни, мы Vue для всех теперь берём?". Хуже, если ТЛ в другом часовом поясе. Тот же вопрос — но ответ завтра. А если он закрутился, то послезавтра. И всё, вместо 1 минуты — двое суток задержки.

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

Сегодня компания Google анонсировала черновик RFC стандарта Robots Exclusion Protocol (REP), попутно сделав доступным свой парсер файла robots.txt под лицензией Apache License 2.0. До сегодняшнего дня какого-либо официального стандарта для Robots Exclusion Protocol (REP) и robots.txt не существовало (ближайшим к нему было вот это), что позволяло разработчикам и пользователям интерпретировать его по-своему. Инициатива компании направлена на то, чтобы уменьшить различия между реализациями.

Черновик нового стандарта можно просмотреть на сайте IETF, а репозиторий доступен на Github по ссылке https://github.com/google/robotstxt.

Парсер представляет собой исходный код, который Google используют в составе своих продакшн-систем (за исключением мелких правок — вроде убранных заголовочных файлов, используемых только внутри компании) — парсинг файлов robots.txt осуществляется именно так, как это делает Googlebot (в том числе то, как он обращается с Юникод-символами в паттернах). Парсер написан на С++ и по сути состоит из двух файлов — вам потребуется компилятор, совместимый с C++11, хотя код библиотеки восходит к 90-ым, и вы встретите в ней «сырые» указатели и strbrk. Для того, чтобы его собрать, рекомендуется использовать Bazel (поддержка CMake планируется в ближайшем будущем).

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



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

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

Добро пожаловать под кат!

Предлагаю ознакомиться с расшифровкой доклада Дениса Исаева jirfag "Линтеры в Go. Как их готовить."

В go 50+ линтеров: в чем их профит и как эффективно встроить их в процесс разработки? Доклад будет полезен как тем, кто еще не использует линтеры, так и тем, кто уже применяет их: я раскрою малоизвестные трюки и практики работы с линтерами.

Кому интересно, прошу под кат.

Есть в графиках что-то магическое. Изгиб кривой мгновенно раскрывает всю ситуацию — историю развития эпидемии, паники или периода процветания. Эта линия просвещает, пробуждает воображение, убеждает.
― Генри. Д. Хаббард

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

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

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



Что ж, приступим: вот лучшие JS библиотеки для визуализации данных!

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

Введение: найди кота

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

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

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

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

1. Введение

Онлайн-платформы пассажироперевозок, такие как Uber, DiDi и Yandex возникли достаточно недавно, при этом они быстро достигли внушительных размеров и, несмотря на свой небольшой возраст, существенно видоизменили и дополнили систему городского транспорта. Технологии и теоретические модели, используемые этими платформами (или разрабатываемые для них), на данный момент являются областью активных исследований для широкого спектра специалистов научного сообщества: экономистов, математиков, программистов и инженеров.

В этой статье мы (как представители команды Uber Marketplace Optimization) коротко представим взгляд изнутри на главные рычаги управления эффективностью онлайн-платформ: алгоритмы, отвечающие за диспетчерские решения (matching), динамическое ценообразование (dynamic pricing), а также представим одну из новых концепций — динамическое время назначения автомобиля (dynamic waiting). Основываясь на реальном практическом опыте, мы покажем, что все три алгоритма играют важную роль для создания системы с высокой производительностью и низким временем ожидания заказов как для пассажиров, так и для водителей.

Представленное описание алгоритмов будет носить ознакомительных характер и намеренно лишено технической глубины и строгости. Заинтересовавшийся читатель приглашается изучить оригинал статьи (Dynamic Pricing and Matching in Ride-Hailing Platforms — N.Korolko, D.Woodard, C.Yan, H.Zhu — 2019), опубликованной исследователями из отдела Uber Marketplace, по мотивам которой этот краткий ознакомительный обзор и создан.