Обновить

Все потоки

Сначала показывать
Порог рейтинга
Биржа заказов Инфостарта: новые задачи по 1С со 23 по 30 сентября
Биржа заказов Инфостарта: новые задачи по 1С со 23 по 30 сентября

На Бирже заказов Инфостарта за неделю с 23 по 30 сентября появились задачи для разработчиков, консультантов и аналитиков 1С.

Заказчикам нужны специалисты по Бухгалтерии, УНФ, УТ, Документообороту, КА, УПП, ERP, мобильной платформе, ККМ, обменам, маркетплейсам и интеграциям.

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

Теги:
+6
Комментарии0

🔖 Наконец‑то дождались: git branch ‑delete‑merged

У нас у всех есть куча проектов. Мы работаем над фичами. Каждая фича — отдельная локальная ветка. Мы её делаем, пушим, открываем PR, PR мержат, ветку на сервере удаляют.

А локальная ветка остаётся. И так каждый раз. Через полгода у тебя в git branch тридцать восемь веток:

  feature/login
  feature/login-fix
  fix/typo
  topic/auth
  topic/auth-v2
  ...
  main

И ты такой сидишь и думаешь: «Какая из них ещё живая? Какие уже смержены? Можно ли что‑то удалить или я что‑то потеряю?».

И вот ты уже пишешь скрипт на коленке, который тебе должен всё почистить. Запускаешь его и вуаля, ты слегка ошибся и больше в твоей репе нет бранчей, паника и судорожный поиск решения на ohshitgit.com.

В общем, короче. Harald Nordgren походу сам задолбался с этим и ребята только что релизнули Git 2.56, в котором запилили опцию delete‑merged.

Самое классное, что команда супер простая и простая как полено (хоспадепрости patch‑format с 100 500 аргументами).

$ git branch --delete-merged 'origin/*' --dry-run
Would delete branch feature/login (was abc1234).
Would delete branch feature/login-fix (was def5678).
Would delete branch fix/typo (was 9876fed).

Посмотрел. Всё выглядит нормально. Запускаешь без --dry-run:

$ git branch --delete-merged 'origin/*'
Deleted branch feature/login (was abc1234).
Deleted branch feature/login-fix (was def5678).
Deleted branch fix/typo (was 9876fed).

Всё. Ветки, которые уже влиты в свой origin, снесены. Ветки, где есть неотправленная работа, — остались. Ветки с deleteMerged = false — остались. Ветки, которые ты вычеканил в другом worktree, — остались.

Это безопасно. Свои скрипты можно выкинуть. Также можно точечно чистить категориями topic-*, feature/*, origin/*.

В общем, если git branch уже не помещается в терминал — обновляемся на 2.56 и теперь вы знаете что делать.

Telegram | Github | YouTube | X

Теги:
+2
Комментарии2

API Security на практике: что проверить в API перед продом

API может быть закрыт авторизацией, работать по HTTPS и стоять за WAF — и при этом оставаться уязвимым. Например, пользователь успешно вошел в аккаунт и запрашивает /orders/125. Если сервер позволяет заменить 125 на 126 и получить чужой заказ, пароль взламывать вообще не нужно: проблема не в аутентификации, а в том, что API не проверяет права на конкретный объект. 

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

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

  • Входные данные и запросы сервера. Параметры, JSON, имена файлов и URL нельзя без проверки передавать дальше в SQL-запросы, команды или внутренние сервисы. Иначе появляются инъекции и SSRF — вплоть до запросов к ресурсам, которые вообще не должны быть доступны извне. 

  • Бизнес-логику. Иногда API технически работает правильно, но им легко злоупотребить: бот может перебрать промокоды, занять все слоты бронирования или отправить тысячи SMS-кодов, за каждый из которых платит компания. Обычного общего rate limit здесь бывает недостаточно — ограничения нужно задавать именно на чувствительные операции. 

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

  • Защиту на уровне инфраструктуры. WAF может отфильтровать часть веб-атак, API Gateway — централизовать правила доступа и лимиты, DDoS-защита — отсечь большой поток до сервера. Но эти инструменты не исправят ситуацию, если само API не проверяет, имеет ли пользователь право выполнить конкретное действие. 

В статье собрали основные риски из рейтинга OWASP API Security Top 10, разобрали аутентификацию и авторизацию, SSRF и инъекции, атаки на бизнес-логику, работу с секретами, WAF, API Gateway, rate limiting и мониторинг. В конце — чек-лист, по которому можно пройтись по своему API и понять, где искать основные пробелы в защите. Если хотите пройти проверку целиком, читайте материал в блоге Рег.облака.

Теги:
+3
Комментарии0

Лента за 29.09.2026 г.

В bodyscript.me (канал об издевательствах над собой) порассуждали о том, как ставить и контролировать эксперименты с весом.

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

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

Сейчас идём от простой отправной точки: предиктор выбран, споры с самим собой и окружающими о его бессмысленности прекратились, надо просто проверить, работает он или нет.

Например, выбрал предиктор — не пить после еды 2 часа. Срок эксперимента — минимум неделя, лучше две, чтобы избежать влияния случайных факторов (коих всегда много). Эти факторы создают статистический шум, мешающий оценке влияния предиктора. Если знакомы с каким‑то инженерным делом, то понимаете, что значит отделить сигнал от шума. Упомянутая выше вода в организме — один из самых частых источников шума.

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

Единственное изменение — предиктор. Не пить во время еды и после неё 2 часа.

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

Если отклонился от эксперимента, неважно по какой причине — начинай заново, со следующего дня.

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

Если за неделю результат очевидно есть — можно на этом и остановиться (в смысле эксперимент остановить). Если результата нет, или он невнятный (типа минус 200 г. за неделю) — лучше потерпеть ещё неделю.

Если и через 2 недели результата нет, и точно уверен, что всё делал правильно — предиктор для тебя не работает. Отлично, вычёркиваем. Избавились от одного неработающего метода. Ищем другой.

В Жёлтым по белому вышла первая серия курса «Бизнес‑скелет».

  1. https://vkvideo.ru/video-208482299_456239504

  2. https://youtu.be/ULVxj6TlS14

Теги:
+3
Комментарии0

Один мой друг, не я, проходил собеседования на Java Senior. Любопытна статистика результатов. 13 собеседований.

Общие вопросы разработки (теория, кодревью, иногда простой лив-кодинг) были на 12 собесах, в 11 случаях всех все устроило (правда, в одном случае поставили чуть ниже ожиданий, но не заблокировало). Это 11/13, но там где не провели интервью - там посмотрели предыдущие фидбеки (то есть по умолчанию ОКнули). Так что 12/13=92% ОК

Алгоритмическая секция была на 4 интервью, в 1 случае выше ожиданий, в 1 по норме, в 1 чуть ниже ожиданий (по мнению интервьюера) но формально отказ, в 1 прям так себе. Кто не проводил - очевидно для них не очень важна эта составляющая, так что считаем от них ОК и пишем 10/13=75% ОК

Системдизайн был по плану на 3 интервью, хотя внезапно вылез еще на 2 посреди другого этапа :) в 2 случаях ОК, в 3 посчитали что слабовато. По тому же принципу что если не спросили то не важно (но не учитываем те где кандидат не добрался до дизайна а он должен был быть) - (13+2 лишних)-3 отказа=9, а в знаменателе (13+2 - 3 непроведенных но где это важно)=75% OK

Финалки/знакомства были в 5 треках, тут можно смело считать что они предусмотрены везде, поэтому проценты считаем только по тем где провели. Из 6 кейсов 6 отказов (2 оверквалификация, 1 опасение что кандидату не понравится используемый стек, 1 несовместимость с командой по вайбу, в 1 случае на финалках спрашивались специфические важные для данной организации технические подробности - вроде того, как производится handshaking в протоколе TCP. 5 кейсов и 5 отказов = 0% OK.

Почему нахожу эти цифры интересными. По каждому из показателей (кроме финалки) кандидат устроил 75-90% работодателей. И однако по совокупности он устроил 0%. Нетрудно посчитать, что вероятность пройти по 3 этапам-критериям исходя из этой статистики - 92%*75%*75%=50%, кажется что система должна работать и давать разумный шанс. На самом деле примерно столько и вышло, но это без учета финалок, на которых тоже теперь проявляют придирчивость. Разумно ли, что на выходе получился 0?

Впрочем по-хорошему оба кейса оверквалификации и один кейс с хардами в финалках следовало исключить уже на этапе первичного скрининга, чтобы не тратить ничье время. Если вакансия на самом деле не сеньорного уровня или требует специфического hands-on experience, кандидат должен был об этом узнать и вовсе не подаваться. Тогда остается только 2 отказа на финале, оба вполне валидных. Но... тогда надо из общей статистики эти вакансии убрать целиком, и получится что из 10 оставшихся проведено только 2 финалки, 20% уже выглядит как слишком низкая востребованность если большинство интервьюеров довольны каждым критерием в отдельности, нет?

Ну и выглядит забавно (хотя это уже искажение перспективы)

  • если ты можешь пройти все этапы трека, мы подкинем тебе еще обручей (+1 сисдизайн например)

  • если ты и тут не слился, то ты для нас слишком хорош

Теги:
+10
Комментарии1

А мы продолжаем серию вебинаров про защиту Identity.

Завтра стартует наш следующий вебинар, при информационной поддержке партнера «Шексна‑Автоматизация»

2FA: on‑prem или облако — что выбрать?

На вебинаре разберем плюсы и минусы обоих вариантов.

2FA — уже не дополнительная защита, а базовый уровень безопасности

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

На вебинаре разберём, как внедрять двухфакторную аутентификацию в существующей инфраструктуре постепенно и без лишней нагрузки на сотрудников и ИТ.

Покажем, как это решается с помощью двух сценариев: on‑prem решения Avanpost MFA+ и SaaS Avanpost Identity Cloud.

Avanpost MFA+ полностью разворачивается в инфраструктуре компании и поддерживает интеграцию с корпоративными системами через RADIUS, SAML, OpenID Connect, LDAP, Credential Provider и другие механизмы.

Avanpost Identity Cloud — защищенный доступ к корпоративным ресурсам для сотрудников и подрядчиков, созданный на базе эталонной облачной архитектуры. Все секреты и чувствительные данные остаются в периметре заказчика.

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

Продемонстрируем на тестовом стенде:

✅ Привязку аутентификатора в момент входа на рабочую станцию (on‑prem решение)

✅ Внедрение второго фактора для VPN (облачное решение)

Сделайте 2FA частью базовой кибергигиены без остановки рабочих процессов.

Когда: 1 октября в 11.00

Спикеры:

  • Светлана Лихоманова, Директор по развитию стандартизированных продуктов

  • Михаил Юров, Пресейл‑инженер, Отдел технической экспертизы

Зарегистрироваться на вебинар

Теги:
+3
Комментарии0

Сколько вакансий на каждом грейде и сколько за них платят?

Сколько вакансий на каждом грейде и сколько за них платят?
Сколько вакансий на каждом грейде и сколько за них платят?

Новая аналитика по уже более 180.000 IT вакансий с HH, карьерных сайтов, сайтов организаций, job-бордов и телеграмм каналов.

Я построил 12 графиков отвечающих на разные вопросы связанные с IT наймом в 2026 году.

На Хабре буду выкладывать новые графики каждую неделю по средам!

Теги:
+2
Комментарии0

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

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

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

📆 Когда: 5 октября в 17:00 (Мск)
👨‍🎓 ️Спикер: Гафитулин Тимур, эксперт по техникам мышления

✍️ Записаться

Теги:
+3
Комментарии0

Открытый проект Unofficial search plugins позволяет искать торренты прямо в qBittorrent. Это каталог поисковых плагинов, которые подключают торрент-сайты к самому клиенту. Можно выбрать нужные источники и искать по нескольким местам сразу с помощью одного запроса. В списке проекта есть Rutor, Nyaa, The Pirate Bay и даже Academic Torrents с научными данными.

Теги:
+4
Комментарии0

Пришло письмо с конференции. На неё я не регистрировалась. 3 дня назад пришло письмо, где мне предложили зарегистрироваться, но его я просто проигнорировала, так как не моя тематика, да и планы уже есть. Честно говоря, за 4 дня до конфы звучит как крик о помощи. А теперь так вообще - добро пожаловать на онлайн, куда я даже не регистрировалась.

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

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

  • Оставить отзыв

  • Отписаться

  • Переход на сайт конференции

А что будет если нажать на радостный? Сайт конференции! А если на покерфейс? Сайт конференции!

Почему при нажатии на грустный смайлик на вопрос "Как вам письмо?" я перехожу на сайт конференции?!

Как выглядят эти люди, которые не довольны рассылкой о конференции, но хотят на неё попасть? 😳

Чисто технически, конечно, вопрос был о письме. Письмо плохое, на конференцию хочу 🫠

Теги:
+13
Комментарии11

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

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

Это в 4 раза быстрее, чем секвенирование ДНК, в 6 раз быстрее, чем вычислительные мощности, в 18 раз быстрее, чем литиевые аккумуляторы, и в 54 раза быстрее, чем дешевела электроэнергия (если брать период до 1973 года).

Хорошего дня! заходите на тг канал https://t.me/TradPhronesis

Теги:
-2
Комментарии2

OpenAI: пузырь или новая инфраструктура?

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

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

С ИИ может быть похожая ситуация: большинство стартапов не выживет, но несколько игроков могут стать системообразующими.

Более важный риск — концентрация вычислитель

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

Альтернативный путь — децентрализованный open source AI: открытые протоколы и распределённые вычисления, которые направлены на полезную работу моделей.

Вопрос будущего не только в том, будет ли коррекция оценок. Вопрос в том, станет ли ИИ инфраструктурой для всех или ресурсом нескольких центров силы.

Подробнее — в Telegram-канале «Идеи для ИИ — Андрей Анисимов». Ссылка в профиле.

Теги:
+2
Комментарии0

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

Теги:
+6
Комментарии2

Ближайшие события

Плановое обслуживание кода

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

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

Эффективность агента

/doctor (Claude Code) — раз в месяц проверяю здоровье агентского окружения: конфигурацию, неиспользуемые скилы и MCP, медленные хуки, проблемы с permissions и другие накопившиеся проблемы. Заодно помогает освобождать память от устаревшего и лишнего.

/fewer-permission-prompts (Claude Code) — анализирует историю работы и предлагает, какие часто используемые безопасные команды стоит добавить в allowlist, чтобы агент меньше отвлекал подтверждениями.

/run-skill-generator (Claude Code) — периодически пересобирает знания агента о том, как поднять и проверить проект, чтобы /run и /verify не опирались на давно устаревшие команды.

/retro (Matt Pocock Skills) — формально не плановая задача. Запускаю после сессии, где агент заметно буксовал, делал лишние шаги или его приходилось несколько раз исправлять. Скил анализирует, что можно поменять в инструкциях, автоматических проверках и окружении, чтобы эта проблема больше не повторялась.

Качество кода

/simplify (Claude Code) — прохожусь по активно меняющимся частям проекта. Ищет дублирование, лишние абстракции, возможность переиспользовать уже существующий код и просто слишком сложные решения. Удобно запускать раз в неделю по нескольким наиболее активно меняющимся каталогам.

/code-review (Claude Code; у Matt Pocock также есть одноимённый skill) — отдельный проход по изменениям за неделю на корректность, качество кода и возможные упрощения. Обычный review конкретного изменения такую накопительную деградацию часто не замечает.

/improve-codebase-architecture (Matt Pocock Skills) — ищет места, где архитектура постепенно поплыла: слишком мелкие модули, неудачные границы, сложные интерфейсы, размазанное по нескольким местам поведение. Можно натравливать прямо на конкретные слои, типа посмотри сервисы

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

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

p.s. Поделитесь своими фишками, что запускаете вы?

Теги:
+3
Комментарии0

Зачем системному программисту знать больше, чем С

C придумали в 1972 году, а системные программисты по-прежнему пишут на нём — несмотря на смену архитектур и языков за прошедшие полвека. Почему так вышло и почему одного знания синтаксиса недостаточно, если не понимаешь, как код компилируется, выполняется процессором и взаимодействует с аппаратурой?

Об этом рассказывают — Денис Довженко, ведущий инженер по разработке ПО для СХД, и Сергей Жмылёв, руководитель отдела низкоуровневого программирования — в лекции журнала «Истовый инженер». На примерах встраиваемых и высокопроизводительных систем они показывают:

  • как устроено системное программирование,

  • какие возможности и ограничения C определяют его применение,

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

➡ Запись лекции смотрите на «Истовом инженере».

Что почитать, чтобы зайти в тему подготовленным:

  • Никита Косырев объяснил, чем системное программирование отличается от прикладного, и подробно рассмотрел, как они работают вместе.

  • Дмитрий Петров в подкасте «Битовые маски» рассказал, как устроена разработка компиляторов и что в ней изменилось за 20 лет.

  • Дмитрий Точанский, Елена Лепилкина и Антон Афанасьев разобрали архитектуру ядра и драйверов Linux и системное программирование для разных процессорных архитектур.

Теги:
+9
Комментарии0

Реально ли в 2026 году вкатиться в айти через QA?

На что вообще смотрят рекрутёры, когда нанимают тестировщиков в 2026 году? Как собрать заметное резюме, когда вокруг одни ИИ-фильтры?

Серёжа Атрощенков и Оля Шнайдер во втором выпуске подкаста «Не воспроизводится» пригласили тест-лида Авито Путешествий Ивана Алексеева

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

🎧 Слушайте выпуск подкаста на всех подкаст-платформах:

Расскажите в комментариях, с чем сталкивались при поиске работы в QA и какие лайфхаки сработали у вас?

Теги:
+3
Комментарии0

В продолжение предыдущего поста.

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

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

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

Хочу турнирный режим: регистрация, проведение, итоги, с поддержкой таких-то турнирных режимов. Что тебе ещё надо знать – задавай вопросы?

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

Во второй – превращал бизнес-требования в ТЗ. Опять же, моё участие свелось к ответам на вопросы, и то, в основном для краевых случаев: основные сценарии были уже описаны.

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

Понесу теперь по клубам уже с новой функциональностью) А чтобы не разъяснять каждый раз, что там и как, собрал ещё и страничку с инструкцией и скринами: https://fencing-scorer.konbo.me/help.html

Теги:
+2
Комментарии0

Статический анализатор — это полезный инструмент, и Go разработчики знают это не понаслышке благодаря go vet. Но что, если его возможностей не хватает? Искать новый инструмент? Или сделать… свой?!

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

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

Посмотреть запись можно тут:
- VK Video
- Rutube
- YouTube
- Наш сайт

Приятного просмотра! Ждем ваши комментарии 😉

Теги:
+3
Комментарии0

VK WorkSpace обновил тарифы: ИИ-ассистент, звонки до 500 участников и оплата помесячно

С 28 сентября в облачной версии VK WorkSpace действуют обновленные тарифы. В сервисах появились новые возможности для видеоконференций, совместной работы и администрирования. В тариф «Расширенный» вошел ИИ-ассистент, а подписку теперь можно оплачивать на любой срок от одного месяца. Разбираем, что изменилось в каждом тарифе и как перейти на новые условия.

Что изменилось

Обновились тарифы «Базовый» и «Расширенный». Для команд, которым нужна только Доска, появился отдельный тариф «Доска+». Изменился и порядок оплаты: плата списывается с баланса ежемесячно, а если пополнить его на несколько месяцев вперед, действуют скидки.

«Мы развиваем VK WorkSpace так, чтобы сотрудники могли быстрее находить нужную информацию и работать эффективнее. ИИ-ассистент поможет сократить время на поиск договоренностей и подведение итогов встреч, а новые инструменты администрирования дадут компаниям больше контроля над данными и доступами. Вместе с возможностями сервисов мы меняем и условия оплаты: вводим ежемесячную тарификацию и скидки за пополнение баланса на несколько месяцев вперед. Это поможет компаниям планировать расходы на корпоративные сервисы под свой бюджет», — рассказал руководитель направления сервисов продуктивности VK Tech Пётр Щеглов.

После 28 сентября 2026 года продление будет доступно только по новым тарифам. Ниже подробно о каждом тарифе.

«Базовый»: видеоконференции до 300 участников и обновленная Доска

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

Теперь в тарифе:

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

  • Новые функции Мессенджера: расшифровка голосовых сообщений и автогруппировка чатов по папкам.

  • Интеграция с мессенджером MAX: сотрудники смогут быть на связи с клиентами и партнерами без переключения между приложениями.

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

  • Рассылки в панели администратора: удобный инструмент для быстрой отправки массовых писем без сторонних сервисов и сложной интеграции.

ИИ-ассистента к «Базовому» можно подключить как дополнительную опцию.

Стоимость: 309 ₽ за пользователя в месяц.

«Расширенный»: ИИ-ассистент и больше контроля для администратора

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

Теперь в тарифе:

  • Максимум в Видеоконференциях: до 500 участников, автоматическая расшифровка звонков.

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

  • Больше контроля для администратора: передача прав владельца чатов и каналов в Мессенджере, смена владельцев хранилищ в Диске, имперсонация в Календаре и корзина пользователей.

  • Больше защиты: брендирование приложения, парольные политики, политика отключения IMAP и ограничение «Ответить всем» на рассылки в Почте.

Стоимость: 499 ₽ за пользователя в месяц.

Как теперь устроена оплата

Плата за сервисы списывается с баланса раз в месяц, подписку можно оформить на любой срок от одного месяца. При пополнении баланса на 3, 6 или 12 месяцев вперед действуют скидки. Подробные условия:

Тарифы «Базовый» и «Расширенный» с помесячной оплатой →

С годовой оплатой:

Задайте вопрос экспертам или запросите демо

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

Теги:
0
Комментарии0

22 октября в Москве соберутся инженеры, архитекторы и DevOps-специалисты, которые работают с Kubernetes и Cloud-Native-инфраструктурой.

В программе — экономика платформ, эксплуатация Kubernetes, наблюдаемость, Service Mesh, безопасность в эпоху LLM, железо и bare metal. Между докладами будет время на нетворкинг, а завершится конференция афтепати. 

🗓 22 октября, 11:00–19:00 
📍 Москва, Connect

👉 Подробности о докладах и расписании конференции уже на сайте. Изучайте и регистрируйтесь

📬 Мы в MAX

Теги:
+4
Комментарии0