Headhunter — продуктовая компания, нам очень важно качество кода. Чем он лучше, тем быстрее мы можем выпускать новые бизнес фичи и чаще радовать пользователей.

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

Протокол прикладного уровня HTTP лежит в основе интернета. Он начал свою жизнь в 1991 году как HTTP/0.9, а к 1999 году превратился в HTTP/1.1, который был стандартизирован Инженерным советом Интернета (IETF).

HTTP/1.1 долго всех удовлетворял, но растущие потребности Сети потребовали апгрейда — и в 2015 году приняли HTTP/2. На этом история не закончилась: совсем недавно IETF анонсировал новую версию HTTP/3. Для некоторых это стало неожиданностью и вызвало некоторое замешательство. Если вы не отслеживаете работу IETF, может показаться, что HTTP/3 появился из ниоткуда. Тем не менее, мы можем отследить его происхождение по истории экспериментов и эволюции веб-протоколов, в частности, транспортного протокола QUIC.

Если вы не знакомы с QUIC, мои коллеги по Cloudflare довольно подробно осветили разные аспекты: например, см. статьи о реальных недостатках современного HTTP и подробности о протоколе транспортного уровня. Мы собрали эти и другие материалы на сайте cloudflare-quic.com. А если интересно, обязательно ознакомьтесь с quiche: это наша собственная реализация QUIC, написанная на Rust с открытым исходным кодом.

Всем привет!

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

• «Стоит ли работать удаленно?»
• «Как вы организовали удаленную работу для своей команды?»
• «Нам сложно работать с удаленными разработчиками...»

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

И раз… два… три… Поехали!

Привет, Хабр! Меня зовут Тимур Шагиахметов, я PHP-разработчик в Badoo.

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

Недавно мы рассказывали о том, какими инструментами пользуемся для профилирования. Напомню: одним из инструментов для анализа производительности, когда непонятно, какие части кода повлияли больше всего на увеличение времени формирования ответа, является XHProf. Это расширение для PHP, которое позволяет профилировать код на боевом сервере и впоследствии  улучшать его.

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

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

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

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

Подобные периоды застоя называют «эффектом плато». И через них проходят 90% всех учеников, которые изучают английский или любой другой иностранный язык.



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

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

microBIGDATA или ФИАС в кармане


Питер Брейгель Младший, Уплата налога, 1640 год

Прошлый заход на бреющем по объектам зашел. Продолжим разведку боем. Сегодня поговорим о тяжелом. Пусть ещё не о BIG DATA, но работать уже неудобно – достаточно большие объёмы данных. Не каждому влезет в оперативную память целиком, а некоторым не влезет даже на диск (не места мало, а хламу много). Имя нашему подопечному БД ФИАС — база данных федеральной адресной информационной системы. Архив в 5,5 ГБ. И это сжатый в архив XML. После распаковки будут полные 53 ГБ (для распаковки запасайте 110 ГБ). И как начнёшь его парсить да конвертить, то и 110 ГБ будет мало. О потребном размере ОЗУ тоже будет.

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

Введение

Алгоритм был написан как часть работы на получение степени бакалавра и основан на статье Ma et al (2014). Целью работы было ускорение алгоритма и дополнение его новыми функциями. Я вполне доволен результатом, потому что мы сделали алгоритм достаточно быстрым, чтобы использовать его во время выполнения игры. После завершения бакалаврской работы мы решили превратить её в статью и отправить на конференцию Game-ON 2018.

Алгоритм

Для создания уровня игры алгоритм получает в качестве входных данных набор полигональных строительных блоков и граф связности уровня (топологию уровня). Узлы графа обозначают комнаты, а рёбра определяют связи между ними. Цель алгоритма — назначить каждому узлу графа форму и расположение комнаты таким образом, чтобы никакие две формы комнат не пересекались, и каждая пара соседних комнат могла соединяться дверьми.

Часто перед разработчиками PHP встаёт задача проверить работу веб-приложения под несколько версий интерпретатора. Решить её можно разными способами. Можно банально установить разные версии PHP на один хост, но это чревато конфликтами библиотек и другими сложностями. Вторая крайность — сделать несколько изолированных виртуальных машин с разным окружением, но здесь не обойтись без чрезмерного использования аппаратных ресурсов и излишней траты времени на разворачивание рабочего окружения. На настоящий момент наиболее просто решить данную задачу можно с помощью Docker.

Ветеран программирования трёхмерной графики Майкл Абраш на примере разработки первого Quake рассказывает о необходимости творческого мышления в программировании.

Много лет назад я работал в теперь уже не существующей компании-производителе видеоадаптеров Video Seven. Там я помогал в разработке клона VGA. Мой коллега Том Уилсон, долгие месяцы круглосуточно работавший над разработкой VGA-чипа Video Seven, стремился сделать VGA как можно более быстрым, и был уверен, что его производительность оптимизирована почти по максимуму. Однако когда Том уже вносил в конструкцию чипа последние штрихи, до нас донеслись слухи, что наш конкурент Paradise достиг ещё большей производительности в своём разрабатываемом клоне, добавив в него FIFO.

На этом слухи заканчивались — мы не знали, ни что это за FIFO, ни насколько он помог, ничего другого. Тем не менее, Том, обычно приветливый и расслабленный человек, превратился в активного, одержимого фанатика со слишком большим процентом кофеина в крови. Исходя из этих крупиц информации, он пытался выяснить, что же удалось сделать Paradise. В конце концов он пришёл к выводу, что Paradise вероятно вставил FIFO-буфер записи между системной шиной и VGA, чтобы когда ЦП выполнял запись в видеопамять, записываемые данные сразу же попадали в FIFO, и это позволяло ЦП продолжать обработку, а не простаивать каждый раз, когда он выполнял запись в память дисплея.

У Тома не было ни логических элементов, ни достаточно времени на реализацию полного FIFO, но ему удалось реализовать FIFO глубиной в одну операцию, что позволяло процессору обгонять VGA-чип на одну операцию записи. Том не был уверен, что это даст хорошие результаты, но это было единственное, что он смог сделать, поэтому он реализовал эту систему и передал чип в производство.

В наше время использование HTTPS становится обязательным для всех сайтов и веб-приложений. Но в процессе разработки возникает проблема корректного тестирования. Естественно, Let’s Encrypt и другие CA не выдают сертификаты для localhost.

Традиционно есть два решения.

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

В разработке больших высоконагруженных проектов с огромным онлайном часто приходится думать, как снизить нагрузку на сервера, особенно при работе в webSocket'ами и динамически изменяемыми интерфейсами. К нам приходит 100500 пользователей и мы имеем 100500 открытых соединений по сокетам. А если каждый из них откроет по 2 вкладки — это уже *201000 соединений. А если пять?

Pathfinder: Kingmaker (далее PF:K для удобства) — компьютерная ролевая игра, созданная студией Owlcat Games и вышедшая этой осенью в Steam и GoG. Проект, вдохновлённый классическими играми от Bioware и разделяющий с ними такие особенности, как использование правил популярной системы настольных игр, сражения в реальном времени с паузой, камера с изометрической проекцией, нелинейность прохождения и возможность получить несколько уникальных завершений.

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

© Яндекс.Картинки

Перечень изменений.

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

Нередко слышишь мнение, что составление Технического задания по ГОСТ 34 (ТЗ) занятие не только трудоемкое, но и крайне раздражающее, поскольку приходится писать много всякой ерунды, воды. Но подумайте: разработкой этого ГОСТа занимались целые НИИ, это был проект на государственном уровне, обобщен опыт сотен проектов автоматизации, сложных проектов. Неужели они могли написать чушь?

На самом деле, при грамотном подходе ГОСТ очень сильно помогает не только при разработке ТЗ, но и в ходе реализации проекта автоматизации в целом (и не только в госконтрактах, но и для коммерческой разработки). Грамотные люди его писали. Но чтобы воспользоваться плодами их трудов, нужно немного понять замысел не только ТЗ, но и ГОСТ 34 в целом.

В данной статье мы пункт за пунктом разберем все требования ГОСТа и попробуем сделать разработку ТЗ по ГОСТ 34 не обременением, а большой помощью в проекте.

(Иллюстрация)

Senior web developer’ы Антон и Алексей продолжают рассказ о непростой борьбе с Nuxt. В предыдущем раунде битвы с этим фреймворком они показали, как запустить проект на Nuxt так, чтобы все были счастливы. В новой статье поговорим о реальном применении фреймворка.

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

После пары раундов обсуждения решили не полагаться на традиционный подход с только серверным рендерингом — но и не загонять себя в ловушку клиентского рендеринга. Как итог мы начали строить решение на базе Nuxt.js.

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

В данной статье я расскажу о своём опыте "заворачивания" Laravel-приложения в Docker-контейнер да так, что бы и локально с ним могли работать frontend и backend разработчики, и запуск его на production был максимально прост. Так же CI будет автоматически запускать статические анализаторы кода, phpunit-тесты, производить сборку образов.

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

• "Использую докер для локальной разработки. Ставлю laradock и беды не знаю". Круто, но как обстоят дела с автоматизацией и запуском на production?
• "Собираю один контейнер (монолит) на базе fedora:latest (~230 Mb), ставлю в него все сервисы (nginx, бд, кэш, etc), запускаю всё супервизором внутри". Тоже отлично, прост в запуске, но как на счёт идеологии "один контейнер — один процесс"? Как обстоят дела с балансировкой и управлением процессами? Как же размер образа?
• "Вот вам куски конфигов, приправляем выдержками из sh-скриптов, добавим магических env-значений, пользуйтесь". Спасибо, но как же на счёт хотя бы одного живого примера, который я бы мог форкнуть и полноценно поиграться?

Для нетерпеливых — ссылка на репозиторий, склонировав который ты сможешь запустить Laravel-приложение одной командой. Так же не составит труда его запустить на том же rancher, правильно "слинковав" контейнеры, или использовать продуктовый вариант docker-compose.yml как отправную точку.

Всем привет!

Наша компания занимается разработкой онлайн игр и сейчас мы работаем над мобильной версией нашего основного проекта. В этой статье хотим поделиться опытом разработки GLSL шейдеров для Android проекта с примерами и исходниками.

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

Существенные недостатки есть и у самих информационных систем. В этой статье я предлагаю поговорить не о традиционных – трёхслойных – АИС, а о системах с четырехслойной архитектурой, где новый четвертый слой – слой представления – реализует понятийную модель предметной области. Для актуализации модели при изменениях в предметной области не требуется программировать. Более того, как актуализация модели, так и прикладные задачи решаются посредством семантически инвариантных для всех предметных областей операций над сущностями понятий.

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

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

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

Привет, Хабр! Представляю вашем вниманию перевод статьи "Design Patterns in Cocos2d-x" автора Aleksei Pinchuk.

Статья будет интересна для разработчиков Cocos2d-x и тех, кто изучает паттерны. Она выполнена в форме краткого конспекта, в котором можно быстро посмотреть где применяется тот или иной паттерн в Cocos2d-x. Целью статьи не является полное описание каждого паттерна.