Как всё начиналось

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



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

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

Решив, что пора увлечения перевести в плоскость практики — я отправился на Youtube. Получил горсть самых базовых знаний и дальше мой путь лежал уже на AliExpress, как и у многих. Закончилось всё покупкой 27-ми наименований различных модулей и прочих компонентов.



Сотрудник почтового отделения был очень недоволен когда искал 27 посылок…

Я из компании Luxoft.
В этой статье будет рассматриваться проект nginx-log-collector, который будет читать логи nginx, отправлять их в кластер Clickhouse. Обычно для логов используют ElasticSearch. Для Clickhouse требуется меньше ресурсов (дисковое пространство, ОЗУ, ЦПУ). Clickhouse быстрее записывает данные. Clickhouse сжимает данные, что делает данные на диске еще компактнее. Преимущества Clickhouse видны по 2 слайдам с доклада Как VK вставляет данные в ClickHouse с десятков тысяч серверов.

При этом за счёт сжатия данных «Кликхаус» использует в 11 раз меньше на жёстком диске и делает примерно в 30 раз меньше дисковых операций (из поста https://habr.com/ru/company/ua-hosting/blog/486540/):

Для просмотра аналитики по логам создадим дашборд для Grafana.

Кому интересно, добро пожаловать под кат.

Завершение цикла статей от Cem Ugur Karacam о реализации MVC в Unity с помощью Scriptable Objects. Прочитать предыдущие части вы можете здесь и здесь.

Продолжение цикла статей от Cem Ugur Karacam (часть 1 можно прочитать здесь).

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

MVC (Model-View-Controller) — это схема, предполагающая разделение данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента, чтобы каждый из них можно было независимо модифицировать. Разработчик Cem Ugur Karacam поделился своим опытом программирования в Unity и коротко рассказал о Scriptable Objects. Мы представляем перевод его статьи, опубликованной на сайте dev.to.

BattlEye — это преимущетвенно немецкий сторонний античит, в основном разрабатываемый 32-летним Бастианом Хейко Сутером. Он предоставляет (или пытается предоставить) издателям игр простую в применении систему античита, использующую механизмы общей защиты, а также обнаружение читов для конкретных игр для оптимизации безопасности. Как сказано на веб-сайте продукта, он всегда остаётся на вершине современных технологий и использует инновационные методики защиты и обнаружения; очевидно, это следствие национальности разработчика: QUALITY MADE IN GERMANY. BattlEye состоит из множества элементов, совместно работающих над поиском читеров в играх, оплативших использование продукта. Четырьмя основными элементами являются:

• BEService
  • Системная служба Windows, обменивающаяся данными с сервером BattlEye BEServer, который обеспечивает возможности клиент-серверной связи с BEDaisy и BEClient.
• BEDaisy
  • Драйвер ядра Windows, регистрирующий превентивные механизмы обработки событий и мини-фильтры, чтобы препятствовать читерам в незаконном изменении игры
• BEClient
  • Динамически подключаемая библиотека Windows, отвечающая за большинство векторов обнаружения, в том числе за описанные в данной статье. После инициализации она привязывается к процессу игры.
• BEServer
  • Проприетарный бэкенд-сервер, отвечающий за сбор информации и принятие конкретных мер против читеров.

Шелл-код

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

Привет, Хабр! Представляю вашему вниманию перевод статьи «ConfigureAwait FAQ» автора Стивен Тауб.



Async/await добавили в .NET более семи лет назад. Это решение оказало существенное влияние не только на экосистему .NET — оно также находит отражение во многих других языках и фреймворках. На данный момент реализовано множество усовершенствований в .NET с точки зрения дополнительных языковых конструкций, использующих асинхронность, реализованы API-интерфейсы с поддержкой асинхронности, произошли фундаментальные улучшения в инфраструктуре, благодаря которым async/await работает как часы (в особенности, улучшены возможности производительности и диагностики в .NET Core).

ConfigureAwait — один из аспектов async/await, который продолжает вызывать вопросы. Надеюсь, у меня получится ответить на многие из них. Я постараюсь сделать эту статью читаемой от начала до конца, и вместе с тем выполнить ее в стиле ответов на часто задаваемые вопросы (FAQ), чтобы на нее можно было ссылаться в последующем.

Физика стала неотъемлемой частью любой современной игры. Будь то простая симуляция ткани или полноценная физика движения транспорта. Не являются исключением и мобильные игры. Однако, настраивая физику для них, нужно оглядываться на ограничения, связанные с относительно низкой производительностью поддерживаемых устройств старого поколения. Ведущий технический 3D-художник Banzai.Games Роман Терский рассказал, как его команда интегрировала физику в игровой процесс мобильного файтинга Shadow Fight 3, какие приемы использовала для оптимизации и как переписала “с нуля” физику для персонажей для достижения ее полной детерминированности в синхронном PVP.

Это третья, заключительная часть из цикла. В предыдущей статье мы подробно рассказали об УСН, патенте и налоге для самозанятых. В этой части рассчитаем налоговую нагрузку для ИП с доходом 100, 200 или 300 тыс. руб. в месяц на разных режимах.

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

Части 1-3: сетка, цвета и высоты ячеек

Части 4-7: неровности, реки и дороги

Части 8-11: вода, объекты рельефа и крепостные стены

Части 12-15: сохранение и загрузка, текстуры, расстояния

Части 16-19: поиск пути, отряды игрока, анимации

Части 20-23: туман войны, исследование карты, процедурная генерация

Части 24-27: круговорот воды, эрозия, биомы, цилиндрическая карта

Часть 16: поиск пути

• Подсвечиваем ячейки
• Выбираем целевую точку поиска
• Находим кратчайший путь
• Создаём очередь с приоритетом

Вычислив расстояния между ячейками, мы перешли к нахождению путей между ними.

Начиная с этой части, туториалы по картам из шестиугольников будут создаваться в Unity 5.6.0. Нужно учесть, что в 5.6 есть баг, разрушающий массивы текстур в сборках для нескольких платформ. Обойти его можно, включив в инспекторе массива текстур Is Readable.


Планируем путешествие

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



Часть 1. Поиск работы: источники, резюме, собеседование с HR
Часть 2. Устройство и адаптация: собеседуем с боссом, проходим испытательный срок с ветерком
Часть 3. Работа в роли новичка: рост в компании
Часть 4. Работа в роли опытного сотрудника: как не перегореть
Часть 5. Увольнение: я ухожу красиво

TL;DR: статья рассказывает об удобном, быстром и надежном способе определения Linux-программ, записывающих данные на диск, что помогает в выявлении большой или аномально частой нагрузки на дисковую подсистему, а также позволяет оценить накладные расходы файловой системы. Это особенно актуально для SSD в ПК, EMMC и Flash-памяти в одноплатных компьютерах.
В ходе написания статьи обнаружилось, что запись нескольких килобайт данных на файловую систему BTRFS приводит к записи 3 мегабайт реальных данных на диск.

Введение

«Ой, ерунда, ячейки памяти на современных SSD выйдут из строя через десятки лет обычного использования, не стоит об этом беспокоиться, и уж тем более переносить swap, виртуальные машины и папку профиля браузера на HDD» — типичный ответ на вопрос о надежности твердотельных накопителей c гарантированными ≈150 TBW. Если прикинуть, сколько типичное ПО может писать данных, то кажется, что 10-20 ГБ в сутки — уже большая цифра, пусть будет максимум 40 ГБ, куда уж больше. При таких цифрах ответ вполне разумен — нужно 10 лет, чтобы достичь гарантированных значений по количеству перезаписи ячеек, при 40 ГБ записанных данных ежедневно.
Однако за 6 лет я пользуюсь уже третьим SSD: у первого вышел из строя контроллер, а второй начал перемещать данные между ячейками несколько раз в день, что оборачивалось 30-секундными задержками в обслуживании записи.

После 7 месяцев использования нового SSD я решил проверить количество записанных данных, как их сообщает сам диск через SMART.
19.7 ТБ.
Всего за 7 месяцев я использовал 13% от гарантированного количества записанных данных, притом, что он настроен в соответствии с рекомендациями по выравниваю разделов и настройке ФС, swap у меня почти не используется, диски виртуальных машин размещены на HDD!

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

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

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

В этой статье я опишу интересное решение на базе Nginx для случая, когда дисковая система становится узким местом при раздаче контента (например, видео).

TL;DR В статье описывается самый простой способ настроить VPN-сервер, у которого IP-адрес для подключения VPN-клиентов отличается от IP-адреса, с которого клиенты выходят в интернет.

Используете VPN для защиты приватности в интернете и арендуете для этого свой личный сервер? При этом вы единственный клиент, который подключается к этому серверу во всем мире? Так ли сложно найти ваш реальный IP-адрес, как вам кажется? С вступлением в силу пакета Яровой, это становится намного проще.

Double VPN — популярная тема, вокруг которой много спекуляций. Часто этим термином называют совершенно разные технологии, но почти всегда это означает разнесенные на уровне IP-адресов точки подключения и выхода в интернет. Мы рассмотрим самый простой способ настройки VPN-сервера в таком режиме, который не требует дополнительной настройки на серверной стороне и позволяет получить максимальную скорость и самые низкие задержки.

Любому программисту будет полезно понимание различных структур данных и способов анализа их производительности. Но на практике мне ни разу не пригождались АВЛ-деревья, красно-чёрные деревья, префиксные деревья, списки с пропусками, и т.д. Некоторые структуры данных я использую только для одного конкретного алгоритма и ни для чего больше (например, кучи для реализации очереди с приоритетом в алгоритме поиска пути A*).

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

• Общие массивы данных (Bulk data) — способ эффективного хранения большого количества объектов.
• Слабые ссылки (Weak reference) (или дескрипторы (handle)) — способ обращения к объектам в bulk data без сбоев программы в случае, если объект удалён.
• Индексы — способ быстрого доступа к отдельным подмножествам в bulk data.
• Массивы массивов — способ хранения объектов bulk data с динамическими размерами.

Я посвящу несколько статей тому, как я обычно реализую все эти структуры. Давайте начнём с простейшей и самой полезной — bulk data.

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

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

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

Девхаб получил среднюю оценку 4,56 и среднюю рекомендацию 93% от своих сотрудников на «Моём круге». Его ценят за современные технологии, которые используются в работе, за отличные отношения с коллегами и налаженную связь с топ-менеджментом.

Я должен признаться. Я ненавижу docker. Всей своей душой. Это самая ужасная софтина, которую я видел за последние 10 лет.

С одной стороны, я очень уважаю одноименную компанию. Ребята из Docker Inc. реально популяризировали контейнеризацию. Теперь о ней не знает только ленивый. С другой стороны, ничего принципиально нового они не изобрели — контейнеризация на момент, когда Docker "выстрелил", уже существовала более 30 лет (начиная от chroot, вспомним еще jails и zones, ну, и наконец-то — namespaces & cgroups).

Круто, что docker реально ускоряет разработку во множество раз. Если вести ее правильно, то даже без потери в качестве. В любом случае, docker здесь, от него не деться и приходится им пользоваться.

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

Disclaimer: все написанное ниже является личным мнением автора и может как отражать реальность, так и не отражать реальность. Материал строго провокационного характера и основной целью является не унизить или обидеть кого бы то ни было, а скорее заставить людей включить голову и осознать масштабы глубин (с).

Привет! Меня зовут Евгения Голева, я выступила на TeamLeadConf с докладом про обратную связь и хочу поделиться с вами его вольной расшифровкой. Мне удалось под соусом совсем другого проекта научить инженеров давать обратную связь гораздо лучше, чем они делали это раньше. Для этого пришлось не только долго и тщательно объяснять «зачем и как», но и организовать множество подходов к снаряду под бдительным контролем и с мягкой поддержкой. Путь был непростым, усеян граблями и велосипедами, и я надеюсь, что некоторые неочевидные мысли и методы пригодятся тем, кто хотел бы привить культуру здорового фидбэка своей команде.