🚨 DeepSeek приостанавливает платежи за API
Из-за перегрузки серверов компания DeepSeek временно отключила пополнение счетов. Пользователи могут использовать только те средства, что уже на балансе. 💳
Похоже, растущий спрос на их API требует масштабирования. ⏳
Вот тут подробнее ТЫК
#новости
Из-за перегрузки серверов компания DeepSeek временно отключила пополнение счетов. Пользователи могут использовать только те средства, что уже на балансе. 💳
Похоже, растущий спрос на их API требует масштабирования. ⏳
Вот тут подробнее ТЫК
#новости
Bloomberg.com
DeepSeek Limits Access to AI Model as Demand Strains Capacity
DeepSeek, the Chinese startup whose artificial-intelligence model roiled global markets last week, said it would restrict access to its application programming interface service because of shortages with its server capacity.
👍1
🌞 Доброе утро! Пока вы разбираетесь с делами, соцсети снова и снова подсовывают мне одну и ту же новость… Ну что ж, поделюсь.
⚡️ Рабочую неделю сократят до 36 часов! Но… только после завершения СВО.
📌 Законопроект уже готов, и изменения коснутся офисных работников и торговли. В Испании такая схема пошла экономике на пользу, а у нас пока 40 часов в неделю.
📅 Но обсуждать реформу начнут только после окончания боевых действий.
Так что ждём. ⏳
⚡️ Рабочую неделю сократят до 36 часов! Но… только после завершения СВО.
📌 Законопроект уже готов, и изменения коснутся офисных работников и торговли. В Испании такая схема пошла экономике на пользу, а у нас пока 40 часов в неделю.
📅 Но обсуждать реформу начнут только после окончания боевых действий.
Так что ждём. ⏳
👍1
🚀 Нейросеть за $50. Технологии становятся дешевле или хуже?
Сегодня наткнулся на новость: американские спецы обучили нейросетку за $50. Причем данные для обучения им сгенерил... GPT. Да, та самая нейросетка учила другую нейросетку. Матрешка технологий.
И вот я сижу и думаю, в каком же некачественном мире я живу. Это ощущение меня не покидало с тех пор, как я впервые услышал про Agile.
📉 Как работает реальный мир технологий?
Бюджет на маркетинг больше, чем бюджет на разработку.
То есть, насколько крутой продукт ты пилишь — вообще не важно, если никто о нем не узнает.
Компании стремятся как можно быстрее закинуть на рынок сырую поделку, снять метрики и если зашло — тогда уже допиливают.
А самое главное — потребитель давно не цель, а товар.
👕 Если массово шьют футболки, значит, есть массовый потребитель.
🧠 Если каждая вторая компания заявляет, что у нее есть своя нейросеть, значит, просто так надо говорить. Потому что если не скажешь — инвестор унесет деньги тем, кто сказал.
А на чем реально обучали нейросеть? На реальных данных или синтетике?
Какая разница, главное, чтобы звучало хайпово.
🧐 Что думаешь? Мир технологий реально деградирует или это просто новая норма? 👇
#толки
Сегодня наткнулся на новость: американские спецы обучили нейросетку за $50. Причем данные для обучения им сгенерил... GPT. Да, та самая нейросетка учила другую нейросетку. Матрешка технологий.
И вот я сижу и думаю, в каком же некачественном мире я живу. Это ощущение меня не покидало с тех пор, как я впервые услышал про Agile.
📉 Как работает реальный мир технологий?
Бюджет на маркетинг больше, чем бюджет на разработку.
То есть, насколько крутой продукт ты пилишь — вообще не важно, если никто о нем не узнает.
Компании стремятся как можно быстрее закинуть на рынок сырую поделку, снять метрики и если зашло — тогда уже допиливают.
А самое главное — потребитель давно не цель, а товар.
👕 Если массово шьют футболки, значит, есть массовый потребитель.
🧠 Если каждая вторая компания заявляет, что у нее есть своя нейросеть, значит, просто так надо говорить. Потому что если не скажешь — инвестор унесет деньги тем, кто сказал.
А на чем реально обучали нейросеть? На реальных данных или синтетике?
Какая разница, главное, чтобы звучало хайпово.
🧐 Что думаешь? Мир технологий реально деградирует или это просто новая норма? 👇
#толки
TechCrunch
Researchers created an open rival to OpenAI's o1 'reasoning' model for under $50 | TechCrunch
AI researchers at Stanford and the University of Washington were able to train an AI "reasoning" model for under $50 in cloud compute credits, according
👍1
🛠 Битва языков: Rust vs C в контексте Linux
В мире Linux заваривается новый срач. И на этот раз не про systemd, а про Rust vs C.
Пока одни с пеной у рта доказывают, что Rust — это спасение от багов и UB, другие (особенно старожилы Linux-кода) видят в нем раковую опухоль. Нет, не сам язык, а кросс-языковую кодовую базу — монстра, который ломает чистоту C-шного мира.
Почему Rust вообще залез в ядро?
Linux исторически написан на C, но проблемы с безопасностью никуда не делись: use-after-free, buffer overflow, null-pointer dereference — старые добрые товарищи. Rust решает это на уровне компилятора. То есть просто нельзя написать кривой код, потому что компилятор скажет: «Ты дебил, переделывай».
Но есть нюанс. Кросс-языковая кодовая база — это боль. Когда ядро на C, а новый код пишется на Rust, начинается зоопарк зависимости, ABI, совместимости, и вот уже приходится не разрабатывать, а разруливать.
Что дальше?
Rust не вытеснит C из ядра, но будет отгрызать куски кода, где критична безопасность. Одни ликуют, другие возмущены, но назад пути нет.
А ты за кого: C или Rust? Или вообще на асме писал бы? 🧐
#новости
В мире Linux заваривается новый срач. И на этот раз не про systemd, а про Rust vs C.
Пока одни с пеной у рта доказывают, что Rust — это спасение от багов и UB, другие (особенно старожилы Linux-кода) видят в нем раковую опухоль. Нет, не сам язык, а кросс-языковую кодовую базу — монстра, который ломает чистоту C-шного мира.
Почему Rust вообще залез в ядро?
Linux исторически написан на C, но проблемы с безопасностью никуда не делись: use-after-free, buffer overflow, null-pointer dereference — старые добрые товарищи. Rust решает это на уровне компилятора. То есть просто нельзя написать кривой код, потому что компилятор скажет: «Ты дебил, переделывай».
Но есть нюанс. Кросс-языковая кодовая база — это боль. Когда ядро на C, а новый код пишется на Rust, начинается зоопарк зависимости, ABI, совместимости, и вот уже приходится не разрабатывать, а разруливать.
Что дальше?
Rust не вытеснит C из ядра, но будет отгрызать куски кода, где критична безопасность. Одни ликуют, другие возмущены, но назад пути нет.
А ты за кого: C или Rust? Или вообще на асме писал бы? 🧐
#новости
👍1
🚀 Мизулина предложила разблокировать X (бывший Twitter) в России — мол, теперь там меньше цензуры и деструктива.
А у меня X давно был, просто стоял пыльный в углу. Но теперь я его почистил, помыл и готов к разблокировке 😎
А вот и ссылочка, если что 👉 https://x.com/debug_leg
#новости
А у меня X давно был, просто стоял пыльный в углу. Но теперь я его почистил, помыл и готов к разблокировке 😎
А вот и ссылочка, если что 👉 https://x.com/debug_leg
#новости
👍2
📱 Цифровой шаббат: мозгам тоже нужен выходной
Всё чаще ловлю себя на том, что залипаю в соцсетях. Эти короткие видео засасывают так, что даже не замечаешь, как прошло полчаса. А месяц назад наткнулся на статью, где написано, что от этого чуть ли не мозги гниют. Теперь мы с Юлей подкалываем друг друга: если кто-то зависает в телефоне, сразу получаем «Эй, у тебя там уже плесень растёт?» 😆
Но шутки в сторону — надо что-то делать. Первая мера — цифровой шаббат. День без телефона, соцсетей, новостей и прочего инфошума. Только офлайн, только хардкор.
А может, ну его нафиг и взять Nokia 3310? 🤔
#bio
Всё чаще ловлю себя на том, что залипаю в соцсетях. Эти короткие видео засасывают так, что даже не замечаешь, как прошло полчаса. А месяц назад наткнулся на статью, где написано, что от этого чуть ли не мозги гниют. Теперь мы с Юлей подкалываем друг друга: если кто-то зависает в телефоне, сразу получаем «Эй, у тебя там уже плесень растёт?» 😆
Но шутки в сторону — надо что-то делать. Первая мера — цифровой шаббат. День без телефона, соцсетей, новостей и прочего инфошума. Только офлайн, только хардкор.
А может, ну его нафиг и взять Nokia 3310? 🤔
#bio
🔥1
💡 Почему так много языков программирования?
Долго не мог понять, зачем придумывать новые языки, пока не услышал одну шутку:
📜 У нас есть 10 стандартов. Давайте объединим их в один универсальный!
📜 Теперь у нас 11 стандартов...
#мем
Долго не мог понять, зачем придумывать новые языки, пока не услышал одну шутку:
📜 У нас есть 10 стандартов. Давайте объединим их в один универсальный!
📜 Теперь у нас 11 стандартов...
#мем
❤1
💻 Кто такие DevOps?
Если спросить разработчика: "Кто такой DevOps?", то можно услышать что-то вроде:
👨💻 "Ну… это админ, который знает не только bash, но и Python, а иногда даже Go!"
В общем-то, не без правды. Но DevOps — это не должность, а культура и подход. Это когда код не просто пишется, а автоматически тестируется, деплоится и масштабируется без боли и страданий.
🚀 Что делает DevOps?
🔹 CI/CD – настраивает конвейер доставки кода (GitLab CI, Jenkins, GitHub Actions), чтобы каждое изменение залетало в прод без магии шаманов.
🔹 Контейнеризация – заворачивает приложения в Docker, а потом ставит их в Kubernetes, чтобы они не падали при первом же нагрузочном тесте.
🔹 Мониторинг и логирование – разворачивает Prometheus, Grafana, Loki, чтобы никто не бегал по серверу с grep’ом в поисках "почему всё упало".
🔹 Автоматизация инфраструктуры – Terraform, Ansible, Helm – всё, что избавляет от ручной настройки серверов, которые "работают, но лучше не трогать".
🔹 Облачные технологии – Selectel, Yandex Cloud, Cloud.ru – чтобы можно было за 5 минут развернуть 100 серверов, а потом за 10 секунд их удалить, когда приходит счёт за облако 😅.
🤔 А DevOps – это команда или один человек?
Есть две модели:
1️⃣ DevOps-команда – отдельный отдел, который обслуживает несколько команд разработки. Минус – часто становится бутылочным горлышком.
2️⃣ DevOps в команде разработки – тогда DevOps-инженер встроен в продуктовую команду и решает задачи конкретного продукта. Это быстрее, но требует хорошего уровня скилла от разработчиков.
🧐 А что по зарплатам?
Ну… если видишь DevOps, который не спешит менять работу – значит, у него либо зарплата хорошая, либо мониторинг настроен идеально 😆
А как у вас? DevOps – это отдельная команда или интегрированы в разработку? 🚀
#толки
Если спросить разработчика: "Кто такой DevOps?", то можно услышать что-то вроде:
👨💻 "Ну… это админ, который знает не только bash, но и Python, а иногда даже Go!"
В общем-то, не без правды. Но DevOps — это не должность, а культура и подход. Это когда код не просто пишется, а автоматически тестируется, деплоится и масштабируется без боли и страданий.
🚀 Что делает DevOps?
🔹 CI/CD – настраивает конвейер доставки кода (GitLab CI, Jenkins, GitHub Actions), чтобы каждое изменение залетало в прод без магии шаманов.
🔹 Контейнеризация – заворачивает приложения в Docker, а потом ставит их в Kubernetes, чтобы они не падали при первом же нагрузочном тесте.
🔹 Мониторинг и логирование – разворачивает Prometheus, Grafana, Loki, чтобы никто не бегал по серверу с grep’ом в поисках "почему всё упало".
🔹 Автоматизация инфраструктуры – Terraform, Ansible, Helm – всё, что избавляет от ручной настройки серверов, которые "работают, но лучше не трогать".
🔹 Облачные технологии – Selectel, Yandex Cloud, Cloud.ru – чтобы можно было за 5 минут развернуть 100 серверов, а потом за 10 секунд их удалить, когда приходит счёт за облако 😅.
🤔 А DevOps – это команда или один человек?
Есть две модели:
1️⃣ DevOps-команда – отдельный отдел, который обслуживает несколько команд разработки. Минус – часто становится бутылочным горлышком.
2️⃣ DevOps в команде разработки – тогда DevOps-инженер встроен в продуктовую команду и решает задачи конкретного продукта. Это быстрее, но требует хорошего уровня скилла от разработчиков.
🧐 А что по зарплатам?
Ну… если видишь DevOps, который не спешит менять работу – значит, у него либо зарплата хорошая, либо мониторинг настроен идеально 😆
А как у вас? DevOps – это отдельная команда или интегрированы в разработку? 🚀
#толки
Доброе утро! ☕️ Маск снова в деле — он хочет купить OpenAI и вернуть компанию к опенсорсу.
Предложение уже на столе у совета директоров, но Альтман не в восторге и даже предложил Маску продать Twitter за 9 млрд в ответ.
Будет ли новая война миллиардеров или OpenAI действительно сменит курс — пока загадка, но скучно точно не будет 🔥
Предложение уже на столе у совета директоров, но Альтман не в восторге и даже предложил Маску продать Twitter за 9 млрд в ответ.
Будет ли новая война миллиардеров или OpenAI действительно сменит курс — пока загадка, но скучно точно не будет 🔥
👍1
🏗 DDD — от теории к практике: что это и как его внедрять
Если ты когда-нибудь страдал от монолитного кода, который невозможно масштабировать, то пора познакомиться с Domain-Driven Design (DDD).
💡 DDD — это про логику бизнеса, а не про базы данных и API. Его цель — построить код вокруг реальных процессов компании, а не вокруг технических решений.
Но вот в чём проблема:
❌ DDD сложно внедрять
❌ Это не просто «новая архитектура» — это другой взгляд на код
❌ Без дисциплины DDD превращается в обычный антипаттерн
📌 Основные принципы DDD
✅ Bounded Context (Ограниченные контексты) — разделяем систему на независимые домены. Например, "Заказы" и "Биллинг" — это разные процессы, их не нужно смешивать.
✅ Ubiquitous Language (Единый язык) — разработчики, аналитики и бизнес должны говорить на одном языке. Если бизнес использует термин "Клиент", а в коде он называется "UserEntity", то кто-то тут явно врёт.
✅ Entities и Value Objects — сущности со своим жизненным циклом и неизменяемые объекты с бизнес-логикой.
✅ Domain Events — важные события, на которые реагируют другие части системы (например, "Заказ создан" → "Биллингу нужно выставить счёт").
📂 Как хранить код по DDD?
Одна из главных ошибок — думать, что DDD = микросервисы. Это не так. Можно строить DDD внутри одного сервиса, если правильно разложить код.
🔹 Базовая структура DDD-сервиса
Если ты когда-нибудь страдал от монолитного кода, который невозможно масштабировать, то пора познакомиться с Domain-Driven Design (DDD).
💡 DDD — это про логику бизнеса, а не про базы данных и API. Его цель — построить код вокруг реальных процессов компании, а не вокруг технических решений.
Но вот в чём проблема:
❌ DDD сложно внедрять
❌ Это не просто «новая архитектура» — это другой взгляд на код
❌ Без дисциплины DDD превращается в обычный антипаттерн
📌 Основные принципы DDD
✅ Bounded Context (Ограниченные контексты) — разделяем систему на независимые домены. Например, "Заказы" и "Биллинг" — это разные процессы, их не нужно смешивать.
✅ Ubiquitous Language (Единый язык) — разработчики, аналитики и бизнес должны говорить на одном языке. Если бизнес использует термин "Клиент", а в коде он называется "UserEntity", то кто-то тут явно врёт.
✅ Entities и Value Objects — сущности со своим жизненным циклом и неизменяемые объекты с бизнес-логикой.
✅ Domain Events — важные события, на которые реагируют другие части системы (например, "Заказ создан" → "Биллингу нужно выставить счёт").
📂 Как хранить код по DDD?
Одна из главных ошибок — думать, что DDD = микросервисы. Это не так. Можно строить DDD внутри одного сервиса, если правильно разложить код.
🔹 Базовая структура DDD-сервиса
/src
├── /order # Контекст "Заказы"
│ ├── /application # Сценарии использования (Use Cases)
│ │ ├── PlaceOrderHandler.py
│ │ ├── CancelOrderHandler.py
│ ├── /domain # Бизнес-логика
│ │ ├── /models # Entities и Value Objects
│ │ │ ├── Order.py
│ │ │ ├── OrderItem.py
│ │ │ ├── OrderStatus.py
│ │ ├── /services # Бизнес-сервисы (доменные)
│ │ │ ├── OrderService.py
│ │ │ ├── DiscountCalculator.py
│ │ ├── /events # Доменные события
│ │ │ ├── OrderPlaced.py
│ │ │ ├── OrderCancelled.py
│ │ ├── /repositories # Абстракция работы с БД
│ │ │ ├── OrderRepository.py
│ ├── /infrastructure # Взаимодействие с внешним миром
│ │ ├── /persistence # Реализация репозиториев
│ │ │ ├── OrderSQLRepository.py
│ │ ├── /messaging # Интеграция с брокерами событий
│ │ │ ├── KafkaPublisher.py
│ │ ├── /external # API-запросы к сторонним сервисам
│ │ │ ├── PaymentGateway.py
│ ├── /presentation # API-интерфейсы
│ │ ├── /http # REST API
│ │ │ ├── OrderController.py
│ │ ├── /cli # Консольные команды
│ │ │ ├── ImportOrders.py
│ │ ├── /events # Обработчики событий
│ │ │ ├── OrderPlacedListener.py
├── /customer # Контекст "Клиенты"
├── /billing # Контекст "Биллинг"
├── /shared # Общий код между контекстами
│ ├── /kernel # Базовые интерфейсы и абстракции
│ ├── /events # Кросс-доменные события
│ ├── /utils # Хелперы и вспомогательные классы
├── main.py # Точка входа
├── settings.py # Конфигурация
└── requirements.txt # Зависимости
🛠 Как применять DDD в реальной жизни?
1️⃣ Определить домены — выделить ограниченные контексты и не смешивать их.
2️⃣ Говорить на языке бизнеса — если в компании термин "Клиент", то в коде это тоже "Клиент", а не "UserEntity".
3️⃣ Разделить слои — доменная логика, инфраструктура и интерфейсы не должны жить в одном месте.
4️⃣ Использовать событийную модель — "Заказ создан" → "Биллинг должен выставить счёт" → "Система уведомлений отправляет письмо".
DDD звучит круто, но на практике далеко не всегда оправдывает затраты. Вот основные минусы и подводные камни:
❌ 1. Сложность внедрения
DDD требует глубокого понимания бизнес-процессов. Нужно не просто писать код, а строить архитектуру вокруг бизнеса. Если команда не готова, получится монструозная система с кучей ненужных сущностей.
❌ 2. Избыточность для простых проектов
Если ты делаешь небольшой CRUD-сервис, то DDD – это перебор. Ограниченные контексты, доменные события и инфраструктурные слои только усложнят жизнь.
❌ 3. Высокий порог вхождения
Разработчикам, привыкшим к классическим архитектурам, будет больно. Код становится менее очевидным, а навигация требует знания всех контекстов.
❌ 4. Усложнение коммуникации
Если разделить систему неправильно, то контексты будут постоянно взаимодействовать друг с другом, создавая чрезмерную связанность. В итоге бизнес-логика снова расползётся, а команда утонет в согласованиях.
❌ 5. Зависимость от качества модели
Если на старте неправильно выделить домены, то всё пойдёт по наклонной. Переосмыслить архитектуру на поздних этапах очень дорого.
❌ 6. Замедление старта проекта
DDD требует времени на проектирование, а в реальном мире бизнесу нужны фичи вчера. В стартапах, где важна скорость, проще начать с простого решения, а DDD внедрять постепенно.
🎯 Когда DDD НЕ нужен?
❌ Если проект маленький (обычный CRUD)
❌ Если бизнес ещё сам не понял, как он работает
❌ Если команда не готова поддерживать сложную архитектуру
❌ Если продукту нужно быстро выйти на рынок
✅ Когда DDD полезен?
✔ Если система сложная, с множеством бизнес-правил
✔ Если команда готова работать с доменной моделью
✔ Если кодовая база разрастается и становится неуправляемой
✔ Если модель данных и бизнес-процессы стабильно развиваются
🚀 Итог
DDD — это не просто красивая архитектура, а философия проектирования. Она даёт:
✅ Читаемость кода
✅ Независимость контекстов
✅ Чёткие границы между доменами
Но если всё сделать неправильно, DDD превращается в хаос. 😅 Поэтому главное — не усложнять без необходимости.
Если твой код уже похож на лапшу, возможно, время пересмотреть его структуру. 🏗
1️⃣ Определить домены — выделить ограниченные контексты и не смешивать их.
2️⃣ Говорить на языке бизнеса — если в компании термин "Клиент", то в коде это тоже "Клиент", а не "UserEntity".
3️⃣ Разделить слои — доменная логика, инфраструктура и интерфейсы не должны жить в одном месте.
4️⃣ Использовать событийную модель — "Заказ создан" → "Биллинг должен выставить счёт" → "Система уведомлений отправляет письмо".
DDD звучит круто, но на практике далеко не всегда оправдывает затраты. Вот основные минусы и подводные камни:
❌ 1. Сложность внедрения
DDD требует глубокого понимания бизнес-процессов. Нужно не просто писать код, а строить архитектуру вокруг бизнеса. Если команда не готова, получится монструозная система с кучей ненужных сущностей.
❌ 2. Избыточность для простых проектов
Если ты делаешь небольшой CRUD-сервис, то DDD – это перебор. Ограниченные контексты, доменные события и инфраструктурные слои только усложнят жизнь.
❌ 3. Высокий порог вхождения
Разработчикам, привыкшим к классическим архитектурам, будет больно. Код становится менее очевидным, а навигация требует знания всех контекстов.
❌ 4. Усложнение коммуникации
Если разделить систему неправильно, то контексты будут постоянно взаимодействовать друг с другом, создавая чрезмерную связанность. В итоге бизнес-логика снова расползётся, а команда утонет в согласованиях.
❌ 5. Зависимость от качества модели
Если на старте неправильно выделить домены, то всё пойдёт по наклонной. Переосмыслить архитектуру на поздних этапах очень дорого.
❌ 6. Замедление старта проекта
DDD требует времени на проектирование, а в реальном мире бизнесу нужны фичи вчера. В стартапах, где важна скорость, проще начать с простого решения, а DDD внедрять постепенно.
🎯 Когда DDD НЕ нужен?
❌ Если проект маленький (обычный CRUD)
❌ Если бизнес ещё сам не понял, как он работает
❌ Если команда не готова поддерживать сложную архитектуру
❌ Если продукту нужно быстро выйти на рынок
✅ Когда DDD полезен?
✔ Если система сложная, с множеством бизнес-правил
✔ Если команда готова работать с доменной моделью
✔ Если кодовая база разрастается и становится неуправляемой
✔ Если модель данных и бизнес-процессы стабильно развиваются
🚀 Итог
DDD — это не просто красивая архитектура, а философия проектирования. Она даёт:
✅ Читаемость кода
✅ Независимость контекстов
✅ Чёткие границы между доменами
Но если всё сделать неправильно, DDD превращается в хаос. 😅 Поэтому главное — не усложнять без необходимости.
Если твой код уже похож на лапшу, возможно, время пересмотреть его структуру. 🏗