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

На сегодняшний день множество IT-компаний сталкиваются с проблемой поиска сотрудников в своем регионе. Все больше предложений на рынке труда связаны с возможностью работы вне офиса – удаленно.

Работа в режиме full-time remote предполагает, что работодатель и работник связаны четкими трудовыми обязательствами: контрактом или трудовым договором; чаще всего, определенным нормированным графиком работы, стабильной зарплатой, отпусками и прочими особенностями, которые зачастую присущи тем, кто проводит свой рабочий день в офисе.
Преимущества постоянной удаленной работы для каждого, кто решил оставить офис, свои. Возможность работать на крупные зарубежные компании без переезда в другой географический регион, стабильность, в сравнении с freelance – это, наверное, основное, что может привлечь нашего соотечественника. Высокий уровень конкуренции – вот основная сложность, с которой сталкивается соискатель, выходя на поиски работы на международном рынке труда.

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

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

Код доступен на гитхабе. Инструкции по установке — для Linux, macOS и (экспериментально) Windows.

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

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

Язык программирования — это технологичный продукт, но не все так просто

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

Один из самых ярких примеров: цифровая фотография, которая в 1990-х была вообще никакой, но спустя всего 20 лет привела к краху такого монстра XX-го века, как Kodak (который, кстати говоря, первым и сделал прототип цифровой камеры).

Перед тем как начать реализацию новой фичи, приходится изрядно поломать голову.

Разработка сложного функционала требует тонкой координации усилий коллектива инженеров.

И одним из важнейших моментов является вопрос распараллеливания задач.

Возможно ли избавить фронтовиков от необходимости ждать реализацию бэка? Есть ли способ распараллелить разработку отдельных фрагментов UI?

Тему распараллеливания задач в веб-разработке мы и рассмотрим в этой статье.

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

Поэтому, я создал Метод управления проектной организацией «Pulse management» — Метод Пульса (далее Метод). Это набор рекомендаций и Правил на основе Теории Ограничений, Agile-подходов и проектного управления обеспечивающий выполнение обязательств Организацией вовремя и в полном объеме в условиях ограниченных ресурсов и высокой неопределенности содержания проектов.

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

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

• Дорого, сложно найти.
• Держать компетенцию желательно распределенно.
• Не всегда уживаются вместе в силу конкуренции, бывает.
• Завышенные требования

Здравствуйте!

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

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

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

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

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



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

Автор материала, перевод которого мы сегодня публикуем, собирается продемонстрировать подобное «превращение» на примере классической задачи «Fizz Buzz Test». Эта задача заключается в том, чтобы вывести список чисел от 1 до 100, заменив некоторые из них особыми строками. Так, если число кратно 3 — вместо него нужно вывести строку Fizz, если число кратно 5 — строку Buzz, а если соблюдаются оба этих условия — FizzBuzz.

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

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

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

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

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

Исследование, проведенное Google, имело два ключевых вывода:

• Пользователю нужно всего 1/50 до 1/20 секунды, чтобы оценить, красивый сайт или нет.
• «Визуально сложные» сайты оцениваются как менее красивые, чем их простые аналоги.

Другими словами, исследование показало — чем проще дизайн, тем лучше.

Но почему?

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

Приступим!

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

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



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

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

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

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

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

В 1991 году Гради Буч, видимо, устал от такого безобразия, и предложил делать сборку всего проекта каждый день, чтобы выяснять несовместимости не в день релиза, а пораньше — и назвал этот подход Continuous Integration.

Производительность — это один из важнейших вопросов, встающих перед разработчиками веб-страниц или веб-приложений. Никто не будет рад «падающему» от чрезмерной нагрузки приложению, или странице, которая загружается целую вечность. Пользователи веб-сайтов не готовы слишком долго ждать их загрузки или приведения их страниц в рабочее состояние. Согласно данным Kissmetrics, 47% посетителей ожидают, что веб-сайт загрузится менее чем за 2 секунды. 40% посетителей покинут сайт в том случае, если его загрузка займёт более 3 секунд.



Автор материала, перевод которого мы сегодня публикуем, говорит, что, если учитывать вышеприведённые цифры, становится ясно, что производительность — это то, о чём всегда стоит помнить веб-разработчикам. Здесь будут приведены 12 рекомендаций по улучшению производительности JS-проектов.

Привет Хабралюди!
Это мой первый пост, поэтому не судите строго. Я хочу начать вольный перевод книги John Torjo «Boost.Asio C++ Network Programming» вот ссылка на нее.

Содержание:

• Глава 1: Приступая к работе с Boost.Asio
• Глава 2: Основы Boost.Asio
  
  • Часть 1: Основы Boost.Asio
  • Часть 2: Асинхронное программирование
• Глава 3: Echo Сервер/Клиент
• Глава 4: Клиент и Сервер
• Глава 5: Синхронное против асинхронного
• Глава 6: Boost.Asio – другие особенности
• Глава 7: Boost.Asio – дополнительные темы

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

Привет, Хабр! Представляю вашему вниманию перевод статьи "Perils of Constructors" автора Aleksey Kladov.

Один из моих любимых постов из блогов о Rust — Things Rust Shipped Without авторства Graydon Hoare. Для меня отсутствие в языке любой фичи, способной выстрелить в ногу, обычно важнее выразительности. В этом слегка философском эссе я хочу поговорить о моей особенно любимой фиче, отсутствующей в Rust — о конструкторах.

Что такое конструктор?

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

1. Вы устанавливаете инварианты в конструкторе.
2. Каждый метод заботится о сохранении инвариантов.
3. Вместе эти два свойства значат, что можно думать об объектах как об инвариантах, а не как о конкретных внутренних состояниях.

Конструктор здесь играет роль индукционной базы, будучи единственным способом создать новый объект.

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

Судя по комментам habr.com/ru/post/460831/#comment_20416435 в соседнем посте и развернувшейся там дискуссии, на Хабре не помешает статья, как правильно передавать аргументы в конструктор или сеттер. На StackOverflow подобного материала полно, но тут что-то я не припомню.

Потому что пример в той статье полностью корректен, и автор статьи абсолютно прав. Вот этот пример:

// Хорошо.
struct person {
  person(std::string first_name, std::string last_name)
    : first_name{std::move(first_name)} // верно
    , last_name{std::move(last_name)} // std::move здесь СУЩЕСТВЕНЕН!
  {}
private:
  std::string first_name;
  std::string last_name;
};

Такой код позволяет покрыть все (ну ладно, почти все) возможные варианты использования класса:

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


CC-BY-SA, Vadim Rybalko

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

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