Эксперты сравнили начинку самого первого iPhone с iPhone Air. За 18 лет эволюции микроэлектроники отрасль пришла к тому, что почти весь корпус смартфона занимает батарея, а железо помещается в блоке камеры.

Как исправить ошибку, связанную с отсутствием системного файла desktop в Windows 11 version 24h2
Текст сообщения об ошибке
Файл C:\WINDOWS\system32\config\systemprofile\Desktop недоступен. Если он находится на этом компьютере, убедитесь, что диск подключен или вставлен, и попробуйте еще раз. Если это сетевой файл, проверьте, подключены ли вы к сети или к Интернету, и повторите попытку. Если не удается найти файл, возможно, он был перемещен или удален.
Появляется, например, при попытке создать новое правило для исходящего соединения в мониторе брандмауэра защитника Windows. На форуме поддержки Microsoft быстро найти решение этой проблемы не получится.
Решение
Переходим по адресу C:\Windows\System32\config\systemprofile и создаем каталог "Desktop".
Открываем диспетчер задач, нажимаем "запустить новую задачу", прописываем там "msconfig" и кликаем по кнопке "обзор". Далее переходим C:\Windows\System32, запускаем "cmd.exe" с правами администратора и пишем команду "gpupdate".
Не забудьте перезагрузить вашу ОС.
Go + Windows = deadlock. Свет в конце тоннеля.
В прошлой статье я рассказывал о редком, но весьма опасном баге: поток под Windows зависал в вызове CancelIoEx, хотя документация Microsoft утверждает обратное. Суть проблемы — в пересечении синхронного и асинхронного ввода-вывода, где ядро Windows блокирует доставку APC, и поток остаётся навсегда «висящим».
История получила развитие не сама по себе: мы целенаправленно поднимали эту тему через support-кейс в Microsoft. В результате удалось подключить и Escalation Team, и разработчиков Go, ответственных за Windows-порт.
Финальный вывод: стандартная библиотека Go действительно использует неправильный API для отмены синхронных операций. Вместо CancelSynchronousIo, рекомендованного самой Microsoft, в коде до сих пор вызывается CancelIoEx.
👀 Сам проблемный вызов:
https://github.com/golang/go/blob/77f911e31c243a8302c086d64dbef340b0c999b8/src/internal/poll/fd_windows.go#L461
Хорошая новость: у команды уже есть рабочий proof-of-concept фикса:
https://go-review.googlesource.com/c/go/+/691395
Менее радостная часть: из-за сложности изменений и их влияния на рантайм правка запланирована только в Go 1.26 (февраль 2026). Бэкпорт в предыдущие версии практически исключён.
Что это значит для разработчиков
Если ваш сервис на Go под Windows внезапно «зависает» в CancelIoEx — это следствие бага в стандартной библиотеке, а не ваша ошибка.
До релиза Go 1.26 остаются обходные варианты:
не вызывать CancelIoEx для синхронных дескрипторов,
использовать CancelSynchronousIo, если есть возможность управлять потоками,
минимизировать использование пайпов в критичных местах.
Итог
Редкий flaky-тест Go (TestPipeIOCloseRace) оказался симптомом реальной и серьёзной проблемы. Благодаря эскалации через Microsoft Support и совместному разбору мы получили подтверждение, понятное объяснение и официальный фикс в планах.
⚡️ Если ваш Go-код на Windows зависает в CancelIoEx, теперь вы знаете: проблема признана и исправление уже в пути.

На Хабре только и разговоров что про ИИ. Он уже пишет код, пилотирует ракеты и, кажется, вот-вот отнимет у нас последнюю кружку с кофе на офисной кухне.
В топы залетают статьи про увольнения, будущее LLM-моделей, новости про OpenAI. Их активно обсуждают, ругаются, соглашаются. И всё меньше говорят о прошлом, о том, как всё начиналось.
А зря.
Скоро никто не ответит с ходу, почему счёт начинается с нуля, а не с единицы. Да уже сейчас многие испуганно полезут в ChatGPT.
А ведь за этим стоят фундаментальные решения, архитектурные баталии и гениальные озарения, которые определили всё, с чем мы работаем сегодня. Помнить о них — значит не наступать на пусть и симпатичные, но всё-таки грабли прошлых ошибок.
Мы в Профи.ру решили, что День программиста — идеальный повод устроить себе исторический reset --soft. Проверить, насколько мы, айтишники, помним и ценим своё прошлое.
Поэтому сделали тест, в котором погуляем по разным эпохам в ИТ.
Актуалочку тоже добавили — нагенерили красивых ИИ-картинок в Sora для каждой эпохи.
Если что, мы не хотим вас проверять и оценивать. Просто решили дать повод улыбнуться и отвлечься от рутинных задач.
А вы как думаете? Мы слишком забываем о прошлом? Или это естественный ход вещей? Делитесь мнением и своими результатами в комментах.
А ещё советуйте интересные вопросы, которые можно было бы добавить в этот тест :)
С Днём программиста
Сегодняшний День программиста - это повод вспомнить, что большая часть человечества до сих пор не понимает, чем мы занимаемся. С точки зрения стороннего наблюдателя: человек сидит, смотрит в монитор, иногда хмурится, бьёт по клавиатуре ("клац-клац-клац"), пьёт кофе и что-то бормочет. При этом: не взаимодействует с клиентом, не строит дом, не лечит людей, а зарплату получает.
Учёные из института когнитивных странностей опубликовали предварительное исследование:
"Представители вида Homo programmatus проводят до 10 часов в день за ритуальным стучанием по плоской коробке. Цель действия неясна, но, судя по всему, связано с укрощением невидимых существ по имени NullPointer и Segmentation Fault. Иногда вместо слов они пишут “if (true) { while(true) { ... } }” - вероятно, заклинание бесконечной защиты".
В этот День программиста - честь и уважение всем, кто:
пишет код, который никто не видит;
чинит то, что никто не ломал;
объясняет нетехнарям, почему "просто добавить кнопку" - это три спринта.
Пусть ваши функции возвращают нужное, логи будут читаемы, дедлайны гибкими, а код будет элегантным, рабочим и читаемым (Update ver 1.1).
С праздником вас, Хранители кода!
Представлен музыкальный сервис OpenSpot Music с треками со многих стримингов с высоким качеством музыки. Алгоритмы подборки помогут найти новые песни, можно собрать собственные плейлисты.

Посткапитализм и 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 — система управления отчетами
Я создал систему (ну как сам, навайбкодил), состоящую из двух компонентов:
Jupyter Lab Sidecar. Это обычный Jupyter Lab в Docker-контейнере. Здесь разработчики пишут и тестируют отчеты, как привыкли.
juport — система управления. Веб-приложение на Python, которое сканирует папку с ноутбуками. Оно позволяет запускать отчеты вручную или по расписанию, выполняет их в изолированном окружении, генерирует HTML-версии без лишней информации, собирает все артефакты (Excel, картинки) в одну табличку и предоставляет удобный веб-интерфейс. Авторизация — через LDAP.
Как это работает
Разработка отчета:
Вы создаете ноутбук в Jupyter Lab.
Пишете код, тестируете, сохраняете.
Используете переменные окружения для конфигурации, чтобы не хранить пароли в коде.
Запуск отчета:
Заходите в веб-интерфейс juport.
Видите список всех ноутбуков.
Нажимаете «Запустить» или настраиваете расписание.
Система выполняет ноутбук и собирает результаты.
Результат:
Чистый HTML-отчет без кода и паролей, доступный для просмотра.
Все Excel-файлы, картинки и PDF собраны в одном месте.
Удобный интерфейс для скачивания.
История выполнений и логи.
Как это сделано
Я не написал ни одной строчки кода сам. Все навайбкодил через Cursor с помощью промптов.
Да, именно так. Привыкайте. Такова реальность.
Андрея Карпатый говорил о том, что скоро разработка будет выглядеть совсем иначе. И он прав.
Мы, миллениалы, единственное поколение, которое разбиралось, как собрать компьютер с нуля. Бумеры были до бума ПК, а зумеры уже родились, когда все было готово. С кодом происходит то же самое. Через N лет опытные разработчики будут получать отличные результаты через промпты, потому что у них есть 20 лет опыта. Этот опыт — не знание синтаксиса, а понимание:
Архитектурных паттернов
Принципов проектирования
Торговых компромиссов
Потенциальных проблем
Именно поэтому те, кто шарит, получат отличный результат, а те, кто не шарит, получат «коричневую субстанцию».
AI-ассистенты — это не замена разработчикам, а инструмент, который многократно увеличивает нашу скорость. Опыт и понимание архитектуры становятся еще важнее. А новичкам будет сложнее, потому что им придется мотивированно изучать технологии, чтобы получать от нейросетей качественные вещи.
Выводы
AI-ассистенты — это не замена, а инструмент.
Опыт и понимание архитектуры становятся критически важными.
Скорость разработки для опытных специалистов вырастет в разы.
Новичкам придется приложить больше усилий для освоения профессии.
А как вы видите будущее разработки с AI? Делитесь в комментариях!
ИБ-ДАЙДЖЕСТ INFOWATCH
Найти хобби и потерять данные. Утечка ПДн 4541 человека произошла в результате хакерской атаки на крупнейший сайт для шахматистов.
Загрузил конфиденциальную информацию компании на личный диск и отнес конкурентам. Рассматриваем на примере Scale AI, почему важно следить за данными и недобросовестными сотрудниками.
ИБ-производители стали жертвами кибератаки на цепочку поставок. Утечка данных клиентов произошла из CRM.
Оплата улыбкой, или как штаты защищаются от распространения цифровой слежки в повседневной жизни.
Утечка данных, падение рейтинга и сокращение премий. Хороший пример, как проблемы в сфере ИБ существенно влияют на репутацию и размер вознаграждения руководителей высшего звена.
Кибератака на производителя шин и остановка производства на нескольких предприятиях. Что позволило быстро идентифицировать и локализовать нарушение?
Нейросети в QA. Подборка важнейших кейсов применения.

Искусственный интеллект в QA – это уже не теория из будущего, а практический инструмент, доступный здесь и сейчас. Пока одни спорят, заменит ли ИИ тестировщика, другие уже используют его, чтобы избавиться от рутины и сосредоточиться на действительно сложных задачах.
Нейросети способны взять на себя генерацию тестовых данных, помочь в написании автотестов, проанализировать тысячи строк логов и даже превратить технический отчет в понятный документ для бизнес-команды. В этом коротком посте я собрал подборку конкретных кейсов, которые помогут вам сделать работу быстрее, качественнее и интереснее.
Кейсы по использованию нейросетей в QA
Генерация тест-кейсов на основе требований
Подготовка позитивных и негативных тестовых данных
Адаптация и улучшение баг-репортов
Перевод сценариев в формат Gherkin (Given-When-Then)
Генерация идей для негативного тестирования
Автоматический анализ логов ошибок
Помощь в написании автотестов и шаблонов
Конвертация технической информации в пользовательские инструкции
Голосовое управление заведением баг-репортов и создания чек-листов
Генерация финальных отчётов по тестированию
Помощь в написании автотестов: генерация кода, шаблонов и отдельных функций для фреймворков автоматизации
Подготовка баг-таблиц и чек-листов
Создание слайдов по итогам тестирования
Автоматическая сверка ожидаемого и фактического поведения
Генерация SQL-запросов на основе текстового запроса
Перевод технических отчётов для бизнес-аудитории
Проверка качества текста / интерфейса (UX-копирайтинг)
Генерация данных для нагрузочного тестирования
Сравнение версий документации / требований
Сбор фидбэка из отзывов пользователей (тематический анализ)
Создание чат-ассистента по документации и API
Анализ требований на предмет неясностей, противоречий и неполноты
Прогнозирование областей с высокой вероятностью дефектов
Оптимизация тестовых наборов (выявление избыточных тестов)
Генерация идей для тестов безопасности
Этот список – лишь небольшая часть того, как нейросети могут усилить работу 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 и хорошо сочетается с моделью виртуальных потоков.
Что имеет смысл сделать уже сейчас без перелома архитектуры:
Планировать переход на JDK 25, чтобы получить финальные Scoped Values и полный набор улучшений Loom.
Запускать задачи через Executors.newVirtualThreadPerTaskExecutor() или фабрику Thread.ofVirtual() — так вы используете Loom «как задумано».
Проаудировать горячие пути — убрать блокирующие вызовы из‑под synchronized, сузить критические секции. При необходимости оставлять ReentrantLock, но не рассчитывать на него как на универсальное лекарство от пиннинга.
Включить наблюдаемость — отслеживать события пиннинга виртуальных потоков, рост очередей/времени ожидания и аномальный CLOSE_WAIT.
Там, где сегодня используются тяжелые 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. Содержит теорию в формате текстовых конспектов и более 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) значительно сдвигали понимание программирования.
Почему это так? А потому что в остатке мы упираемся в побочные эффекты, барьеры абстракции (тут сикп) и грамотное управление состоянием. Вот такие пироги
Больше про разработку в моем телеграм-канале Организованное программирование