В этой статье речь пойдёт в основном о домашних (бытовых) компьютеров, выпускаемых в Советском Союзе с начала 1980-х годов. А о более ранних и не бытовых моделях можно почитать, например, в статье — «Информатика и электроника: забытые рекорды».

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

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

Несмотря на свои размеры, контролька обладает довольно большим функционалом по сравнению со своими китайскими собратьями с AliExpress.

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

Второе, контролька может измерять напряжение в диапазоне от 0 до 50 вольт.

Третье, контролька имеет защиту от переплюсовки.

И при всех своих преимуществах, печатная плата нашего измерительного прибора меньше спичечного коробка.

«Всё намного сложнее, чем кажется на первый взгляд.»

Закон Мерфи.

Дисклеймер: Автор абсолютно уверен, что все поставленные задачи можно было решить иным способом. Лучше, дешевле, умнее, креативнее… Но вышло так, как вышло. Собственно, автор придерживается точки зрения, что обАСУчивание дач — процесс творческий и субъективный: «Я художник, я так вижу». Вместе с тем автор способен также к объективному восприятию информации, а потому открыт для обмена мнениями и опытом, тем более, что творческий процесс продолжается.

Начало здесь.

Итак, «мозг» у нашей «ленивой автоматики» есть. Теперь нужно подобрать «руки и ноги», то бишь исполнительные устройства. Как уже писал выше, сначала думал о соленоидных клапанах. Очень заманчива их простота – подал напряжение, и клапан сработал, снял – вернулся в исходное состояние. Нужно всего два провода. И на первый взгляд таких клапанов на Али – море. Стоимость полдюймовых – чуть ли не от 300р. Исполнение, правда, незащищённое, но можно что-нибудь придумать. Однако почитав отзывы, пришлось отвергнуть этот вариант. Основная проблема – сильно греются. Пишут, что за 10 минут работы может нагреться до 60-70 градусов. Очевидно китайские братья сэкономили на обмотке. Для кратковременных включений оно ничего, но мне-то нужно чтобы клапан работал часами. Если клапан сгорит, а мы в отъезде, то заменить его будет некому, и дача останется без полива.

Потому пришлось переключиться на другой вариант – шаровой клапан с электродвигателем. В АСУ ТП такой называется MOV – motor operated valve. Для его работы нужно уже три провода – один на команду открытия, второй на команду закрытия, и общий. Таких тоже на Али много. Есть и двухпроводное исполнение, где обратный ход обеспечивается конденсатором. Но насколько надёжен такой конденсатор? В общем, решил не искушать судьбу, и взял трёхпроводные клапана, в защищённом исполнении. Работают от 12 вольт. Стоимость каждого - в районе 1200р. Купил три — поскольку выходов «открытый коллектор» у контроллера пять, два решил оставить про запас, в расчёте на будущие задумки и расширения. Но всё равно, хотя такой клапан и надёжен, хотелось бы контролировать – течёт через него вода или нет? Снова выручил Алиэкспресс. Там же нашлись полдюймовые дачтики потока. Стоят недорого, 130р., и отзывы, вроде, неплохие. Таким образом, стала вырисовываться общая схема – управляем насосом и тремя клапанами, расход через каждый клапан контролируем датчиком. В исходном положении все клапана открыты, по необходимости закрываем один или два.

Данных становится все больше. Важно уметь эффективно хранить и обрабатывать их для решения сложных бизнес-задач. Одним из первых шагов на пути к успешной стратегии является выбор технологии хранения, поиска, анализа и отчетности по данным. Как выбрать между базой данных, Data Warehouse и Data Lake? Рассмотрим ключевые различия и когда следует использовать каждое.

Мы выложили в публичный доступ гигантский датасет для детекции речи (voice activity detection).

Датасет содержит порядка 150 тысяч часов аудио более чем на 6,000 языках. Количество уникальных ISO-кодов данного датасета не совпадает с фактическим количеством языков, так как близкие языки могут кодироваться одним и тем же кодом.

Данные были размечены для задачи детекции голоса при временной дискретизации примерно в 30 миллисекунд (или 512 семплов при частоте дискретизации 16 килогерц).

Данный датасет распространяется под лицензией CC BY-NC-SA 4.0.

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

Проджект-менеджер - (П)
Заказчик - (З)

Стою около мольберта с красками и кисточками, готовый к работе и заряженный на успех:
(П): - Коллеги, вы сказали, что вам срочно необходима картина. Что вам нужно изобразить?
(З): - Как что? Картину.
(П): - Это понятно, что картину. Что на ней должно быть изображено?
(З): - Ну ты же занимаешься картинами, ты нам и скажи.
(П): - Эм... ну хорошо. На картине должно быть дерево?
(З): - Нет.
(П): - На картине должна быть река?
(З): - Нет.
(П): - На картине должна быть лошадь?
(З): - Ты что, дурак? При чём тут лошадь?
(П): - Но вы же не говорите конкретно, что вам нужно.
(З): - Очевидно, что никакой лошади там не должно быть.
(П): - Хорошо. На картине должен быть дом?
(З): - Да.
(П): - Отлично. Это уже хоть что-то. И какой должен быть дом?
(З): - Я понятия не имею, мне нужна картина. Может знает мой коллега.
(П): - Коллеги, какой нужен дом на картине?
(З)-2: - Что значит "какой"? Какой вы обычно рисуете?
(П): - По-разному, в зависимости от требований. Может быть деревянный, может каменный. Может быть одноэтажный, может многоэтажный. Может вообще избушка на курьих ножках.
(З)-2: - Пусть будет каменный многоэтажный.
(П): - Вы уверенны?
(З)-2: - Да я вообще не знаю, зачем нам дом на нашей картине. Нам же нужно изобразить машину.
(П): - Какую машину?
(З)-2: - Ну как, обычную спортивную машину. Коллега вам разве не сказал? А дом - это так, на фоне, незначительная деталь.
(З): - Ну да, очевидно же, что нужно было нарисовать машину.
(П): - Так а почему вы об этом сразу не сказали?
(З): - Я думала, что это и так понятно.
(П): - Хорошо. Есть какие-то требования к изображению машины?
(З): - Просто нарисуйте обычную чёрную спортивную машину.
*Рисую машину. Передаю на утверждение*
(З): - Зачем вы нарисовали двери у машины?
(П): - ???
(З): - Понятно же, что двери не нужно было рисовать.
(П): - Не бывает же машин без дверей. Зачем вам такая картина?
(З): - А это уже наше дело. Убирайте двери у машины. И круглые колёса тоже вызывают большие сомнения. И кстати, где дерево на картине?
(П): - ...

Я большой поклонник автоматизированных тестов и достаточно дисциплинированный их автор. Проектирование ПО крайне сложно реализовать функционально корректно и ещё сложнее избежать регрессии в дальнейшем. Как сказал Майкл Фезерс, «легаси-код — это весь код, у которого нет тестов».

Некоторые вещи, например, конечные точки серверов, схемы баз данных и компоненты библиотек UI тестировать очень просто.

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

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

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

В статье рассказывается, как разработать навык для платформы Яндекс.Диалоги, используя Java и фреймворк Spring Boot, а затем развернуть его в Яндекс.Облаке.

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

В действующем 184-ФЗ “О техническом регулировании”, ратифицированный Россией при присоединении к ВТО, требуется, чтобы любая продукция была безопасна для: «предупреждения действий, вводящих в заблуждение приобретателей, в том числе потребителей» (ст. 6, 46 184-ФЗ). Двухступенчатая система разделения техрегламентов и ГОСТов, согласно статье 46 184-ФЗ, становится в России однступенчаиой. Для реализации этих требований вводятся технические регламенты, которых прогнозируется около 2000. В технических проектах термины являются юридически основными условиями. Создание словаря - облегчит выбор необходимых  терминов.

Участие России в ВТО потребовало стандартизации терминов и определений, для: «предупреждения действий, вводящих в заблуждение приобретателей, в том числе потребителей» (ст. 6, 46 184-ФЗ). Двухуровневая система разделения технических регламентов и ГОСТов, обусловленная их обязательным и добровольным характером, согласно статье 46 184-ФЗ, преобразуется в одноуровневую. В современном российском обществе, когда правила статьи 46 указа 184-ФЗ “О стандартизации” и ГОСТы являются необходимыми к выполнению, появляется потребность в применении и сравнении тысяч терминов. В целях упрощения работы со множеством терминов  был создан этот словарь.

Хотела начать текст с шутки про то, что раз инструкции никто не читает, то и писать их не обязательно. Однако 14 лет работы в IT-сфере доказывают, что это всё же довольно глупая шутка. В современных компаниях (не только в IT, но и особенно в IT!) на документации завязаны практически все процессы от проектирования ПО и ведения бэклога до эксплуатации и поддержки пользователей. Люди со стороны часто не догадываются, что в командах кроме суровых разработчиков, дотошных тестировщиков, внимательных сисадминов, осторожных безопасников и продвинутых девопсов трудятся технические писатели. Как правило, они одновременно суровые, дотошные, внимательные, осторожные и продвинутые, потому что именно на них лежит ответственность как за внутреннюю документацию, так и за корректные, грамотные, лаконичные и точные инструкции для пользователей. И писать желательно без девяти прилагательных в одном предложении, как строчкой выше 🙂

Сегодня поговорим об этих ребятах, о профессии, о людях в ней и о том, стоит ли войти в айти именно через вакансию техписа?

NB И да, обязательно читайте цитаты членов сообщества техписов — они рассказывают о самом актуальном в профессии из первых рук.

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

Этой статьёй я открою серию материалов про управление требованиями на разных этапах проекта.  Уже больше 10 лет я работаю в IT и успела побывать бизнес аналитиком, системным аналитиком и руководителем проектов. Также я выступаю в роли ревьюера на курсе «Системный аналитик». 

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

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