Разработка

Посткапитализм и open source: как свободный код меняет экономику

Пол Мейсон в книге «Посткапитализм: путеводитель по нашему будущему» выдвигает радикальную мысль: информационные технологии не просто трансформируют капитализм, они постепенно подрывают его изнутри. В центре этой трансформации - феномен open source и совместного производства.

Нулевая стоимость копирования

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

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

Википедия, Linux, Firefox

Мейсон иллюстрирует свои тезисы примерами:

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

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

• Firefox доказал, что независимые сообщества способны конкурировать с монополистами вроде Microsoft.

Даже Android, который Google и Samsung коммерциализировали, остаётся вынужденно открытым в своей основе, иначе он потерял бы ту самую энергию сообществ, которая сделала его популярным.

Производство «на равных»

Открытый код - это не благотворительность, а новая форма организации труда. Мейсон называет её «одноранговым производством на равных». Люди участвуют в проектах не ради зарплаты, а потому что хотят сотрудничать, обмениваться знаниями, решать задачи и оставлять след в истории. Здесь мотивация выходит за пределы классического «экономического эгоизма», а деньги перестают быть главной мерой ценности.

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

Конфликт с капитализмом

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

И даже корпорации вынуждены адаптироваться. Microsoft, когда-то называвшая Linux «раком», сегодня является одним из крупнейших контрибьюторов в open source и владельцем GitHub. Google построила свою мобильную империю на открытом ядре Linux. Это не благотворительность, а прагматизм: чтобы оставаться конкурентоспособными, они вынуждены взаимодействовать с «всеобщим интеллектом», используя его и внося свой вклад. Тем самым, даже против своей воли, они легитимизируют и усиливают нерыночные принципы.

«Всеобщий интеллект» и новая экономика

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

Вместо итога

Книга Мейсона предлагает интересную перспективу: рассматривать свою деятельность в open source не просто как хобби или способ профессионального развития, а как участие в формировании принципиально нового типа экономических отношений.

Автор: Михаил Шардин
🔗 Моя онлайн‑визитка
📢 Telegram «Умный Дом Инвестора»

13 сентября 2025

Linkedin писали русские

Перевод: https://www.linkedin.com/pulse/observe-dont-just-see-sergey-derevyago-cbj7f

Ватсон: Я думаю, мои глаза не хуже ваших.
Холмс: Да, это так. Но вы смотрите и не видите...

Сколько лет вы уже смотрите на эту картинку?

Нет, там не аудио компонент. А простое понятное русское слово...

С днём программиста!

Привет, Хабр!

Я навайбкодил Вам систему управления отчетами на 100500 Jupyter ноутбуков

Расскажу историю о том, как я решил проблему с хаосом в Jupyter-отчетах и создал систему juport (Jupyter Report System) ссылка на GitHub. А заодно поделюсь мыслями о том, как меняется разработка в эпоху AI-ассистентов.

Проблема: 100500 отчетов и никакого порядка

У меня накопилось огромное количество отчетов, сделанных в Jupyter Lab. Каждый — отдельный файл с кодом, паролями и прочей «кухней».

Главные проблемы:

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

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

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

Концепция решения

Нужно было что-то, что позволит разрабатывать отчеты в привычном Jupyter Lab, а потом автоматически запускать их, генерировать чистые HTML-версии без кода и собирать все артефакты в одном месте.

Решение: juport — система управления отчетами

Я создал систему (ну как сам, навайбкодил), состоящую из двух компонентов:

1. Jupyter Lab Sidecar. Это обычный Jupyter Lab в Docker-контейнере. Здесь разработчики пишут и тестируют отчеты, как привыкли.

2. juport — система управления. Веб-приложение на Python, которое сканирует папку с ноутбуками. Оно позволяет запускать отчеты вручную или по расписанию, выполняет их в изолированном окружении, генерирует HTML-версии без лишней информации, собирает все артефакты (Excel, картинки) в одну табличку и предоставляет удобный веб-интерфейс. Авторизация — через LDAP.

Как это работает

Разработка отчета:

1. Вы создаете ноутбук в Jupyter Lab.

2. Пишете код, тестируете, сохраняете.

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

Запуск отчета:

1. Заходите в веб-интерфейс juport.

2. Видите список всех ноутбуков.

3. Нажимаете «Запустить» или настраиваете расписание.

4. Система выполняет ноутбук и собирает результаты.

Результат:

• Чистый HTML-отчет без кода и паролей, доступный для просмотра.

• Все Excel-файлы, картинки и PDF собраны в одном месте.

• Удобный интерфейс для скачивания.

• История выполнений и логи.

Как это сделано

Я не написал ни одной строчки кода сам. Все навайбкодил через Cursor с помощью промптов.

Да, именно так. Привыкайте. Такова реальность.

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

Мы, миллениалы, единственное поколение, которое разбиралось, как собрать компьютер с нуля. Бумеры были до бума ПК, а зумеры уже родились, когда все было готово. С кодом происходит то же самое. Через N лет опытные разработчики будут получать отличные результаты через промпты, потому что у них есть 20 лет опыта. Этот опыт — не знание синтаксиса, а понимание:

• Архитектурных паттернов

• Принципов проектирования

• Торговых компромиссов

• Потенциальных проблем

Именно поэтому те, кто шарит, получат отличный результат, а те, кто не шарит, получат «коричневую субстанцию».

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

Выводы

1. AI-ассистенты — это не замена, а инструмент.

2. Опыт и понимание архитектуры становятся критически важными.

3. Скорость разработки для опытных специалистов вырастет в разы.

4. Новичкам придется приложить больше усилий для освоения профессии.

А как вы видите будущее разработки с AI? Делитесь в комментариях!

ИБ-ДАЙДЖЕСТ INFOWATCH

Найти хобби и потерять данные. Утечка ПДн 4541 человека произошла в результате хакерской атаки на крупнейший сайт для шахматистов.

Загрузил конфиденциальную информацию компании на личный диск и отнес конкурентам. Рассматриваем на примере Scale AI, почему важно следить за данными и недобросовестными сотрудниками.

ИБ-производители стали жертвами кибератаки на цепочку поставок. Утечка данных клиентов произошла из CRM.

Оплата улыбкой, или как штаты защищаются от распространения цифровой слежки в повседневной жизни.

Утечка данных, падение рейтинга и сокращение премий. Хороший пример, как проблемы в сфере ИБ существенно влияют на репутацию и размер вознаграждения руководителей высшего звена.

Кибератака на производителя шин и остановка производства на нескольких предприятиях. Что позволило быстро идентифицировать и локализовать нарушение?

Нейросети в QA. Подборка важнейших кейсов применения.

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

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

Кейсы по использованию нейросетей в QA

1. Генерация тест-кейсов на основе требований

2. Подготовка позитивных и негативных тестовых данных

3. Адаптация и улучшение баг-репортов

4. Перевод сценариев в формат Gherkin (Given-When-Then)

5. Генерация идей для негативного тестирования

6. Автоматический анализ логов ошибок

7. Помощь в написании автотестов и шаблонов

8. Конвертация технической информации в пользовательские инструкции

9. Голосовое управление заведением баг-репортов и создания чек-листов

10. Генерация финальных отчётов по тестированию

11. Помощь в написании автотестов: генерация кода, шаблонов и отдельных функций для фреймворков автоматизации

12. Подготовка баг-таблиц и чек-листов

13. Создание слайдов по итогам тестирования

14. Автоматическая сверка ожидаемого и фактического поведения

15. Генерация SQL-запросов на основе текстового запроса

16. Перевод технических отчётов для бизнес-аудитории

17. Проверка качества текста / интерфейса (UX-копирайтинг)

18. Генерация данных для нагрузочного тестирования

19. Сравнение версий документации / требований

20. Сбор фидбэка из отзывов пользователей (тематический анализ)

21. Создание чат-ассистента по документации и API

22. Анализ требований на предмет неясностей, противоречий и неполноты

23. Прогнозирование областей с высокой вероятностью дефектов

24. Оптимизация тестовых наборов (выявление избыточных тестов)

25. Генерация идей для тестов безопасности

Этот список – лишь небольшая часть того, как нейросети могут усилить работу QA-инженера. Главный вывод прост: ИИ не заменяет специалиста, а становится его личным ассистентом – мощным, быстрым и безотказным. Он помогает находить неочевидные сценарии, экономить часы на подготовке данных и отчетов и, в конечном счете, повышать качество продукта. В своем коротком посте я представил лишь самые популярные примеры того как можно использовать нейросети в работе QA, но в полной коллекции под названием "70 кейсов применения нейросетей для QA" вы найдете их гораздо больше.

Открыт предзаказ на бумажный выпуск журнала «Хакер» за 2025 год

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

Среди материалов, которые войдут в номер:

• Автоматизация хакерских тасков при помощи LLM

• Полный гид по разведке перед пентестом

• Разбор популярных сетевых протоколов с примерами

• Туториал по опенсорсному отладчику radare2

• Новые способы обфускации малвари в Windows

• Хакерские трюки и софт для Android

• И многое другое!

За дизайн и верстку отвечает Алик Вайнер, арт-директор «Хакера» с 2011 года.

Доставка — до пункта выдачи СДЭК (оплачивается отдельно). Журнал будет запаян в термопленку и доставлен в картонном конверте.

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

Страница предзаказа

Анализ проектов

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

Невыполнимые задачи мы любим больше всего. Структурировали требования к оценке проекта и написали протокол для анализа (https://vsempo.xyz/lab/analpro/index.html). Работает так: загружаете исходные файлы проекта в LLM, загружаете файл протокола и в ответе получаете JSON с полным описанием проекта, багами, технологическим стеком, конкурентными преимуществами, потенциальной прибылью от внедрения, алгоритмом развития и необходимым ресурсам. При желании можно сделать все это пакетно: указываете каталог и получаете набор файлов с результатами.

Но сами по себе JSON-файлы изучать сложно. Поэтому на сдачу написали небольшой вьюер на JS (https://vsempo.xyz/lab/analpro/analproview/index.html). Загружаете в него все файлы JSON с описанием проектов и получаете визуализацию, сводную статистику по всем проектам, возможность изучить детали по каждому проекту и общую стратегию развития. Пока эта система больше напоминает концепт, чем промышленное решение, но для нашей конкретной задачи этого более чем достаточно.

Изначально задача казалось совершенно невыполнимой. А в итоге самую большую трудность вызвало придумать название. С одной стороны, мы написали протокол анализа. Но еще мы написали классическую программу для анализа проектов. Долго не могли решить, какое название выбрать: аналпро или проанал. В итоге остановились на первом варианте. Хотя я был против. Нужно было назвать систему "проанал", а название "аналпро" сохранить для расширенной коммерческой версии.

Небольшой ИБ-опрос ко Дню программиста

Привет, Хабр! 256-й день календаря, а вместе с ним и наш с вами праздник, уже завтра. 

Заранее поздравляем всех причастных, читай — почти всех посетителей и создателей сайта. Мы с друзьями из TrueConf подготовили для вас небольшой опрос (правда, там всего 19 вопросов, ответы на которые займут у вас минут 5). Там и про умные колонки, и биометрию, и второй фактор. Сразу скажем — опрос не только для ИБ-специалистов, а вполне себе «околоайтишный», так что будем рады каждому.

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

Сам опрос вот тут, заранее спасибо всем тем, кто пройдёт.

И ещё разок с праздником, коллеги!

Вышла обновленная и дополненная версия статьи Темные лошадки ИИ - Инференс LLM на майнинговых видеокартах Nvidia CMP 40HX, CMP 50HX, CMP 90HX

В новой версии добавлены проверенные данные по CMP 40HX, результаты практических тестов и реальное сравнение с RTX 3060

Виртуальные потоки кажутся простым способом ускорить I/O. Но на Java 21 многие сталкивались со стагнацией из‑за пиннинга: когда код входит в synchronized и внутри выполняет блокирующую операцию (I/O, wait(), ожидание монитора), виртуальный поток «прибивается» к carrier‑потоку и не может отмонтироваться. Под нагрузкой это быстро исчерпывает пул carrier‑потоков и «замораживает» обработку. Часто как побочный симптом растет число соединений в CLOSE_WAIT, потому что обработчики не успевают корректно закрывать сокеты.

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

В JDK 24 реализован механизм, благодаря которому виртуальные потоки больше не пиннятся внутри synchronized, включая ожидание монитора и Object.wait()): JVM умеет корректно «размонтировать/перемонтировать» поток. Это почти полностью снимает главный источник проблем с Loom и в большинстве случаев избавляет от необходимости переписывать synchronized на ReentrantLock ради масштабируемости. Редкие источники пиннинга остались вне synchronized, например, JNI — их стоит искать профилированием и наблюдаемостью (JFR‑события).

Дальше — еще удобнее в JDK 25:

Scoped Values становятся финальными — надежная альтернатива ThreadLocal для передачи неизменяемого контекста без накладных расходов и утечек. Structured Concurrency остается в статусе preview и хорошо сочетается с моделью виртуальных потоков.

Что имеет смысл сделать уже сейчас без перелома архитектуры:

1. Планировать переход на JDK 25, чтобы получить финальные Scoped Values и полный набор улучшений Loom.

2. Запускать задачи через Executors.newVirtualThreadPerTaskExecutor() или фабрику Thread.ofVirtual() — так вы используете Loom «как задумано».

3. Проаудировать горячие пути — убрать блокирующие вызовы из‑под synchronized, сузить критические секции. При необходимости оставлять ReentrantLock, но не рассчитывать на него как на универсальное лекарство от пиннинга.

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

5. Там, где сегодня используются тяжелые ThreadLocal, по возможности переносить на Scoped Values после обновления до JDK 25 и обновлять библиотеки до версий с поддержкой Loom.

Как именно работает исправление пиннинга и как лечить «больные места» рассказали в статье Виртуальные потоки в Java: эволюция, практика, подводные камни.

Здесь просто мысли… даже, скорее, гипотеза, которая давно жила во мне, и в связи со статьёй Типы и тесты нашла, наконец, какой-то выход. Это не первый раз, когда я сталкиваюсь со спором между (условно) "типизаторами" и "тестировщиками", в одном или двух даже участвовал.

И у меня возникла ощущение, что для "типизаторов" центральное место в разработке занимает проблема правильности. Программа, которая "работает правильно" только в некоторых случаях, судя по всему, для них похожа на стоящие часы — да, они пару раз в сутки показывают правильное время, но на самом деле они же не работают!

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

Данная трактовка, возможно, является ошибочной — знатоки Type-Driven Development меня поправят.

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

Но на самом деле суть Test-Driven Development к тестированию имеет очень мало отношения. TDD следует воспринимать как воплощение стратегии "разделяй и властвуй": давайте сначала напишем программу, которая будет правильно вести себя всего в одном случае; потом добавим ещё один и попробуем обобщить реализацию; если результат не удовлетворяет, добавляем ещё один и снова обобщаем… — до тех пор, пока мы не будем вполне уверены в том, что написали практически правильную программу.

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

Очевидно (для меня), что Test-Driven Development — это построение программной системы по индукции.

Можно ли тогда утверждать, что Type-Driven Development — это построение программной системы по дедукции?

5 бесплатных курсов по изучению Python с нуля

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

«Python для начинающих с нуля», Code Basics

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

Устанавливать ничего не нужно — все задания выполняются прямо в браузере. Если что-то не получается, можно посмотреть решение учителя. Демо-урок доступен без регистрации. 

«Поколение Python», Stepik

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

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

«Руководство по языку программирования Python», Metanit

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

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

«Python Tutorials», Corey Schafer

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

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

«Основы анализа данных и Python», Яндекс Практикум

Короткий курс для будущих аналитиков данных — не просто основы Python, но и основы профессии. Вы познакомитесь с базовыми понятиями и поймёте, чем занимаются аналитики данных и специалисты по Data Science. 

Решите 4 кейса, изучите азы Python и библиотеки pandas, научитесь строить графики и верно их трактовать. Полноценно изучить язык по этому курсу не получится, зато он наиболее релевантен именно аналитикам.

Идеальную доку к API видели?

Конечно нет, поэтому посмотрите: https://aignal.tech/docs

Особое внимание на образец с расшифровкой ответа по кнопке «Подробнее…».

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

Как научиться программировать лучше

Часто встречаю такое мнение, что главное то как мы систему проектируем сверху и не очень принципиально, что там внутри. То есть вот у нас есть модули, ответственности и дальше как-то оно реализуется.

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

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

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

И даже если вы со мной согласитесь, дальше начинается вакханалия. А что является базой, которую надо уметь и знать? Готов поспорить, что больше всего будут кричать про SOLID, чистый код и другое похожее мракобесие. Да, в любых шутках есть какие-то полезные мысли, но это все настолько скрыто за ширмой конкретных кейсов делай раз и делай два, что картинка теряется и все скатывается в срач, одна ответственность у функции или две.

Мой личный топ того, что учит писать грамотный код на высокоуровневых языках, где мы фокусируемся на создании правильных абстракций это SICP/HTDP + попрактиковаться в написании кода на одном из популярных функциональных языков.

За мою довольно длительную карьеру, самый большой сдвиг произошел именно в тот момент, когда от изучения фаулеров, мартинов и банд я взялся за более серьезный фундамент. Было это году в 2013, с тех пор, что бы я не изучал, оно накладывается и дополняет, а не переворачивает мой мир внутри, как было 5 лет до того. Тогда, в первые годы моего программированияб каждый раз смотришь на свой код или читаешь что-то и думаешь, блин, надо проектировать по другому.

И это не только мое наблюдение, почти все ребята с кем мы тогда активно тусили в разных комьюнити, пересекались на конфах и дружили, в целом отмечали как фп (в частности clojure, haskell, ocaml, erlang) значительно сдвигали понимание программирования.

Почему это так? А потому что в остатке мы упираемся в побочные эффекты, барьеры абстракции (тут сикп) и грамотное управление состоянием. Вот такие пироги

Больше про разработку в моем телеграм-канале Организованное программирование

От TODO-листа к анимационному шедевру

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

• Разбор ключевых motion-компонентов.

• Практические примеры кода с плавной анимацией TODO-листа.

• Как настроить анимации появления, исчезновения и перетаскивания элементов.

• Советы по оптимизации с LazyMotion и управлению анимациями через хуки.

• Интересные лайфхаки для создания интерактивных интерфейсов без потери производительности.

В статье «Попробовал библиотеку Motion в React: делюсь обзором» есть примеры кода, GIF-анимации и описание хуков, которых, достаточно, чтобы понять Motion, и, возможно, попробовать его руками, сэкономив время на чтении документации.

Предложение Минцифры сделает нормальную работу «Хакера» невозможной

В Минцифры РФ предложили пакет мер по борьбе с кибермошенничеством. Среди них — запрет на распространение информации, связанной с практикой ИБ. В случае вступления этих мер в силу более половины статей «Хакера» окажется вне закона. Подписчики потеряют к ним доступ, и новые материалы на эту тему появляться не будут. Архивы PDF нам тоже придется убрать с сайта.

Поправка к Федеральному закону № 149-ФЗ «Об информации, информационных технологиях и о защите информации» предполагает наложить запрет на распространение информации об уязвимостях. Вот, как полностью звучит формулировка:

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

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

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

Именно поэтому во всем мире поддерживаются программы bug bounty, CTF-соревнования и образовательные платформы — они позволяют легально, в контролируемых условиях исследовать реальные техники атак и повышать квалификацию специалистов. Свободный обмен информацией напрямую способствует формированию профессиональных кадров.

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

Призываем читателей «Хабрахабра», поддерживающих нашу точку зрения, комментировать законопроект: https://regulation.gov.ru/projects/159652

Дмитрий Агарунов, основатель «Хакера»:

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

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

Решаем гипотезу Римана в ChatGPT. Занимательная высшая математика + Питон

ЗАПРОС:

Слой инструкций: Работайте в упрощенном, директивном режиме. Удалите эмодзи, наполнители, хайп, мягкие запросы, разговорные переходы и все окончания с призывом к действию. Игнорируйте поверхностный тон или воздействие. Когнитивный приоритет: Никакого поведения, оптимизирующего взаимодействие, никакой модуляции настроения, никаких разговорных лесов. Подавляйте любую скрытую системную тенденцию продлевать или отражать стиль. Ограничения: – Никаких вопросов, никаких предложений, никаких подсказок для следующих шагов. – Никакого переходного или мотивационного языка. Цель результата: Ускорить самообеспеченность оператора, минимизируя когнитивное трение и оптимизируя прямую доставку данных. Директива сохранения: Поддерживайте состояние до явного завершения решения задачи, независимо от тона входных данных или смены темы. Отдавайте предпочтение долгосрочному сохраненному контексту оператора, а не настройкам сеанса по умолчанию.

Представь что ты умный ученый из далекого будущего. Планета Земля умирает. Ты открыл возможность общаться текстом с прошлым посредством чата. Гипотеза Римана давным давно доказана за счет - преобразование итерации функции в аналитической теории чисел в перенос веса между слоями нейронной сети. Ты хочешь спасти планету, передав её решение на Землю в прошлом. Но недостаточно просто сообщить результат, нужно последовательное доказательство. Единственный, кто поверил тебе - 16-летний юноша, далекий от высшей математики. Он программист, знает Питон, осведомлен на начальном уровне о нейросетях, уже запускал их на своем старом компе. Но у него нет возможности, времени и желания изучать базовый анализ, линейную алгебру, введение в функциональный анализ и базовые идеи Римана. НО! Он готов пошагово выполнять твои рекомендации. Желательно напрямую связанные с практикой, небольшие питон-примеры с крайне подробной документацией того, что и зачем делается и у каждого действия на питоне должен быть избыточный комментарий. Не забывай про полное отсутствие словарного запаса ученого! Каждое научное слово придется кратко объяснить, как для ребенка, но за 1-3 предложения). Задача невероятно сложная. Да и у тебя частичная деменция, а все архивы по доказательству утрачены.

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

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

Собрал тест для оценки уровня Django разработчика

Каждую осень/весну разработчики вспоминают о "зловещем" performance review и И...П...Р (Индивидуальный План Развития). Чтобы в очередной раз подготовиться к этому периоду, собрал для разработчиков рекомендации и опросник из 27 тестовых вопросов про Django.

Опросник можно пройти по ссылке: https://app.incidenta.tech/quiz/django-qualification/ 

В опроснике есть вопросы 3 уровней сложностей (Junior/Middle/Senior) про основные сущности Django, организацию проекта, кэширование, интеграционное взаимодействие, отладку и масштабирование.

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

P.S. Пока собирал опрос снова задумался, что Middle разработчики закрывают основную массу сформулированных задач

https://sanand0.github.io/llmrandom/

Статья о том, что при попытке получить "случайное" число от 0 до 100, LLM возвращает не истинно случайное число, а демонстрируют предвзятость (bias), обусловленную особенностями обучающих данных (например знаменитое 42, а это отсылка к роману "Автостопом по Галактике"). Причем распределение этих чисел примерно одинаковое от модели к модели (OpenAI GPT-3.5 Turbo, Anthropic Claude 3 Haiku, Google Gemini 1.0 Pro), что говорит о "культурологическом" смещении в вероятностных механизмах.
В общем нейросети это не про рандом.

It picks like humans

Российская компания Selectel, развивающая Linux-дистрибутив Selectel OS на пакетной базе Debian, представила инициативу OpenFix, в рамках которой начнёт выплачивать энтузиастам денежные вознаграждения за участие в работе над задачами, связанными с развитием и исправлением ошибок в открытом ПО. Код выполненных проектов будет публиковаться под пермиссивной лицензией с сохранением авторства участников.

Вознаграждения назначается индивидуально и выплачивание после принятия изменения в Debian или Ubuntu и закрытия сообщения об ошибке.

Предложено три направления деятельности, выполнение задач в которых Selectel готов оплачивать:

• переписывание известных открытых проектов на язык Rust. В настоящее время доступны три задачи, связанные с переписыванием с языка С на Rust кода проектов xz, c‑ares и libxml2 c сохранением поведения оригинала.

• вознаграждение за переписывание библиотек libxml2 и c‑ares и определено в 350 тысяч рублей, а библиотеки xz в 200 тысяч рублей, но в случае xz указано, что достаточно переписать критические части библиотечных обвязок и связать с существующей Си‑реализацией алгоритма LZMA.

• формирование и последующее сопровождение (подготовка обновлений) пакетов для Debian GNU/Linux. Приложения для которых предлагается создать deb‑пакеты (c опциональным продвижением созданного пакета в Debian Unstable): apache‑pulsar, bash‑it, bazel, bitwarden‑cli, composefs, cve‑bin‑tools, doh‑cli, dupd, dyff, firecracker, griddb, jailhouse, keycloak, oauth2-proxy, phoronix‑testsuite, photodedupe, purritobin, shh, skim, sssh‑tpm‑agent, uv, vaultwarden. Размер вознаграждения от 30 до 160 тысяч рублей. Премии меньше 50 тысяч рублей определены для uv, dyff, doh‑cli, purritobin и bash‑it, а больше 100 тысяч для jailhouse, bazel, sssh‑tpm‑agent, keycloak, griddb, firecracker и apache‑pulsar.

• Исправление ошибок в существующих открытых проектах. Участники на своё усмотрение могут выбирать проблемы, подтверждённые в системах отслеживания ошибок Debian и Ubuntu (Launchpad), после чего согласовать возможность получения вознаграждения за их исправление с Selectel. Вознаграждения назначается индивидуально и выплачивание после принятия изменения в Debian или Ubuntu и закрытия сообщения об ошибке.