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

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

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

Но давайте начну с методологии.

В нашу эру, машины успешно достигли 99% точности в понимании и определении признаков и объектов на изображениях. Мы сталкиваемся с этим повседневно, например: распознавание лиц в камере смартфонов, возможность поиска фотографий в google, сканирование текста со штрих-кода или книг с хорошей скоростью и т. д. Такая эффективность машин стала возможным благодаря особому типу нейронной сети, называемой сверточной нейронной сетью. Если вы энтузиаст глубокого обучения, вы, вероятно, слышали об этом, и вы могли разработать несколько классификаторов изображений. Современные фреймворки глубокого обучения, такие как Tensorflow и PyTorch, упрощают обучение машин изображениям. Однако все еще остается вопрос: как данные проходят через слои нейронной сети и как компьютер обучается на них? Чтобы получить четкое представление с нуля, мы погрузимся в свертку, визуализируя изображение каждого слой.

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

Этот блог выложен на GitHub. Если у вас какие-то вопросы или проблемы, открывайте там соответствующий запрос.

Тестирование производилось с помощью Yandex Tank.
В качестве приложения использовались Symfony 4 и PHP 7.2.
Целью являлось сравнение характеристик сервисов при разных нагрузках и нахождение оптимального варианта.
Для удобства все собрано в docker-контейнеры и поднимается с помощью docker-compose.
Под катом много таблиц и графиков.

Если одновременно выполняется много операций по изменению схемы БД, сервис не может корректно работать на запись. Разработчик Владимир Колясинский объяснил, какие операции в PostgreSQL требуют длительных блокировок и как команда Яндекс.Коннекта обеспечивает почти стопроцентную доступность сервиса на запись во время выполнения подобных операций. Кроме того, вы узнаете о библиотеке для Django, которая призвана автоматизировать часть описанных процессов.

У нас большие нагрузки, тысячи RPS, и простой в несколько минут, не говоря о большем времени, недопустим. Нужно, чтобы миграции происходили незаметно для пользователя. А с такими нагрузками уже не получится встать в четыре часа ночи, что-то накатить, когда нет нагрузки, и снова лечь спать — потому что нагрузка идет круглые сутки.

*на самом деле мы напишем только прототип протокола.

Возможно, вы встречались с подобной ситуацией – сидите в любимом мессенджере, переписываетесь с друзьями, заходите в лифт/тоннель/вагон, и интернет вроде ещё ловит, но отправить ничего не получается? Или иногда ваш провайдер связи неправильно конфигурирует сеть и 50% пакетов пропадает, и тоже ничего не работает. Возможно, вы думали в этот момент — ну ведь можно же наверное как-то сделать, чтобы при плохой связи всё равно можно было отправить тот маленький кусочек текста, который вы хотите? Вы не одни.

Источник картинки

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

Автор материала, перевод которого мы сегодня публикуем, говорит, что когда она работала в сфере бухучёта, там применялись понятные термины, значения которых легко найти в словаре. А вот занявшись программированием, и, в частности, JavaScript, она начала сталкиваться с такими понятиями, определения которых в словарях уже не найти. Например, это касается ключевого слова this. Она вспоминает то время, когда познакомилась с JS-объектами и функциями-конструкторами, в которых использовалось это ключевое слово, но добраться до его точного смысла оказалось не так уж и просто. Она полагает, что подобные проблемы встают и перед другими новичками, особенно перед теми, кто раньше программированием не занимался. Тем, кто хочет изучить JavaScript, в любом случае придётся разобраться с this. Этот материал направлен на то, чтобы всем желающим в этом помочь.

Многие знают о механизме Event-Dispatcher-Listener'ов, реализованному во многих языках программирования. Я же создам подобный механизм не для Event'ов, а для любого метода объекта JavaScript — Object.
Я не претендую на оригинальность, нет. Основная цель статьи — рассмотреть интересные механизмы прототипирования в JavaScript, создание декораторов и, собственно, постараться хоть немного раскрыть мощь и гибкость это чудесного языка, который так часто обижают и недооценивают.

UPD1: краткое содержание:
1. Создание декоратора на JavaScript
2. Создание механизма Function call listener с помощью декораторов

UPD2: от 09.06.2009
В конце статьи я добавил раздел Update: Decorator Mark II. В нём — исправления и улучшения (я не перекраивал всю статью из-за этого)

Итак, первый (и, надеюсь, не последний) рецепт в моей поваренной книге JavaScript.

1-3 февраля пройдёт Слёрм-3, интенсив по Kubernetes. Анонс и программа тут.

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

Я сам 2-3 раза в год прохожу платные курсы, всегда беру варианты с практикой, и очень редко доделываю ее до конца. Для меня ситуация выглядит, как если бы я заказал в ресторане килограммовый стейк: съел, сколько мог, остальное оставил на тарелке. Но в тех, кто едет на Слёрм, хотелось бы запихнуть всю порцию.

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

Поэтому на втором Слёрме кроме трех спикеров со студентами работал десяток саппортов: системных администраторов из команды Southbridge.

Программы, в ходе работы, пользуются оперативной памятью компьютеров. На JavaScript, в среде Node.js, можно писать серверные проекты самых разных масштабов. Организация работы с памятью — это всегда непростая и ответственная задача. При этом, если в таких языках, как C и C++, программисты довольно плотно занимаются управлением памятью, в JS имеются автоматические механизмы, которые, как может показаться, полностью снимают с программиста ответственность за эффективную работу с памятью. Однако на самом деле это не так. Плохо написанный код для Node.js может помешать нормальной работе всего сервера, на котором он выполняется.



В материале, перевод которого мы сегодня публикуем, речь пойдёт об эффективной работе с памятью в среде Node.js. В частности, здесь будут рассмотрены такие концепции, как потоки, буферы и метод потоков pipe(). В экспериментах будет использован Node.js v8.12.0. Репозиторий с кодом примеров можно найти здесь.

Кажется, мы так глубоко погрузились в дебри highload-разработки, что просто не задумываемся о базовых проблемах. Взять, например, шардирование. Чего в нем разбираться, если в настройках базы данных можно написать условно shards = n, и все сделается само. Так-то, он так, но если, вернее когда, что-то пойдет не так, ресурсов начнет по-настоящему не хватать, хотелось бы понимать, в чем причина и как все починить.

Короче, если вы контрибьютили свою альтернативную реализацию хэширования в Cassandra, то вряд ли тут для вас найдутся откровения. Но если нагрузка на ваши сервисы уже прибывает, а системные знания за ней не поспевают, то милости просим. Великий и ужасный Андрей Аксёнов (shodan) в свойственной ему манере расскажет, что шардить плохо, не шардить — тоже плохо, и как это внутри устроено. А еще совершенно случайно одна из частей рассказа про шардинг вообще не совсем про шардинг, а черт знает про что — как объекты на шарды мапить.

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

7 декабря мы провели Frontend DevDay — смешали техническую презентацию нового 2ГИС с полноценным митапом. Разговаривали про карты на WebGL, трансформацию команды и запросы браузера. По словам участников, получилось празднично и увлекательно.

Сегодня делимся записями всех трёх докладов. Спикеры на связи, если у вас возникнут вопросы — смело задавайте в комментариях к посту.

Буквально накануне (UPD пока я писал статью, прошло двое суток 0_0), 4 декабря в Лондоне прошла конференция FlutterLive, посвящённая в основном мобильному фреймворку Flutter, но не ограничиваясь им. Какие новости нам рассказали, и что теперь является основным вектором развития для команды Google, включая некоторые размышления на этот счёт, вы можете прочесть ниже.

Так как мы в Wrike сейчас одни из самых больших потребителей Dart (но, как показала конференция DartUP далеко не единственные), то мы постарались сделать для вас детальный разбор, что этот анонс значит для всего IT мира.

Спойлер для затравки: скоро всё будет Flutter

В 2010 году Патрик Маккензи написал знаменитую статью «Заблуждения программистов об именах», перечислив 40 фактоидов, которые не всегда верны в отношении человеческих имён.

Думаете, программисты сели, подумали и изменили обработку имён в компьютерных системах? К сожалению, не совсем. Нас по-прежнему повсеместно просят заполнить онлайн-формы, которые предполагают обязательное наличие имени и фамилии (причём именно в таком порядке). Эти системы по-прежнему предполагают, что наши имена всегда можно записать символами алфавита, зачастую только ASCII.

Hyperledger Fabric (HLF) — платформа с открытым исходным кодом, использующая технологию распределенного реестра (DLT — distributed ledger technology), предназначенная для разработки приложений, работающих в среде бизнес-сетей, созданных и контролируемых консорциумом организаций с применением правил доступа (permissioned).

Платформа поддерживает смарт-контракты, в терминах HLF — чейнкоды (chaincode), создаваемые на языках общего назначения, таких как Golang, JavaScript, Java, в отличие, от, например, Ethereum, в котором используется контрактно-ориентированный, ограниченный по функциональности язык Solidity (LLL, Viper и др).

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

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

Я провёл простое тестирование и убедился в том, что на простых задачах, использующих только стек, виртуальная машина работает шустро, а при использовании "памяти" — массива со случайным доступом — начинаются большие проблемы. О том, как удалось их решить, не меняя базовых принципов архитектуры программы и достичь тысячекратного ускорения работы программы, и пойдёт речь в предлагаемой вашему вниманию статье.

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

Доклад Владимира Иванова на AppsConf как раз о том, что не так страшен чёрт и что можно прямо сегодня применять корутины:

• почему корутины, а не RxJava;
• какие страхи мешают разработчикам;
• как сделать кэш применяя корутины;
• как правильно обрабатывать ошибки.

О спикере: Владимир Иванов (dzigoro) — ведущий Android-разработчик в компании EPAM с 7-летним опытом, увлекается Solution Architecture, React Native и разработкой под iOS, а еще имеет сертификат Google Cloud Architect.

Меня зовут Роб Стакл, я консультант по безопасности из Феникса, штат Аризона, и в основном работаю пентестером. Я участвую в конференциях DefCon с 1996 года, увлекаюсь высотной фотографией, а в эти выходные была одиннадцатая годовщина нашей свадьбы. Я хочу поблагодарить мою удивительную и понимающую жену Линду, которая не ожидала, что моё участие в DefCon означает, что каждый год я буду вынужден проводить годовщину нашей свадьбы в Вегасе, о чём я очень сожалею.



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

Мой старый друг Myetherwallet давно и неустанно мне напоминает, как неправильно я, дядя Егор, бутерброд ем, заходя на него через браузер по приватному ключу. Использование веб-кошельков — один из рискованных способов доступа к криптоактивам наряду с их хранением на криптобирже. Давно было пора изучить альтернативные варианты. Общественное мнение, разумеется, было за «железные» аппаратные кошельки. Но я особо не спешил: защита от хакеров — это, конечно, аргумент. Но и оффлайн-угрозы никто не отменял — в жизни что-нибудь терять случается гораздо чаще. И внешние ассоциации с флэшками уверенности не добавляли.



Но рано или поздно нужно встречать свои страхи лицом к лицу, так что предложение Madrobots потестить Ledger Nano S пришлось весьма кстати. Как и то, что обзор получился под Чёрную пятницу — так что Nano S сейчас с дисконтом 50% до воскресенья — с рухнувшим в цене битком скидки особенно актуальны.

Перевод Neural Network Architectures

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


Сравнение популярных архитектур по Top-1 one-crop-точности и количеству операций, необходимых для одного прямого прохода. Подробнее здесь.