Как-то раз я случайно увидел, как мой коллега решает джуниорскую задачку разворачивания двусвязного списка на C++. И в тот момент странным мне показалось не то, что он лид и давно перерос подобное, а само решение.

Вернее, не так.

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

• Почему по умолчанию все решают задачу именно так?
• Можно ли сделать лучше?

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

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

На Хабре много статей о том, как самостоятельно изучать английский язык. Но вот вопрос, а как оценить свой уровень при самостоятельном изучении? Понятно, что есть IELTS и TOEFL, но эти тесты почти никто не сдает без дополнительной подготовки и эти тесты, как говорят, оценивают не сколько уровень владения языком, а скорее умение проходить эти самые тесты. Да и использовать их для контроля самообучения будет накладно.

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

1. Форма кредитной карты

Клёвая форма кредитной карты с гладкими и приятными микровзаимодействиями. Включает форматирование чисел, проверку и автоматическое определение типа карты. Она построена на Vue.js, а также полностью адаптивная. (Посмотреть можно здесь.)



credit-card-form

Чему научитесь:

• Обрабатывать и валидировать формы
• Обрабатывать события (например, при изменении полей)
• Разберетесь как отображать и размещать элементы на странице, особенно данные кредитной карты, которая поверх формы

Эта неделя была короткой, в понедельник и вторник я продолжал работать над системой 2D-освещения. Остальное время я потратил на реализацию деревьев квадрантов (quadtree).

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

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

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

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

У Радислава Гандапаса есть отличная книга Полная Ж. В ней говорится о том, как оценить направления своей жизни, и как разработать план развития.

Мне захотелось создать инструмент, который будет в моем смартфоне и поможет составить мой радар.

На фотографии дипломы дантиста и зубного врача конца 19 века.


Прошло более 100 лет. Дипломы большинства организаций и по сей день не отличаются от выдаваемых в 19 веке. Казалось бы, раз все и так хорошо работает, то зачем что‐то менять? Однако не все хорошо работает. У бумажных аттестатов и дипломов есть серьезные недостатки из‐за которых теряются время и деньги:

• Бумажные дипломы выпускать долго и дорого. Необходимо тратиться на их дизайн, специальную бумагу, печать и доставку по почте.
• Бумажный диплом легко подделать. Если же делать его сложно подделываемым, добавляя водяные знаки и другие методы защиты, то цена создания сильно возрастает.
• Информацию о выданных бумажных дипломах нужно где‐то хранить. Если произойдет взлом реестра, в котором хранится информация о выданных документах, то невозможно будет более проверить их подлинность. Ну, бывает, что базы данных взламывают.
• Запросы о подлинности сертификатов обрабатываются вручную. Из‐за чего процесс затягивается на недели.

Некоторые организации решают эти проблемы за счет выпуска цифровых документов. Они могут быть следующих видов:

1. Сканы и фотографии бумажных документов.
2. PDF сертификаты.
3. Цифровые сертификаты различных видов.
4. Цифровые сертификаты, выпущенные на едином стандарте.

Разберем каждый вид подробнее

Сканы и фотографии бумажных документов

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

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

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

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

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

После сравнительно недавнего анонса компанией Mozilla запуска поддержки DNS-over-HTTPS (DoH) в продакшн в сети не утихают споры, зло это или благо. По моим ощущениям, позиция "зло" базируется в основном на том, что при этом манипуляция вашими DNS-запросами даже в полезных для вас целях будет затруднена, поэтому я пока что остаюсь на позиции "благо".

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

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

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

Всем привет, в преддверии старта нового потока по курсу «Разработчик Golang» хотим поделиться с вами переводом интересной статьи, в первой части которой разбираются элементы, которые есть в Go. Поехали.



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

Перед прочтением: Выше приведен отрывок из книги Алан А. А. Донована и Брайана В. Кернигана «Язык программирования Go». страница XIV. Пункты, упомянутые ниже, являются кратким и несколько неполным объяснением терминов, используемых при проектировании языка программирования. Я попытался объяснить все концепции с точки зрения программирования на Go. Все пункты, упомянутые ниже, не моего авторства, они взяты из других выдержек. Я никоим образом не защищаю Go или любой другой язык.

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

1. Человеческим языком объяснить, что такое интерфейсы.
2. Объяснить, чем они полезны и как вы можете использовать их в своём коде.
3. Поговорить о том, что такое interface{} (пустой интерфейс).
4. И пройтись по нескольким полезным типам интерфейсов, которые вы можете найти в стандартной библиотеке.

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

Многие ругают CMake, и часто заслуженно, но если разобраться, то не всё так плохо, а в последнее время очень даже неплохо, и направление развития вполне позитивное.

В данной заметке я хочу рассказать, как достаточно просто организовать заголовочную библиотеку на языке C++ в системе CMake, чтобы получить следующую функциональность:

1. Сборку;
2. Автозапуск тестов;
3. Замер покрытия кода;
4. Установку;
5. Автодокументирование;
6. Генерацию онлайн-песочницы;
7. Статический анализ.

Кто и так разбирается в плюсах и си-мейке может просто скачать шаблон проекта и начать им пользоваться.

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

Что такое Makefile-ы?

Makefile — невероятно полезный инструмент автоматизации, который можно использовать для запуска и сборки приложений не только на Go, но и на большинстве других языков программирования.

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

Если вы используете Go для создания веб-сервисов, то Makefile поможет решить следующие задачи:

• Автоматизация вызова простых команд, таких как: compile, start, stop, watch и т. д.
• Управление специфичными для проекта переменными окружения. Он должен подключать файл .env.
• Режим разработки, который автоматически компилируется при изменении.
• Режим разработки, который показывает ошибки компиляции.
• Определение GOPATH для конкретного проекта, чтобы мы могли хранить зависимости в папке vendor.
• Упрощенный мониторинг файлов, например, make watch run = «go test. / ...»

Не так давно Mail.Ru Cloud Solutions (MCS) и cервис Добро Mail.Ru запустили проект «Облако для благотворительных фондов», благодаря которому некоммерческие организации могут бесплатно получить ресурсы облачной платформы MCS. Благотворительный фонд «Арифметика добра» принял участие в проекте и успешно развернул часть своей инфраструктуры на базе MCS.

НКО после прохождения валидации может получить от MCS виртуальные мощности, но дальнейшая настройка требует определенной квалификации. В этом материале мы хотим поделиться конкретными инструкциями по настройке сервера на базе Ubuntu Linux для работы основного сайта фонда и ряда поддоменов с использованием бесплатных SSL-сертификатов. Для многих это будет простое руководство, но надеемся, что наш опыт будет полезен для других некоммерческих организаций, и не только.

На этой неделе я начал работать над своим движком для игры Vagabond и приступил к реализации шаблона entity-component-system.

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

Введение

Мотивация

Я не буду рассказывать о преимуществах ECS перед объектно-ориентированным подходом, потому что с этим хорошо справились многие люди до меня. Одним из первых про ECS рассказал на GDC 2002 Скотт Билас. Среди других знаменитых введений в тему можно назвать Evolve Your Hierarchy Майка Уэста и главу Components из потрясающей книги Game Programming Patterns Роберта Нистрома.

Вкратце скажу, что задача ECS — создание ориентированного на обработку данных подхода к игровым сущностям и удобное разделение данных и логики. Сущности (Entities) составляются из компонентов, содержащих данные. А системы, содержащие логику, обрабатывают эти компоненты.

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

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

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

В тестах A/B мы попытались замедлять выдачу страниц с шагом 100 миллисекунд и обнаружили, что даже очень небольшие задержки приводят к существенному падению доходов. — Грег Линден, Amazon.com

По опыту, низкая производительность проявляется одним из двух способов:

• Операции, которые хорошо выполняются в небольших масштабах, становятся нежизнеспособными с ростом числа пользователей. Обычно это операции O(N) или O(N²). Когда база пользователей мала, всё работает отлично. Продукт спешат вывести на рынок. По мере роста базы возникает всё больше неожиданных патологических ситуаций — и сервис останавливается.
  
• Много отдельных источников неоптимальной работы, «смерть от тысячи порезов».

DevOps- и SRE-инженеры уже, наверное, не раз слышали о Prometheus.

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

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

Что такое Prometheus?
Зачем он нужен?
Чем он отличается от других систем?

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

Буквально на днях произошло большое событие для сообщества SvelteJS, да и вообще, как мне кажется, для всего современного фронтенда — долгожданный релиз Svelte 3! Посему, под катом перевод статьи автора Svelte и прекрасное видео с его доклада на YGLF 2019.

У нас не очень простое собеседование. Нужно пройти 3 шага:

1. Прислать резюме, программист его посмотрит, лайкнет если всё хорошо. Рекрутер позвонит, задаст несколько вопросов.
2. Встретиться или созвониться с нами. Узнаем, какой вы специалист.
3. Прийти на тестовый день. Познакомиться с командой и поработать вместе. Пообщаться с техническим директором, обсудить зарплату и получить оффер.

Я три месяца был тем программистом, который оценивает резюме. Мне есть о чём с вами поговорить.