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

Как только кто-либо из нашей команды вносит изменения в код (читай «мерджит feature-ветку в develop»), наш билд-сервер:

• Собирает исходный код и установщик приложения
  
  • проставляет номер сборки, каждый раз увеличивая последнюю цифру. Например, текущая версия нашего ПО 3.3.0.202 – часть 3.3.0 когда-то ввёл разработчик (привет, SemVer), а «202» проставляется в процессе сборки.
  • В процессе анализирует качество кода (с использованием SonarQube) – и отправляет отчёт во внутренний SonarQube,
• Сразу после сборки запускает автотесты (xUnit) и анализирует покрытие тестами (OpenCover),

Также, в зависимости от ветки, в которую были внесены изменения, могут быть выполнены:

• отправка сборки (вместе с changelog-ом) в один или несколько телеграм-каналов (иногда удобнее брать сборки оттуда).
• публикация файлов в систему автообновления ПО.

Под катом о том, как мы научили Gitlab CI делать за нас бОльшую часть этой муторной работы.

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

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

В том году я уже писал статью об интерфейсах систем диспетчеризации, она получилась большая, и в ней все рассказано в общих чертах, здесь же я хочу рассказать более конкретно о своих наработках и своем опыте. Буду придерживаться в первую очередь системам вентиляции, так как они чаще всего встречаются на объектах и по нима больше кейсов. Так же, будут примеры с разных устройств, панелей 7 дюймов и мониторов около 27 дюймов. Ну что, поехали.

В этой подборке представлены полезные малоизвестные консольные Linux утилиты. В списке не представлены Pentest утилиты, так как у них есть своя подборка.

Осторожно много скриншотов. Добавил до ката утилиту binenv.

binenv — cамая интересная утилита для установки новых популярных программ в linux, но которых нет в пакетном менеджере.

• можно ли git «подстроить» под тот процесс разработки, который мне нужен?
• будет ли менеджер и заказчик удовлетворён этим процессом?
• будет ли легко работать разработчикам?
• смогут ли новички быстро включиться в процесс?
• можно ли процесс относительно легко и быстро изменить?

Привет, Хабр! Вам приходила мысль сделать свою систему управления проектами и задачами? Нам да! И мы делаем YouGile. 

Знаете, в чем самая большая сложность? Выбрать и сфокусироваться на одном востребованном направлении продукта. Вообще такая задача есть везде, но тут она особенно масштабная. 

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

У нас есть внутренний документ, в котором собран обзор 52 систем управления проектами, и он постоянно обновляется и используется в трудные моменты выбора приоритетов.

Текст невероятно длинный (проскроллите до конца?) Внизу есть таблица с кратким содержанием.

И если у вас есть свой взгляд на какую-либо систему – прошу дополнять, пишите в комментариях. 

Приветствую любителей питона. Как-то раз я невзначай, сунул палец в ctypes. И знаете, мне понравилось. Особенно блок ввода с клавиатуры и мыши. И первое, что мне сбрело в голову,- "А почему бы не написать локер для винды на питоне, с разблокировкой по флешке, как ключом" (Не спрашивайте почему именно это, я сам не знаю). И тут пошло поехало моё воображение. Сейчас я распишу с чем вам придётся столкнуться для его написания.

Ну что ж, приступим!

Первым делом создадим граф часть локера. Не будем же мы делать тупо белый лист.

Назовём . . . locker.pyw

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

Как показывает собственный опыт - если разработчик пишет код, который взаимодействует с внешним миром, то закон Мерфи сработает быстрее, чем хотел бы того этот самый разработчик. И дело даже не в том, что в этом случае появляются зависимости от доступности внешнего мира и стороны принимающей данные - часто ошибки появляются на стороне кода отправляющего данные из-за недостаточной его проверки, полагаясь на "ну, код вроде выглядит нормально, да и unit-тест есть на это". Но должного ли качества этот самый тест, и фиксирует ли он то, что надо? А что будет, если состав данных будет совсем не такой, как в тесте?

В этот момент появляется желание посмотреть "так что же на самом деле отправляет my-awesome-lib?", и если это желание возникает и у тебя, мой дорогой читатель, и отправка происходит посредством протокола HTTP - то, возможно, у меня для тебя есть "ещё одна тулзовина для отладки HTTP запросов" в твою коллекцию (бесплатно, без регистрации).

Git имеет репутацию запутывающего инструмента. Пользователи натыкаются на терминологию и формулировки, которые вводят в заблуждение. Это более всего проявляется в "перезаписывающих" историю командах, таких как git cherry-pick или git rebase. По моему опыту, первопричина путаницы — интерпретация коммитов как различий, которые можно перетасовать. Однако коммиты — это не различия, а снимки! Я считаю, что Git станет понятным, если поднять занавес и посмотреть, как он хранит данные репозитория. Изучив модель хранения данных мы посмотрим, как новый взгляд помогает понять команды, такие как git cherry-pick и git rebase.

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

Туториал, как сделать электронное пианино, из детских воспоминаний, на Unity 3D.

На примере разработки проекта, рассмотрим темы:

- Изменение скорости воспроизведения и высоты звука через Pitch;
- Использование аудиомикшера и постэффектов на мастер-канале микшера.

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

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

- 3 ресурса с гайдами

- сайт с учебными модулями

- 8 книг

- ресурс с примерами архитектуры

Все это под катом!

Вторая часть — https://habr.com/ru/post/563484/

Вокруг темы синтеза речи сейчас много движения: на рынке есть огромное число тулкитов для синтеза, большое число закрытых коммерческих решений за АПИ (как на современных технологиях, так и на более старых, т.е. "говорилки") от условных GAFA компаний, большое количество американских стартапов, пытающихся сделать очередные аудио дипфейки (voice transfer).

Но мы не видели открытых решений, которые бы удовлетворяли одновременно следующим критериям:

• Приемлемый уровень естественности речи;
• Большая библиотека готовых голосов на разных языках;
• Поддержка синтеза как в 16kHz так и в 8kHz из коробки;
• Наличие своих собственных голосов у авторов решения, не нарушающих чужие права и лицензии;
• Высокая скорость работы на "слабом" железе. Достаточная скорость работы на 1 потоке / ядре процессора;
• Не требует GPU, команды ML инженеров или какой-либо дополнительной тренировки или для использования;
• Минимализм и отсутствие зависимостей / использование в 1 строчку / не надо ничего собирать или чинить;
• Позиционируется именно как готовое решение, а не очередной фреймворк / компиляция чужих скриптов / тулкитов для сбора плюсиков;
• Решение никак не связано и не аффилировано с закрытыми экосистемами и продуктами Гугла / Сбера / Яндекса / вставить нужное;

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

На днях у меня появилась довольно интересная идея для статьи, основанная на следующей предпосылке: на Хабре ни разу не рассказывали об организации энтерпрайз разработки "от и до". В плане совсем с нуля и хотя бы до комфортного минимума. За отправную точку я буду брать ситуацию полнейшего хаоса, когда какой-то код существует на машине единственного разработчика, нет системы контроля версий, нет тестовых сред, код объектов БД существует только внутри эталонной продуктивной базы данных, нет никаких процессов сборки и установки, контроля качества кода и так далее. Возможно читатель задастся вопросом "Такое бывает в 2020 году? Разве кто-то еще так разрабатывает?" и будете только отчасти правы. Предлагаю обсудить детали под катом.

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

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

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

Git – очень мощный инструмент, который практически каждый разработчик должен использовать ежедневно, но для большинства из нас git сводится к нескольким командам: pull commit push. Однако, чтобы быть эффективным, продуктивным и обладать всей мощью git, необходимо знать ещё несколько команд и трюков. Итак, в этой статье мы исследуем функции git, которые просто запомнить, применять и настроить, но которые могут сделать ваше время с git гораздо более приятным.

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

1. Специфика англоязычного резюме

Предыстория или как родился этот проект