Сохранёнки программиста

Public

Просмотреть канал

Не можете присоединиться? @prog_stuff

6.6k Участники

Обновлено: May 11, 2026 at 12:46 AM

Сохранёнки программиста

Заметки и ссылки на будущее, чтобы изучить когда будет время. Разместить рекламу: @tproger_sales_bot Правила общения: https://tprg.ru/rules Другие каналы: @tproger_channels Другие наши проекты: https://tprg.ru/med

@prog_stuff is a dedicated channel for tproger_channels and httpstprgrurules with regular updates in Кодинг и программирование

Рейтинг

Глобальный рейтинг

#456

Рейтинг по языку

#45

Рейтинг по категории

#23

-1

Рост участников (Последние 13 дней)

Всего: 6.6K

Рост за 24ч: +0 0%

Последние посты

Сохранёнки программиста

13 мая 2026 г., 15:57

📷 Photo

USB устроен как сетевое программирование — только это мало кто объясняет именно так

Endpoint — это порт. Дескриптор устройства — аналог DNS-записи. Хост всегда инициирует соединение, устройство только отвечает. Если вы работали с сокетами, модель USB окажется неожиданно знакомой.

https://tproger.ru/translations/usb-dlya-razrabotchikov-kak-napisat-drajver-iz-polzovatelskogo разбирает USB с разработческой точки зрения: четыре типа передачи данных, как читать дескрипторы, и главное — как написать полноценный драйвер в userspace через libusb, без единой строки кода ядра.

В качестве практического примера — Fastboot-клиент на C++ примерно в 50 строк.

Материал стоит отложить: он даёт концептуальную рамку, после которой USB перестаёт быть чёрным ящиком.

739

Сохранёнки программиста

13 мая 2026 г., 15:57

📷 Photo

9 нативных API браузера, ради которых обычно зря ставят npm-пакет

Справочник-пособие на случай, когда в следующий раз рука потянется к npm install: разбор девяти вещей, которые браузер уже умеет сам. requestIdleCallback для фоновых задач, :focus-within вместо сорока строк JS на focus и blur, navigator.onLine и события offline/online для PWA, requestAnimationFrame вместо setInterval на 16 мс, container queries для самодостаточных компонентов.

Дальше интереснее: crypto.randomUUID() вместо самописных «достаточно случайных» ID, нативный  с фокус-трапом и доступностью из коробки, Web Speech API для распознавания речи и @supports для CSS feature detection.

Полезно https://tproger.ru/translations/9-nativnyh-api-brauzera-vmesto-npm-paketov, когда в следующий раз захочется тянуть в проект uuid, focus-trap или очередной модал.

709

Сохранёнки программиста

13 мая 2026 г., 15:57

📷 Photo

Устали от уймы API-ключей и танцев с бубном вокруг OpenAI, Claude и Gemini?

Снять эту головную боль может один API-роутер.
https://tprg.ru/YWhU, почему три разных API могут тормозить ваш проект и как подключить GPT-5.4, Claude Sonnet 4.6 и Gemini 3.1 Pro через единую точку входа без переписывания кода.

Кратко о содержании:
— Что умеет хороший роутер: fallback, балансировка, кеш, единый биллинг.
— Пошаговый гайд подключения через одни API на Python и Node.js.
— Реальный кейс: мультимодельный бот с авто-переключением за 30 минут.
— Подводные камни: контекстные окна, latency, rate limits (и как их обойти).

Читать материал: https://tprg.ru/YWhU

704

Сохранёнки программиста

13 мая 2026 г., 15:57

Отправить email из скрипта — вызов одной функции. Сделать так, чтобы он дошёл до инбокса и не улетел в спам — инженерия.

На Tproger https://tproger.ru/translations/kak-na-samom-dele-rabotaet-elektronnaya-pochta--put-pisma-ot-otp перевод с пошаговым разбором того, как почта работает под капотом на уровне инфраструктуры:

— Цепочка доставки: MUA (клиент), MTA (сервер пересылки), MDA (агент доставки).

— Как SMTP ищет маршрут до целевого домена через DNS и MX-записи.

— Подробный разбор SPF, DKIM и DMARC, это база, которую нужно понимать, чтобы ваши транзакционные письма не отбивались серверами получателей.

— Разница между протоколами извлечения IMAP и POP3.

Годный технический фундамент, чтобы понимать, на каком именно узле отваливаются письма сброса пароля с вашего продакшена: https://tprg.ru/XOao

@prog_stuff

906

Сохранёнки программиста

13 мая 2026 г., 15:57

📷 Photo

Какие доки может распознавать ИИ

Субботнее разглядывательное: у нас на сайте вышла https://tprg.ru/VZR6. Так вот, там уйма наглядных примеров с картинками: какие документы под силу нейросетке, и как это распознавание выглядит. Всех приглашаю к залипанию.

А вы любите разглядывать документы?😏

980

Сохранёнки программиста

13 мая 2026 г., 15:57

Автор https://tproger.ru/translations/join---ne-dorogaya-operaciya--benchmark-na-milliarde-strok-eto-doka прогнал JOIN на таблице из миллиарда строк и проверил, насколько оправдан страх перед этой операцией.

Главный вывод: JOIN сам по себе не дорогой. Дорогими его делают конкретные вещи: отсутствие индексов на join-колонках, выбор SELECT * с широкими строками и неправильный порядок фильтрации.

Тезисы из бенчмарка:

— Правильно проиндексированный JOIN на миллиарде строк отрабатывает быстрее, чем денормализованная «One Big Table» при выборке нескольких колонок.

— OBT начинает выигрывать только когда нужно вытащить почти все колонки широкой строки, но это редкий паттерн.

— Главные виновники медленных JOIN-запросов: отсутствие индексов → full scan, CAST() в условии join → план не использует индекс, агрегация после join вместо до него.

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

@prog_stuff

832

Сохранёнки программиста

13 мая 2026 г., 15:57

В блоге Dochia https://blog.dochia.dev/blog/waterfall-returning/ интересная статья о том, как нейросети незаметно возвращают нас к методологии Waterfall.

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

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

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

Формируется новая парадигма. Написание ТЗ снова становится самым дорогим этапом, в котором незаменим человек. Код при этом превращается в дешёвый одноразовый расходник. Вы пишете подробные требования, отдаёте их нейросети, показываете результат пользователям, и если что-то не так, просто меняете ТЗ и генерируете проект заново.

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

Ссылка на полную статью: https://blog.dochia.dev/blog/waterfall-returning/

@prog_stuff

12,100

Сохранёнки программиста

13 мая 2026 г., 15:57

Если вы помните https://paulgraham.com/foundermode.html, то сооснователь GitLab Сид Сийбрандий нашёл этой концепции самое нетривиальное применение. В 2022 году у него обнаружили редкий рак костей, а после первого этапа лечения случился рецидив. Врачи сообщили, что стандартные протоколы исчерпаны.

Вместо того чтобы смириться, Сид перестал делегировать медицинские решения больницам. Он взял управление ситуацией в свои руки, нанял бывшего руководителя из компании 10x Genomics на роль проектного менеджера своего здоровья и собрал личную команду учёных.

Его инженерный подход к онкологии выглядел так:
— команда сделала полное секвенирование клеток опухоли и использовала ИИ для поиска скрытых закономерностей в анализах;
— Сид выложил 25 терабайт своих медицинских данных в открытый доступ, чтобы любой исследователь в мире мог изучить их и предложить решение;
— глубокий анализ данных помог найти в Германии экспериментальную терапию, которая точечно била по уязвимости именно его формы опухоли;
— параллельно с собственным лечением он запустил семь стартапов в сфере биотеха для развития персонализированной медицины.

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

Полная статья: https://tprg.ru/a19w

@prog_stuff

713

Сохранёнки программиста

13 мая 2026 г., 15:57

Хочу стать техлидом — большая подборка материалов

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

В этой подборке собрано 100+ крутых ресурсов: книги, блоги, рассылки и эксперты, которых стоит читать. Тут есть всё — от глубокой системной архитектуры до навыков эффективного менеджмента. Не стоит гнаться за всем сразу, лучше выбрать несколько направлений и прокачиваться в них.

https://github.com/gregorojstersek/resources-to-become-a-great-engineering-leader

#подборка #en

944

Сохранёнки программиста

13 мая 2026 г., 15:57

📷 Photo

Разработчик Эрик Ленгьел (Eric Lengyel) https://terathon.com/blog/decade-slug.html огромный подарок для индустрии графики и геймдева. Он досрочно, за 12 лет до истечения срока, передал патент на свой знаменитый алгоритм Slug в общественное достояние.

Slug — это метод рендеринга шрифтов (и векторной графики) на GPU напрямую из кривых Безье, вообще без использования предзапечённых текстур или атласов. Это позволяет отрисовывать идеально чёткий, сглаженный текст любого размера и под любым углом. Алгоритм уже 10 лет является индустриальным стандартом: лицензию на него покупали Blizzard, id Software, Adobe, Ubisoft и другие гиганты.

Главная математическая фишка последних версий Slug — это «динамическое расширение» (dynamic dilation). Вершинный шейдер на лету высчитывает матрицу трансформации и автоматически расширяет полигон каждого глифа ровно на полпикселя в экранном пространстве. Это гарантирует, что растеризатор не потеряет ни одного сглаженного пикселя на границах букв, и при этом не тратит ресурсы GPU на отрисовку лишнего пустого пространства (как это бывает при фиксированном отступе).

Теперь использовать эту технологию можно абсолютно бесплатно в любых проектах. Автор уже выложил эталонные шейдеры (вершинный и пиксельный) на GitHub под лицензией MIT: https://github.com/EricLengyel/Slug

@prog_stuff

Сохранёнки программиста

3 апр. 2026 г., 13:15

Интересная мысль из https://boreal.social/post/ai-wont-make-you-rich-but-fixing-bugs-in-ai-slopware-will: «ИИ не сделает вас богатым, а вот починка багов в сгенерированном ИИ-мусоре — сделает». Сейчас все увлеклись генерацией кода: джуны, менеджеры и стартаперы штампуют проекты целыми кусками с помощью Claude и Copilot. В результате на свет появляется так называемый «AI slopware» — код, который вроде бы работает на демо-стенде, но внутри представляет собой неподдерживаемое спагетти.

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

Автор поста считает, что золотая лихорадка ИИ-стартапов и бесконечных «ChatGPT-обёрток» скоро пойдёт на спад. А вот горы некачественного, сгенерированного кода останутся в корпоративном секторе на десятилетия.

В ближайшие годы самой высокооплачиваемой и востребованной работой станет не написание новых фичей, а хардкорный дебаггинг и рефакторинг этого самого «ИИ-мусора». Компании будут готовы платить огромные деньги инженерам с глубоким пониманием систем, способным разгрести архитектурные катастрофы, оставленные автогенераторами.

Умение вслепую промтить нейросети перестанет быть преимуществом. Главным навыком снова станет фундаментальное понимание того, как работают технологии.

Полный текст: https://boreal.social/post/ai-wont-make-you-rich-but-fixing-bugs-in-ai-slopware-will

778

Сохранёнки программиста

3 апр. 2026 г., 13:15

В блоге NixCI https://blog.nix-ci.com/post/2026-03-09_ci-should-fail-on-your-machine-first отличная статья, которая ставит под сомнение привычный всем нам процесс работы с непрерывной интеграцией. Обычно мы воспринимаем CI как удалённый сервер (GitHub Actions, GitLab CI), куда мы пушим код и ждём заветную зелёную галочку. Но у этого подхода есть огромный минус — длинная петля обратной связи.

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

Автор предлагает концепцию Local-First CI. Идея в том, что вся пайплайн-логика должна быть описана так, чтобы она могла локально выполниться на машине разработчика до пуша в репозиторий.

Какие плюсы у локального CI:

— Скорость. Рабочие машины разработчиков (особенно современные Mac) часто гораздо мощнее стандартных бесплатных раннеров (у тех же GitHub Actions всего 4 vCPU и 16 GB RAM).

— Фокус. Вы не переключаете контекст. Ошибка падает сразу, и вы фиксите её, оставаясь в потоке.

— Отсутствие вендор-лока. Если весь ваш CI — это условный баш-скрипт ./ci.sh в корне проекта, вам всё равно, где его запускать. Вы не привязаны к специфичным YAML-файлам конкретного провайдера.

— Локальная воспроизводимость. Больше не нужно делать коммиты с названиями fix ci, try again, maybe now?, пытаясь вслепую угадать, почему тест падает на сервере, но работает у вас.

Есть и минусы, конечно.

Главная проблема наивного подхода с ./ci.sh — рассинхрон сред. У вас локально macOS и gcc 15, а на сервере Ubuntu и gcc 14. У вас замусоренная папка с билдами и завалявшийся .env, а CI стартует с чистого листа.

Решением автор логично называет воспроизводимые сборки (reproducible builds), в частности — использование Nix. Команда nix flake check гарантирует, что локальное и удалённое окружение будут абсолютно идентичными вплоть до версий системных библиотек . Но даже без Nix, максимальный перенос логики проверок в локальную среду (например, через Docker) — это отличная практика для ускорения разработки.

Полная статья: https://blog.nix-ci.com/post/2026-03-09_ci-should-fail-on-your-machine-first

Сохранёнки программиста

3 апр. 2026 г., 13:15

Scientific American https://www.scientificamerican.com/article/why-developers-using-ai-are-working-longer-hours/ свежую статистику о том, как нейросети влияют на жизнь разработчиков. Изначально все надеялись, что ИИ разгрузит инженеров, но реальные цифры показывают обратную картину: программисты стали работать больше и чаще перерабатывать по вечерам.
​
Главные причины такого парадокса:

— Падает стабильность релизов. Нейросети выдают код мгновенно, но его нужно тщательно проверять. Отчёт DORA подтверждает, что активное использование ИИ напрямую связано с ростом откатов и горячих фиксов на проде.
​
— Растут ожидания руководства. Бизнес замечает ускорение и требует закрывать больше задач. В итоге инженеры берут дополнительный объем, а количество их коммитов в нерабочие часы выросло почти на 20%
​
— Усложняется отладка. Инженеры объективно хуже понимают сгенерированную логику. Когда такой код ломается, на поиск причин и исправление багов уходит гораздо больше сил.
​
Получается, что инструменты действительно ускоряют написание новых блоков, но вся экономия времени полностью сгорает на этапах тестирования и ревью. А если вы начинаете писать код быстрее, в качестве награды менеджеры просто накидывают вам больше новых тикетов.

Полная статья: https://www.scientificamerican.com/article/why-developers-using-ai-are-working-longer-hours/

842

Сохранёнки программиста

3 апр. 2026 г., 13:15

Разработчик Рич Уайтхаус https://richwhitehouse.com/index.php?postid=77 жёсткую статью о том, почему он полностью разочаровался в опенсорсе и перестал писать бесплатный код. По его мнению, вся эта культура в итоге просто помогает крупным корпорациям обесценивать работу обычных инженеров.
​
Главные мысли из его лонгрида:

— компании годами используют открытые репозитории как бесплатную ресурсную базу, при этом регулярно забивая на лицензии;
​
— бум нейросетей только добил ситуацию, корпорации молча скормили своим моделям десятилетия чужого труда без оглядки на авторское право;
​
— внутри самих опенсорсных комьюнити процветает токсичность, синдром вахтера и бесконечные споры ради раздутого эго мейнтейнеров.
​
Уайтхаус уверен, что идея писать код на общее благо отлично звучит только в теории. На практике любые полезные наработки быстро и безвозмездно забирают гиганты индустрии. В итоге это бьёт по нам самим. Ценность разработчиков на рынке падает, потому что бизнесу становится выгоднее вкладываться в серверы и ИИ, бесплатно обученный на нашем же коде.

Полная статья: https://richwhitehouse.com/index.php?postid=77

2,100

Сохранёнки программиста

3 апр. 2026 г., 13:15

🎥 Video

Посмотрите на этот https://lyra.horse/x86css/. Полноценный эмулятор процессора архитектуры x86 на чистом CSS. Никакого JavaScript или WebAssembly, все вычисления происходят исключительно силами браузерного движка стилей.

Как это реализовано технически:
— эмулятор исполняет реальный машинный код для процессоров 8086;
​— тактовый генератор построен на CSS-анимациях, поэтому система работает автономно и не требует от пользователя постоянно водить курсором по экрану;
​— логика работает благодаря новым спецификациям CSS, таким как условные операторы if(), стилевые запросы и кастомные функции

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

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

2,690

Сохранёнки программиста

3 апр. 2026 г., 13:15

📷 Photo

Как эволюционировали OCR-программы

Инструменты для распознавания текста (OCR) появились еще в 1960-х, но только последние 20 лет они используются для чтения документов и облегчают нашу с вами жизнь.

За этот период направление получило мощное развитие: от простого считывания перешло к мультимодальной форензике и антифроду. Подробнее про историю этого увлекательного процесса можно прочитать https://tprg.ru/nBqx.

901

Сохранёнки программиста

3 апр. 2026 г., 13:15

📷 Photo

Если вы когда-нибудь работали в кровавом энтерпрайзе на Java, https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition может вызвать у вас флешбеки и легкую панику. Разработчики создали пародийный проект FizzBuzz Enterprise Edition — ту самую задачу с собеседований про деление чисел на 3 и 5, но написанную «серьёзными бизнесменами для серьёзных бизнес-целей».
​
Вместо десяти строк кода авторы наворотили гигантскую архитектуру. Внутри бесконечные вложенные папки, десяток фабрик, интерфейсы для интерфейсов и классы с названиями в духе FizzBuzzOutputGenerationContextVisitor.
​
Отдельный вид искусства в этом проекте — раздел https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition/issues. Пользователи активно подыгрывают авторам и создают гениальные тикеты. Например, кто-то пожаловался, что код написан слишком качественно и потребовал ухудшить его, чтобы соответствовать реальным индустриальным стандартам. Или предлагают уволить бизнес-аналитика, потому что он слишком понятно объяснил задачу, и требуют добавить больше уровней абстракции, чтобы никто не смог найти, откуда импортируется код.

Сохранёнки программиста

3 апр. 2026 г., 13:15

[poll]

751

Сохранёнки программиста

3 апр. 2026 г., 13:15

📷 Photo

Победителями https://tprg.ru/5aYo 🐀становятся...

Здесь играет барабанная дробь и интригующая музыка... Вам нужно только выждать драматическую паузу перед объявлением победителей — в каждой номинации он один, и определяется большинством голосов. Готовы?

В номинации «Продукт года» золотая мышь достается компании:
🐀NetVision за https://tprg.ru/u2qx.

В номинации «Облачный продукт года» побеждает компания:
🐀Гравитон https://tprg.ru/TN3h

Звание «IT-ивент года» вручается компании:
🐀Островок! за https://tprg.ru/gxcK

И в категории «Дизайн года» первое место занимает компания:
🐀AcademiaDev за https://tprg.ru/70rB.

Каждый ваш лайк, голос влияли на исход премии. Давайте поддержим всех — ставьте 🏆участникам, которые хоть и не заняли призового места, но точно остались в сердечке.
И 🔥, если хотите аналогичных активностей и готовы выбирать еще!

502

Сохранёнки программиста

3 апр. 2026 г., 13:15

Разработчик из Mozilla Габриэле Свельто https://mas.to/@gabrielesvelto/116171750653898304 технической статистикой о причинах падений Firefox. Некоторое время назад команда инженеров внедрила в браузер алгоритм для анализа краш-репортов, который умеет выявлять одиночные искажения битов в памяти.

Собранные данные показали неочевидную картину:
— система точно зафиксировала битфлипы в 5% всех отчётов об ошибках;
— по расчётам команды реальная доля таких инцидентов доходит до 10%.

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

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

757

Сохранёнки программиста

31 мар. 2026 г., 10:42

[poll]

656

Сохранёнки программиста

28 мар. 2026 г., 22:03

Никого не повышают за простоту

Инженер A делает фичу за два дня: пишет 50 строк понятного кода, тестирует, выкатывает.

Инженер B берёт ту же задачу, но строит «масштабируемую архитектуру»: добавляет pub/sub, новые абстракции и фреймворк для конфигурации. Тратит три недели.

На performance review работа B звучит как готовый кейс: «спроектировал масштабируемую событийно-ориентированную архитектуру, внедрил переиспользуемый слой абстракций». Работа A звучит как «сделал фичу X». Никто не получает повышение за ту сложность, которой он избежал.

Индустрия системно поощряет оверинжиниринг:

— На собеседованиях кандидаты рисуют сложные схемы с микросервисами и шардированием, потому что простое решение с одной БД кажется интервьюерам недостаточно «умным»

— На код-ревью простые решения обрастают абстракциями из-за вопросов коллег «а не стоит ли заложиться на будущее?»

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

Автор даёт совет: решение не строить сложную систему — это важное инженерное решение. Его нужно документировать. Вместо «сделал фичу X» пишите: «Оценил три подхода, включая event-driven архитектуру. Определил, что простое решение покрывает все текущие требования. Выкатил за 2 дня, 0 инцидентов за полгода».

Статья целиком: https://terriblesoftware.org/2026/03/03/nobody-gets-promoted-for-simplicity/

697

Showing 22 of 22 posts

No more posts

Рейтинг

Требуется вход

Отзывы пользователей (0)

Пока нет отзывов. Будьте первым, кто поделится своим опытом!

Сохранёнки программиста

Сохранёнки программиста

Рейтинг

Рост участников (Последние 13 дней)

Последние посты

Рейтинг

Отзывы пользователей (0)

Похожие каналы Telegram

Albinasummer

PM работа. Проектные менеджеры

Русский Модный Код

Литературный коД

Компьютерная математика Weekly

AI Projects

ReLab Family

Книги по программированию

Похожие каналы Telegram

Albinasummer

PM работа. Проектные менеджеры

Русский Модный Код

Литературный коД

Компьютерная математика Weekly

AI Projects

ReLab Family

Книги по программированию

Отзывы пользователей (0)

Последние посты