1. TabNine

Если вам важна скорость — TabNine стоит попробовать хотя бы ради этого. Расширение — лёгкий AI-ассистент, который работает как умный автодополнитель кода, непохожий на аналоги вроде Codeium или Copilot.

TabNine обучен на миллионах строк открытого кода и умеет предсказывать, что вы напишете дальше, с учётом контекста проекта и языка. Отлично справляется с рутинными вещами: автозавершает функции, переменные, конструкции — всё быстро и чаще всего в тему.

Кому подойдёт: тем, кто хочет ускорить набор кода, но не готов передавать весь проект в облако или открывать чат с Copilot. Поддерживает офлайн-режим и локальное обучение модели.

Плюсы:

• Работает из коробки, не требует тонкой настройки;
• Есть локальная версия — удобно для закрытых проектов;
• Поддерживает большинство языков и фреймворков.

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

2. GitLens

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

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

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

Плюсы:

• Информация о коммитах отображается прямо в редакторе под строкой;
• Есть таймлайн изменений файла;
• Удобный diff по коммитам, авторам, веткам и даже фрагментам кода.

Чем полезен: помогает быстрее разбираться в чужом коде, искать причины бага или откатывать ошибки. Особенно ценится за то, что делает Git прозрачным и доступным прямо в процессе разработки.

3. Error Lens

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

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

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

Плюсы:

• Ошибки и предупреждения отображаются прямо в редакторе, рядом со строкой кода;
• Гибкая настройка стилей и уровня детализации сообщений;
• Ускоряет процесс отладки, особенно при работе с большими файлами.

Чем полезен: минимизирует время на поиск и анализ ошибок, позволяя сразу фокусироваться на их исправлении. Это особенно ценно, когда вы пишете код в реальном времени или работаете с новыми библиотеками, где легко допустить мелкие недочёты.

4. Path Intellisense

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

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

Кому подойдёт: всем, кто устал вручную прописывать длинные relative-пути или путаться в структуре проекта. Особенно выручает на фронтенде, где модулей десятки и легко ошибиться в названии.

Плюсы:

• Подсказки появляются автоматически при наборе пути;
• Поддерживает большинство языков и фреймворков;
• Учитывает jsconfig.json и tsconfig.json при работе с alias-ами.

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

5. TODO Highlight

TODO Highlight подсвечивает комментарии с задачами (например, TODO, FIXME, NOTE) прямо в коде, делая их заметными и удобными для отслеживания. Расширение помогает не терять важные заметки, которые вы оставляете в коде, и быстро находить места, требующие доработки.

Можно настроить ключевые слова, цвета подсветки и даже добавить свои собственные метки. Работает с любыми языками программирования и интегрируется с панелью задач VSCode для удобного обзора всех TODO в проекте.

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

Плюсы:

• Яркая подсветка TODO-комментариев прямо в редакторе;
• Гибкая настройка ключевых слов и стилей;
• Интеграция с панелью задач для быстрого обзора.

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

6. Prettier – Code formatter

Prettier — расширение, которое автоматически приводит ваш код к единому стилю, избавляет от ручной правки отступов, кавычек и переносов. Оно поддерживает множество языков (JavaScript, TypeScript, CSS, HTML и другие) и интегрируется с линтерами, чтобы ваш код был не только красивым, но и консистентным.

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

Кому подойдёт: разработчикам, которые хотят экономить время на форматировании, и командам, стремящимся к единообразию кода.

Плюсы:

• Автоматическое форматирование при сохранении или по хоткеям;
• Поддержка множества языков и кастомных настроек;
• Интеграция с ESLint и другими инструментами для проверки кода.

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

7. Live Server

Live Server запускает локальный сервер прямо из VSCode, позволяя просматривать изменения в HTML, CSS и JavaScript в браузере в реальном времени. После сохранения файла страница автоматически обновляется, что исключает необходимость ручного перезапуска или обновления браузера.

Поддерживает кастомные порты, HTTPS, и работает с любыми фронтенд-проектами, от простых HTML-страниц до сложных приложений на React или Vue. Можно настроить, чтобы сервер открывался автоматически при запуске проекта.

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

Плюсы:

• Автоматическое обновление страницы при изменении кода;
• Простая настройка и поддержка HTTPS для безопасного тестирования;
• Лёгкий запуск сервера прямо из редактора.

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

8. Project Manager

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

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

Кому подойдёт: разработчикам, которые ведут сразу несколько проектов, часто переключаются между ними и устали искать нужный путь через File > Open Folder.

Плюсы:

• Быстрое переключение между проектами через интерфейс или хоткеи;
• Поддержка избранного и тэгов;
• Можно автоматически подтягивать все папки из заданной директории.

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

9. Code Spell Checker

Code Spell Checker выявляет орфографические ошибки в комментариях, строках и именах переменных прямо в редакторе VSCode. Расширение подчёркивает опечатки волнистой линией и предлагает варианты исправления через Ctrl+. или Cmd+., что позволяет быстро исправить ошибки.

Поддерживает множество ЯП и словари для разных языков (английский, русский, немецкий — с дополнительными расширениями). Можно добавлять свои слова в пользовательский словарь или игнорировать определённые термины, чтобы адаптировать проверку под проект. Работает с camelCase и snake_case, не помечая их как ошибки.

Кому подойдёт: разработчикам, которые пишут много комментариев или документации в коде, и тем, кто хочет избежать опечаток в строках, API или логах, чтобы повысить читаемость.

Плюсы:

• Мгновенное обнаружение ошибок с подсказками для исправления;
• Гибкая настройка словарей и игнорируемых слов;
• Поддержка технических терминов и различных стилей написания кода.

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

10. REST Client

REST Client позволяет отправлять HTTP-запросы и просматривать ответы непосредственно в VSCode. Достаточно создать файл с расширением .http или .rest, написать запрос в простом текстовом формате, и вы увидите кнопку Send Request для моментального выполнения.

Поддерживает все типы запросов (GET, POST, PUT, DELETE и другие), авторизацию (Basic, OAuth, JWT), переменные окружения и даже генерацию кода на разных языках. Запросы можно сохранять в репозиторий, что удобно для командной работы. Расширение также позволяет использовать динамические переменные по типу {{$timestamp}} или {{$guid}}, всё для гибкой настройки запросов.

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

Плюсы:

• Простая отправка запросов через .http или .rest файлы с кнопкой Send Request;
• Поддержка переменных окружения и авторизации для сложных API;
• Возможность сохранять запросы в репозитории для совместной работы.

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

А какими расширениями пользуетесь вы? Пишите в комментариях!

Что интересно, компания задала датой коммита 27 июля 1978 года, 22:00 по московскому времени. Таким образом, формально коммиту — 47 лет.

Исторический артефакт в прямом эфире

Проект под названием BASIC-M6502 содержит полный исходный код Microsoft BASIC версии 1.1. Это один из самых ранних программных продуктов компании, написанный между 1976 и 1978 годами.

BASIC 1.1 стал основой для множества персональных компьютеров, включая:

• Apple II — революционный домашний ПК от Джобса и Возняка.
• Commodore PET — один из первых массовых компьютеров.
• KIM-1, OSI, PDP-10 — популярные среди хобби-разработчиков системы.

Коммит из прошлого

В коммит-логе можно увидеть:

• Дата: July 27, 1978, 22:00 (GMT+3).
• Автор: Scott Hanselman (Microsoft).
• Файл: m6502.asm — 6955 строк ассемблера.
• Текст коммита: «Microsoft BASIC for 6502».

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

Зачем Microsoft это выложила?

По словам авторов, это попытка сохранить цифровое наследие эпохи ранних ПК. В README подробно описано, почему именно этот код важен:

• Он сделал программирование доступным миллионам пользователей;
• Лицензирование интерпретатора стало основой бизнес-модели Microsoft;
• Код использовался до появления MS-DOS и Windows;
• Интерпретатор легко переносился на разные платформы, заложив принципы кроссплатформенной разработки.

Проект представлен как учебный и исследовательский ресурс, с MIT-лицензией.

Внутри — чистый 6502-ассемблер

Код представляет собой полноценный интерпретатор BASIC, написанный на ассемблере для процессора MOS 6502. Он включает:

• Поддержку арифметики с плавающей точкой.
• Обработку строк и массивов.
• Динамическое распределение памяти.
• Сборку мусора.
• Абстракцию ввода-вывода под разные платформы.

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

Это не просто учебный проект или архив. Это исходный код, с которого началась история Microsoft как софтверной компании. Без него не было бы MS-DOS, Windows и .NET

Мы в Smart Engines занимаемся разработкой софта для распознавания самых разных документов — начиная от паспорта РФ, свидетельства о рождении и заканчивая первичкой вроде УПД или ТОРГ-12, а также банковских карт, номеров телефона и баркодов. Наши библиотеки написаны полностью с нуля (на плюсах), мы уделяем огромное внимание скорости алгоритмов, нейросетям (новым архитектурам, размеру и правильному применению) и оптимизации, за счет чего наш софт портируется на любые архитектуры и может быть использован на любой платформе.

Сегодня продолжим знакомиться через рассказ о нашем софте, на очереди вторая библиотека — Smart Document Engine и ее возможности работы с жесткими и гибкими формами.

Гибкие и жесткие формы

Вначале про сами формы: они могут быть «жесткими» и «гибкими». Жёсткие формы подразумевают, что положение всех объектов на форме может быть задано прямо в виде координат на шаблоне. Самое простое определение для жестких форм — они совпадают «на просвет». Возьмите пару листов А4 с распечатанной жёсткой формой, наложите друг на друга, и места расположения полей точно совпадут. Гибкие формы устроены гораздо сложнее, но все равно имеют свою характерную структуру и топологию.

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

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

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

Также существуют общие для подобных форм проблемы. Правильно интерпретировать галочки в чекбоксах, найти штрихкоды, правильно разметить табличные данные — есть куча проблем, каждая из которых имеет своё state-of-the-art решение и набор алгоритмов, над которыми нужно ломать голову.

Почему не LLM, хотя казалось бы

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

Однако чем сложнее нейросеть, чем глубже степень обучения — тем выше шанс, что она начнёт бредить. Мы все какое-то время назад смеялись над шести-семипалыми героями очередных сгенерированных изображений, сейчас посмеиваемся над сгенерированными сетями текстами с описанием несуществующих фильмов и книг, но смешно ли будет нам (а особенно бухгалтерии), если нейросеть начнет галлюцинировать при распознавании платёжных реквизитов или суммы НДС? И чем выше степень развития сетей — тем менее заметными будут становиться такие ошибки.

В прошлом году на одной из ключевых конференций в области анализа и распознавания документов — ICDAR — учёные традиционно задались вопросом о будущем OCR. И сошлись во мнении, что OCR нисколько не устарела, благополучно развивается и остается наиболее надежным инструментом распознавания. Обеспечить требования консистентности (и ещё всякого такого) информации, извлекаемой из изображения, все равно сможет только старый добрый OCR и прочие детерминированные алгоритмы. И именно их разработкой (и доведением до совершенства) мы и занимаемся.

Вернёмся к библиотеке Smart Document Engine. Как уже говорилось выше, гибкие формы на то и гибкие, что исключительно геометрией на них не обойдёшься — вопрос местонахождения полей решается «на лету». На процесс взаимодействия с библиотекой это влияет в самом конце, на моменте работы с результатом. Перейдем к знакомству с интерфейсом на примере всё того же встраивания в андроид.

Встраивание

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

Логическая и физическая части документа разбираются отдельно, так как в некоторых случаях геометрия вообще не нужна (если результат распознавания документа дальше идёт в базу данных):

Как правило, результат распознавания представляют в виде json-объекта, но для наглядности лучше всего пользоваться html — особенно в случае, когда логические и физические поля имеют больше одного соответствия. Вот простенький генератор html на основе документа:

В результате получается удобная для взаимодействия html-страничка. Если добавить немного фантазии, то можно сразу сделать форму, в которой можно будет проверять и дополнять неуверенно распознанные поля — очень удобно в случае, если качество изображения плохое или документ плохо пропечатан.

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

На этом мы не заканчиваем, ждите новых статей!

✅ подробный протокол встречи (транскрипт),

✅ интеграцию с Google Meet, Zoom, Teams; возможность расшифровки уже записанного аудио или видео встречи,

✅ автоматически подготовленное саммари — ключевые моменты встречи, решения, задачи.

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

Вариант 1: для дейликов или статус-митингов

Наши фавориты:

🤖Fireflies.ai

🤖Supernormal.com

🤖Tactiq.io

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

Ограничения:

• Низкая поддержка многоязычности — нужно выбрать язык встречи заранее. Все, что будет сказано на другом языке, будет проигнорировано, либо может быть записано неверно.

• Трудности с пониманием терминов (например, WSR, RAID и пр.).
• Автоматически сгенерированное саммари, задачи, моменты встречи могут быть неполными или неверными. Не отправляйте саммари другим участникам без предварительной проверки!

Supernormal

• Видеозаписи встреч есть только на платном тарифе ($10/месяц). Если для вас критична запись экрана, бесплатная версия не подойдет;

• Нет аудиозаписи;

• Иногда путает, кто из участников что сказал, или на кого в действительности была назначена задача.

Tactiq.io

• Видеозаписи встреч есть только на платном тарифе (Business $20/месяц);

• 800 минут на аудиозаписи (потом нужно чистить старые записи);

• В обязательном порядке требует интеграцию с Google/Microsoft-календарем;

• В бесплатном тарифе предоставляет 20 кредитов на AI-саммари (после этого будет только транскрипт, который потом можно скормить чату GPT для подготовки саммари);

• В бесплатном варианте нет экспорта саммари/транскрипта (приходится выделять текст на странице и копировать его, что неудобно, к тому же может теряться форматирование).

Fireflies

• Есть режим записи транскрипта без ограничений на их количество (подробнее);

• Умеет обрабатывать загруженные видео- или аудиозаписи митингов;

• Умеет автоматически выгружать саммари в Google Docs, Slack и Confluence (только Cloud).

Вариант 2: для более сложных митингов

Наши фавориты:

🤖 Claap.io

🤖 Bluedot

🤖 Sembly.ai

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

Чем они лучше, чем Fireflies / Supernormal:

• У всех более качественное саммари.
• Они позволяют отредактировать саммари прямо в приложении..

Bluedot

• Его можно интегрировать с Jitsy.

• Максимум 5 митингов на бесплатном аккаунте (на всю жизнь аккаунта);.
• Видеозаписи встреч есть только на платном тарифе ($18/месяц).
• На Basic-плане ($18/месяц) – 1 час на встречу максимум (на тарифе Pro ($25) этого ограничения нет).

Claap.io

• Видеозапись экрана включена по умолчанию, удобно записывать созвоны с демонстрацией экрана;

• Довольно богатая функциональность (например, в одном из платных тарифов заявлена функция на лету переводить с разных языков на заданный).

• Максимум 10 митингов на бесплатном аккаунте (на всю жизнь аккаунта);
• Дорогой: тариф Pro – 24€/месяц, Business – €48/месяц.

Sembly.ai

• Хорошо справляется с переключением между языками во время митинга (русский, английский, французский).

• Всего 1 загрузка (upload) и 1 час онлайн-записи в месяц на бесплатном тарифе.
• Тарифы: $15 или $30 в месяц.
• Не очень удобный формат экспорта PDF.

Как использовать AI-инструменты

Вариант 1. Подключение к онлайн-встрече на примере Fireflies

Зарегистрируйтесь на сайте Fireflies.ai.

Интегрируйте сервис с рабочим календарем (Google Calendar, Microsoft Outlook и др.)

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

Настройте основные параметры в личном кабинете:

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

Установите расширение Fireflies для браузера (Chrome Extension).

Подключите нужные интеграции для хранения МоМ: Google Docs, Notion, Confluence, Microsoft Teams, Slack или другие платформы.

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

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

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

После завершения встречи Fireflies автоматически сохранит аудиозапись, создаст транскрипт и MoM, а затем отправит уведомление о готовности на почту.

Лайфхаки

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

Как это сделать:

• Соберите текстовую расшифровку встречи.
• Отправьте запрос в ChatGPT.com / Deepseek.com / Claude.ai / любой другой другой промт. Текст запроса в AI сильно зависит от того, что вы хотите получить в результате. .

Пример запроса к ИИ:

Привет!

Подготовь, пожалуйста, саммари по протоколу встречи.

В саммари выдели для каждого участника 2 части:

1. “что сделано”,

1. “что нужно сделать”.

Формат результата ожидаю такой:

Person 1

Что сделано:

• задача 1,

• задача 2,

…

Что нужно сделать:

• задача 1,

• задача 2,

…

Person 2

Что сделано:

• задача 1,

• задача 2,

…

Что нужно сделать:

• задача 1,

• задача 2,

…

Person N

…

В качестве Person может быть любой из участников встречи: [перечисли имена участников списком. Имена использовать лучше в том виде, как они записаны в транскрипте, чтобы AI смог сделать четкое сопоставление].

——

[вставь текст транскрипта / подгрузи документ транскрипта]

Если результат не понравится – попробуйте:

Добавить контекст для лучшего результата

1. Роли участников (если еще не было указано),
2. О чем вообще была встреча (например, “это стендап команды разработки”),
3. На какие темы стоит обратить особое внимание.

Уточнить формат результата

• Добавить пример корректного саммари, по модели которого ИИ должен сгенерировать текст.

• Попросить сделать улучшения/правки выданного результата (например, “добавь в результат список участников и дату встречи” или “добавь после каждой задачи ожидаемый срок выполнения”).

• Если один инструмент выдает некачественный результат (например, ChatGPT) — попробуйте другой чат, например, DeepSeek, с тем же промтом. Удивительно, но иногда результат бывает крайне разный.

• Если указанные выше пункты не дали желаемого результата — отредактируйте саммари вручную. Сохраните полученный результат и используйте его в качестве примера ожидаемого результата для саммари следующих встреч.

Вариант использования 2

Если у вас есть файл записи митинга (аудио или видео) — можно использовать те же Fireflies, Claap.io, Sembly.ai, чтобы загрузить файл и получить транскрипт/саммари.

Как можно создавать серию новых аккаунтов

Если у вас есть gmail-почта, например user@gmail.com, то в сервисах можно делать новые аккаунты, используя почтовый адрес вида user+[string]@gmail.com.

Т.е можно регистрировать аккаунты user+1@gmail.com, user+2@gmail.com, …

Все письма, отправленные на эти адреса, приходят в ящик user@gmail.com.

Неудобство, связанное с таким подходом — бывает трудно вспомнить, какой созвон записан в каком аккаунте. Поэтому лучше переносить транскрипт/МоМ в какое-то постоянное место (конфлюенс, гугл-док и пр.).

Итоги в двух словах:

1. В бесплатном варианте рекомендуем использовать Fireflies.ai.
2. В платном варианте — Claap.io ($30/месяц) или Bluedot ($20/месяц). Их также можно использовать бесплатно, каждый раз создавая новые аккаунты по достижению лимита. У Claap.io лимит — 10 митингов на бесплатный аккаунт, у Bluedot — 5. Как можно создавать серию аккаунтов на один ящик gmail, описано выше.

Список протестированных AI-инструментов

• Fireflies.ai
• Claap.io
• Blue Dot
• Sembly.ai
• Supernormal
• Tactiq.io
• Meetgeek.ai
• Turboscribe.ai
• Noota.io
• Noty
• Scribbl
• Colibri.ai
• Otter.ai (transkriptor)
• Screenapp.io
• Laxis
• Meet Transcript – not available anymore
• Transkriptor

Я создал свой проект с полноценной документацией с сылкой на Github по развертыванию n8n на собственном сервере.

Завязка

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

В сети крутился хайп вокруг n8n — open-source, который можно развернуть на любом сервере, и с полной свободой действий. Конечно, до меня не сразу дошло, на официальном сайте очень дорогие тарифы. Поэтому я начал изучать туториалы на Ютубе. В этот момент я даже не подозревал, что эта идея затянет меня на неделю, подарит десятки ошибок и первый полноценный сервер.

Развитие: от ноды до ноды

Railway: первая проба пера

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

Подходящей оказалась платформа Railway. Бесплатный пробный период, $5 бонуса за привязку GitHub — всё выглядело перспективно. Я:

• подключил GitHub;
• получил API-ключ;
• запустил n8n;
• настроил Telegram-бота.

И всё шло нормально, пока не начались проблемы с Telegram Trigger — он просто не отвечал. Ошибок в логах почти не было, но и связи — тоже. Я тратил часы, пробовал разные переменные, гуглил, спрашивал у нейросетей — без толку. Тогда в рекламе мне попался Yandex Cloud с двухмесячным бесплатным периодом. Я решил попробовать развернуть n8n на нем.

Виртуалка, SSH и первый затык

Я развернул ВМ на Ubuntu 20.04 LTS, выбрав её за стабильность и поддержку. Конфигурация:

• 2 vCPU
• 50 ГБ SSD
• Снятие с бонуса: 2683.50 руб/мес

Сгенерировал SSH-ключ через Git Bash. Первый облом: ключ исчез. После нескольких безуспешных попыток изменить его, понял — проще пересоздать ВМ. У Yandex Cloud есть ограничения:

нельзя обновить на лету.

Подключение выглядело так:

Когда получилось зайти — был настоящий кайф. Я обновил систему, установил Docker, понял, что GUI у сервера не будет — только терминал. Ну что ж, поехали.

Docker, docker-compose, и n8n-raw.env

Следующим шагом стал

и файл

В нём я прописал:

Это позволило не держать всё в голове и запускать конфигурации быстрее. Первые ошибки появились почти сразу — что-то не так с путями, потом — с переменными. Без ChatGPT и stackoverflow не обошлось.

Домены и HTTPS

Купил домен

настроил A-записи, скачал сертификаты. Nginx — отдельная песня. Нужно было:

1. Объединить три сертификата в один;
2. Подключить его через конфиг;
3. Настроить редирект на HTTPS.

Вот пример из моего nginx.conf:

Telegram и «почему ты не работаешь?!»

Подключил Telegram Trigger — ноль. Ни один запрос не проходил. Ошибки:

• Lost connection to the server
• Webhook error: unexpected status code 403
• Логи молчали или выдавали бессмысленное.

Проблема оказалась в том, что webhooks шли через HTTP, а всё у меня уже работало через HTTPS. Куки не обрабатывались, туннель API оказался лишним, docker не доверял IP клиента. Пришлось в docker-compose.yml прописывать:

Потом был конфликт сертификатов, SSE и WebSocket. Я потратил день на всё это — и наконец бот ответил.

Разгрузка: спасение в Obsidian и GitHub

Всю документацию, команды, даже ошибки я хранил в Obsidian. Там же создавал шаблоны, чтобы не печатать одни и те же команды. Это было моим вторым спасением после ChatGPT.

Когда всё начало получаться — создал репозиторий. Сейчас там:

• README.md с пошаговыми действиями;
• n8n-raw.env для автоматизации запуска;
• Docker-конфиги.

Проект пока не идеален, но рабочий и повторяемый.

Финал: в этой истории я вырос

Когда Telegram наконец сработал — было 3 часа ночи. Я сидел в темноте, всматривался в терминал и не верил. Всё. Бот работает. HTTPS есть. Docker жив. Я сам развернул свой первый полноценный сервер. Сам. С нуля. С ошибками. Без опыта.

Теперь я могу:

• Развернуть ВМ и подключиться через SSH;
• Настроить Docker и Nginx;
• Создать и связать домен;
• Конфигурировать n8n под прод;
• Документировать всё на GitHub.

Я только начал, но теперь точно знаю — могу не просто тестировать, а создавать решения с нуля.

В 1975 году Гейтс и Пол Аллен создали её для микрокомпьютера Altair 8800. Тогда компания называлась Micro-Soft — с дефисом.

С чего всё началось

Вдохновением для Altair BASIC стала обложка январского выпуска журнала Popular Electronics, где был изображён Altair 8800 — первый массовый персональный компьютер.

Гейтс и Аллен связались с производителем MITS и предложили написать для машины интерпретатор языка BASIC. Программу они поначалу только «продавали на словах» — кода ещё не существовало.

Но спустя бессонные месяцы он появился и это стало первым продуктом будущей Microsoft.

«Самый крутой код, что я писал»

В блоге Gates Notes Билл называет Altair BASIC своим «самым крутым кодом» и вспоминает, как держал в руках метровую распечатку исходников. Теперь эти 157 страниц доступны всем желающим — распечатать, изучать или просто полюбоваться кусочком истории.

Гейтс подчёркивает, что без таких людей, как Стив Балмер и Сатья Наделла, Microsoft не достигла бы того, что есть сейчас: «50 лет — серьёзная отметка и мы не прошли бы этот путь без невероятной команды».

Символичный жест

Журнал Thurrott назвал публикацию кода «самым гейтсовским способом отпраздновать юбилей компании» — и с этим трудно не согласиться. В эпоху ИИ, Xbox и Windows 11, Гейтс вернулся к коду, с которого всё началось — строчкам, написанным на бумаге задолго до IDE и GitHub.

Исходники Altair BASIC доступны наGates Notes, а тем, кто решится их распечатать, придётся запастись терпением — файл состоит из 157 страниц.

Он почти 25 лет пишет код и пережил уже не одну «революцию» в индустрии. Сейчас, по его мнению, мы наблюдаем не конец профессии, а очередной виток развития инструментов.

Больше новостей — в нашем тг-канале «Представляешь»

«Когда я был маленьким…»

Матейс вспоминает, как начинал программировать на стареньком 486-м ПК отца, с книжкой по DOS-командам и QBasic. Без автодополнения, без подсветки синтаксиса, без Stack Overflow.

Только PRINT, библиотеки и надежда, что после очередного запуска программа не вылетит. Каждый новый инструмент — будь то ConTEXT, Eclipse или Stack Overflow — упрощал жизнь, сокращал время на рутину и освобождал место для настоящей работы: понимания задач, архитектуры и решений.

ИИ сегодня — просто следующий шаг в этой цепочке. Как и IDE раньше, он помогает быстрее писать код. Но, как подчеркивает Лагерберг, это не революция. И уж точно не повод увольнять разработчиков.

Что ИИ умеет хорошо — и где спотыкается

ИИ-помощники вроде ChatGPT, Codeium и Windsurf действительно ускоряют повседневную рутину. Надо сгенерировать перевод, сэкономить на бойлерплейте, быстро понять, как устроен новый фреймворк — пожалуйста.

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

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

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

ИИ — не магия, а просто дорогой предсказатель

Многие забывают, что ИИ — это всего лишь продвинутое угадывание следующего слова. Та же логика, что и в автозамене на смартфоне, только с огромными вычислительными мощностями.

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

Почему нужен человек — и, возможно, даже больше, чем раньше

Лагерберг отмечает: даже если ИИ выглядит уверенным, его решения могут быть опасны. Неопытные разработчики, копируя с Stack Overflow, рисковали и раньше. Сейчас они рискуют в разы больше — потому что доверяют коду, который выглядит идеально, но может оказаться полным бредом.

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

Вывод: пусть копилот сидит на пассажирском

Лагерберг продолжит пользоваться ИИ, но с оглядкой.

Он не против помощника — но пусть тот сидит сбоку, а не за рулем. Потому что карту он читает, может, и хорошо. Но рулить всё равно должен человек.

Я — Олег Филон, ментор Эйч Навыки и Senior DevOps Engineer. Мы разберем ключевые инструменты, которые помогают автоматизировать разработку, тестирование и развертывание приложений. Сегодня на повестке — развертывание собственного облака с помощью KVM и libvirt.

О минимальных требованиях и поддержке виртуализации

Сейчас популярная тема на Youtube — Home Lab, или домашняя сеть с кучей компьютерного и сетевого оборудования, часто в выделенном помещении вроде серверной. И один из самых известных блогеров в этом направлении — Jeff Geerling, вот его GitHub. У меня, кстати, тоже есть небольшой блог — здесь можно почитать статьи, а здесь — посмотреть код на Гитхабе.

Однако наша цель гораздо скромнее — мы будем строить на обычном ПК или ноутбуке персональное облако, используя KVM-модуль из ядра Linux и набор утилит libvirt и qemu. Сразу определимся с минимальными требованиями к железу, чтобы попробовать руками всё обсуждаемое.

Мой рабочий ноут — китайский Chuwi GemiBook Plus с процессором Intel N100, 4 ядра, 16GB памяти, nvme диск на 960GB — вполне справляется с такими задачами.

Сразу объяснюсь за невольную рекламу дешёвых китайских ноутов: я не сразу выбрал этот 200-евро-бук. У меня в домашней сети есть несколько SBC (single board computer) на arm64 и risc-V — опыт весьма интересный. Во-первых, Линукс на таких экзотических компьютерах сильно отличается от обычных ПК. Во-вторых, я стал ценить не абстрактные BogoMIPS из dmesg, а реальный отклик в повседневной работе: веб, YouTube, билды приложений. Неудобств нет, а TDP (thermal design power) — 2-5W.

Как и многие из вас, я беспокоюсь, что оставляю углеродный след, но нельзя сравнивать мой Intel 10W N100 и процессор, который греется как утюг, но для глажки бесполезен, и даже наоборот, требует себя охлаждать — сначала мощными кулерами, а в жаркую погоду ещё и кондиционерами с весьма низким КПД. Короче, ваш компьютер справится с 2-3 виртуалками без проблем. Но на всякий случай проверьте, что аппаратная виртуализация поддерживается процессором.

Установить связку KVM+libvirt можно во многие дистрибутивы Linux. Не будем, однако, спешить, а выполним полезную подготовительную работу. Моя основная ОС уже много лет — Ubuntu. В ней есть удобный инсталятор, новые релизы каждые полгода и LTS (Long Term Support) для тех, кто предпочитает стабильность. Есть ещё бесплатный на 5 машин Ubuntu Pro с патчами безопасности в дополнительном репо. Но главная фича, из-за которой я не меняю дистрибутив — поддержка файловой системы ZFS. Вот о ней и поговорим.

Лирическое отступление: что такое ZFS и в чем ее прикол

ZFS — самая сложная из многочисленных ФС. Она является дефолтной во FreeBSD и не только, а также в дистрибутиве Proxmox, который использует OpenZFS. Разница между Open и просто ZFS в лицензии. Оригинальная лицензия не была свободной. Переписывание многих модулей и библиотек, чтобы эту ФС можно было включить в ядро Linux, заняло много лет. В Ubuntu, начиная c версии 20.04, уже можно выбрать ZFS как опцию при установке. Кратко перечислю, что нам даёт ZFS:

1. Встроенное шифрование диска, не нужны никакие LUKS и танцы с бубном.
2. Модные контейнерные OverlayFS, виртульные диски формата QCOW2, используют COW (copy-on-write). ZFS это тоже умеет, можно сказать, она оптимизирована для контейнеров и ВМ.
3. Замечательная фича — встроенный RAIDZ. В моём Proxmox сервере 8 портов SATA, мощный корпус со стойкой на 8 HD. Купил 7 штук одинаковых 4TB дисков, добавил в пул raidZ, в итоге 24TB довольно шустрого хранилища.
4. Можно забыть как кошмарный сон мучения с mdadm, lvm2. Партишены увеличиваются без всякой суеты с PV/VG/LV. Впрочем, XFS это тоже умеет, поговорим позже и о ней.

На будущее: виртуализация никак не привязана к файловой системе, можно использовать то, что уже есть, в том числе и привычный дистрибутив. Буду рассказывать, однако, только об установке на Ubuntu.

Готовимся к установке KVM+libvirt

По умолчанию libvirt создаёт внутреннюю сеть на виртуальном устройстве в режиме nat. Для единственного хоста это не так важно, виртуалка доступна, но полезно настроить плоскую сеть, где ВМ будет иметь свой IP-адрес и физический хост.

Для этого сделаем заранее на хостовой машине виртуальное устройство br0 и будем привязывать виртуалки к этому устройству. Cеть в обычном десктопном Ubuntu настраивается сервисом NetworkManager:

• через графический интерфейс,
• через утилиту интерфейса командной строки nmcli,
• через nmtui с текстовым интерфейсом.

Для серверных конфигураций документация рекомендует netplan. В случае сервера необходимо присваивать хостовым машинам статические IP-адреса вплоть до того, что Proxmox — гораздо более мощный сервер виртуальных машин с возможностью кластеризации, миграции ВМ, ceph и так далее. Он отказался от NetworkManager и требует наличия ethernet порта.

Мы же хотим сохранить удобство десктопной OS и добавить серверные возможности, поэтому будем использовать пакет netplan.io, который вполне совместим с NetworkManager. Вот пример конфигурации для хостовой машины, создающий на физическом ethernet устройстве виртуальный интерфейс br0:

Создав файл /etc/netplan/01-br0.yaml, сначала проверим его корректность: sudo netplan try /etc/netplan/01-br0.yaml, и если Configuration accepted, применяем его: sudo netplan apply .... Посмотрим, что у нас с сетью. Должно быть что-то похожее на это:

Во второй строке вывода стоит мой eth0, который является физическим интерфейсом, он активен (link state UP), но адреса не имеет. В последней строке мой br0, который выступает виртуальным интерфейсом с правильным статическим адресом. Более того, если мы посмотрим настройки с помощью brctl из пакета bridge-utils, то увидим что у нас появился полноценный бридж:

Подготовка к установке KVM+libvirt завершена, возвращаемся к документу с сайта https://sysguides.com/. Для Ubuntu это команда:

На первых порах удобно прибегнуть к десктопному приложению virt-manager, позволяющему создавать, запускать, управлять виртуальными машинами. Под капотом прячется много низкоуровневых утилит, поэтому рано или поздно придётся познакомиться и с libvirt-clients, и с qemu-utils, и с guestfs-tools.

Разворачиваем виртуальные машины

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

Самый простой и знакомый способ создания виртуальной машины — использовать iso-образ. Установка будет напоминать сотни раз пройденные шаги: скачать образ, указать путь к нему, задать имя виртуальной машины, количество оперативной памяти, выделить ядра процессора и так далее.

Расскажу чуть подробнее про пару новых опций для virt-manager. Во-первых, это использование настроенного ранее виртуального интерфеса br0. Во-вторых, формат виртуального диска QCOW2. Вот, например, настройки одной из моих виртуалок:

Здесь показаны 4 размера:

• ls -lh видимый размер файла имиджа;
• du -BM занимаемое место на диске, qemu-img info выдаёт его внутренние параметры, в частности: virtual size — 10 GiB; реальный размер файла disk size — 5.11 GiB.

Это возможности того самого COW (copy-on-write). Виртуальный размер — тот, что мы указали при создании ВМ, а реальный размер файла — сколько фактически места занято на диске. Внутри ВМ мы будем видеть эту разницу как свободное место, и оно также остаётся свободным на хостовой ФС. Можно заказывать размер диска с запасом, QCOW2-формат не займёт место, пока оно не потребуется под данные внутри ВМ.

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

Общий вид virt-manager со списком ВМ на 2 хостах:

Десктопное приложение virt-manager — не единственный способ создания ВМ. Можно (и иногда удобнее) использовать командную строку и соответствующие утилиты. Также установить ВМ из готового образа в формате для libvirt/qemu. Например, для релиза 14.2 FreeBSD всё, что заканчивается на .qcow2.xz, raw.xz — это образы для libvirt/qemu. После скачивания и проверки контрольных сумм выполним команды:

Предположим, вы успешно создали одну или несколько ВМ, проверили их в графическом режиме или настроили ключи для ssh. Настало время навести порядок с DNS.

У меня раздавал адреса и имена роутер от провайдера. Удобнее настроить на вашем основном компе сервис dnsmasq, который включается первым и по умолчанию всегда доступен. Он умеет также dhcp, так что в одном конфиге сможем сразу задавать и IP-адреса, и имена ВМ. Вот часть моего конфига:

MAC-адреса присваиваются в virt-manager, адреса до 99 оставил под WiFi; со 100 до 200 виртуалки с отдельными диапазонами для каждого хоста; адреса с 201 по 254 — «железные» хосты, то есть реальные устройства. Напомню, после каждой правки конфига сервис dnsmasq надо рестартовать.

Если в будущем ваше персональное облако разрастётся, рекомендую обратить внимание на китайский KVM-свитч 4K HDMI USB KVM Switch. В этом случае KVM означает Keyboard Video Mouse — переключатель для управления несколькими компьютерами с одного комплекта устройств. Это сокращение как нельзя кстати для нашей темы.

Мы разобрали, как развернуть персональное облако DevOps с помощью KVM и libvirt. В следующей статье рассмотрим Fedora Core дистрибутив и инструмент mise — удобную альтернативу pyenv и другим менеджерам версий.

Математики Джон Кемени и Томас Курц успешно запустили первую программу, написанную на новом языке программирования BASIC (Beginner's All-Purpose Symbolic Instruction Code), на мейнфрейме General Electric GE-225.

Простота и доступность

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

Простота синтаксиса BASIC, основанная на ключевых словах на английском языке, делала его легким для освоения новичками.

BASIC и персональные компьютеры

В 1975 году Пол Аллен и Билл Гейтс адаптировали BASIC для персональных компьютеров, таких как Altair 8800, что позволило основать Microsoft.

В 1976 году Стив Возняк разработал интерпретатор BASIC для Apple I, а затем и Applesoft BASIC для Apple II, который оставался ключевой частью этой платформы на протяжении всего ее существования.

В конце 1970-х и начале 1980-х BASIC стал важным элементом многих домашних компьютеров, таких как Atari 800 и Commodore 64.

BASIC сегодня

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

Однако он продолжил развиваться. Существует множество диалектов BASIC, наиболее известные из которых — это продукты Microsoft, такие как Visual Basic и Visual Basic for Applications (VBA).

Эти языки стали популярными для разработки Windows-приложений и скриптинга в Microsoft Office. Современные языки, такие как Python и JavaScript, заняли место BASIC, став популярными благодаря своей простоте и доступности.

Мы уже проводили батл в прошлых 2020, 2021 и 2022 годах: первые два раза в голосовании победил Python, а в прошлом году — C#.

Вот, кто поборется за звание лучшего языка в 2023 году:

Правила батла остаются прежними:

1. В батле участвует 16 языков программирования.
2. Ежедневно соревнуются две пары.
3. За любимый язык можно проголосовать в течение 24 часов.
4. Пары составляются рандомно, так что выбирайте язык, который субъективно нравится больше.
5. В финале мы определим тройку победителей.
6. Старт — 19 декабря, финал — 26 декабря.

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

1. Первый раунд
2. Второй раунд
3. Третий раунд
4. Четвёртый раунд
5. Пятый раунд
6. Шестой раунд
7. Полуфинал
8. Финал
9. Результаты

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

Старт уже завтра — 19 декабря в 11:00 МСК. Следите, участвуйте, голосуйте!

• Visual Basic против Pascal;
• C++ против C#.

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

Подробнее об условиях баттла читайте в анонсе.

Голосование продлится до завтра, 14 декабря 2022 года, до 11 часов по московскому времени.

Боитесь пропустить следующие раунды баттла? Подпишитесь на тэг Лучший язык 2022 и следите за новыми раундами в личной ленте.

Правила батла по-прежнему просты:

1. В батле участвует 16 языков программирования.
2. Ежедневно соревнуются две пары.
3. За любимый язык можно проголосовать в течение 24 часов.
4. Пары составляются рандомно, так что выбирайте язык, который субъективно нравится больше.
5. В финале мы определим тройку победителей.
6. Старт — 13 декабря, финал — 20 декабря.

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

• Этап 1
• Этап 2
• Этап 3
• Этап 4
• Этап 5
• Этап 6
• Полуфинал
• Финал
• Результаты

Турнирная таблица:

Старт уже завтра — 13 декабря в 11:00 МСК. Следите, участвуйте, голосуйте!

Мы же не останавливаемся и объявляем новых кандидатов на звание лучшего языка программирования 2021:

• Visual Basic vs. Java
• Swift vs. Go

Выбирайте язык, исходя из личных предпочтений. Текущее голосование будет завершено 17 декабря 2021 года в 11:00 по Москве.

Но давайте отвлечёмся от официальной статистики и узнаем, какие языки предпочитаете именно вы! Завтра стартует баттл языков программирования 2021. Правила просты:

1. Всего участвует 16 языков программирования.
2. Каждый день соревнуются две пары.
3. На возможность проголосовать за любимый язык отводится 24 часа.
4. Пары составляются рандомно.
5. Выбирайте тот язык, который субъективно нравится вам больше.
6. В финале мы определим победителей — языки которые заняли первое, второе и третье место.
7. Старт — 14 декабря, финал — 21 декабря.

Так выглядит изначальная турнирная таблица:

А вот как мы выбирали лучший язык программирования в прошлом году.

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

Результаты баттла можно посмотреть по ссылке.

Visual Basic считается языком программирования для новичков, а также популярным инструментом для быстрого прототипирования. Именно поэтому о нем сложилось довольно предвзятое впечатление среди профессиональных разработчиков, уверены эксперты. Несмотря на все это, в феврале VB набрал обороты.

TIOBE делает акцент на возвращении SQL в индекс, начиная с февраля 2018. Делается это из-за того, что популярный язык запросов является тьюринг-полным, то есть на нем можно реализовать любую вычислимую функцию. При этом его позиция в рейтинге на данный момент не совсем объективна, так как SQL появился в нем впервые за долгое время.

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

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

Для тех, кто хочет потратить ещё больше своего свободного времени на ностальгию, вот ссылки на подходящие веб-эмуляторы:

• PC DOS во всевозможных конфигурациях;
• Apple II с загружаемыми дисками.

Эта игра входила в комплект поставки ранных версий PC DOS, распространявшихся с оригинальными IBM PC в то время. Сейчас в неё можно поиграть даже на iOS (искать по словам Donkey bas). Побробнее про историю игры можно почитать на Wikipedia.