😮 SQL: от Тетриса до ИИ — неожиданные возможности языка баз данных

Долгое время SQL использовали лишь для запросов и изменения записей в базах данных — для полноценного программирования в привычном смысле слова он не подходил. Однако добавление рекурсивных общих табличных выражений (CTE) сделало SQL полным по Тьюрингу.

Благодаря CTE на SQL можно при желании реализовать любой алгоритм. Несколько месяцев назад коллекция SQL-проектов пополнилась еще одной интересной разработкой — версией «Тетриса».

Эта реализация демонстрирует несколько нестандартных SQL-техник, о которых стоит знать, даже если вы используете SQL только по прямому назначению:

— игровой цикл;
— вывод игры;
— пользовательский ввод;
— решение проблемы изоляции данных;
— предотвращение кэширования.

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

🔗 Подробнее читайте в статье
🔗 Зеркало

🤔 Кто-то из вас помнит Xenix?

Да, Microsoft пыталась сделать Unix в свое время. Билл Гейтс даже говорил об этом в журнале Unix World (~1985 год). Но потом они все такие:

Нет, забудьте Unix, мы сделаем Windows NT!

Что имеем сейчас? Microsoft всё-таки сделала большой шаг в сторону открытого исходного кода. Посмотрим, что будет дальше…

🍊 Подборка лучших статей «Библиотеки программиста» за декабрь: сохраняй в заметки, чтобы не пропустить #самыйсок

➡️ Статьи:
💻📈 Итоги года Proglib: 2024 год в цифрах и достижениях
📊 Построение DWH и разработка дашбордов в Power BI: 5 проблем и их решение
💾 CDC vs Outbox: как решить проблему двойной записи в распределенной системе
🌐 Как работает GraphQL и чем он лучше RESTful API
🐛🔍 Как найти баг в 2088 коммитах с помощью git bisect

➡️ Тесты:
🦑👨💻 Программист в «Игре в кальмара»: каковы шансы выжить?
🤔🔥🪦 Беспощадный Frontend-тест: уволься сам, если не наберёшь 7 из 10!
👑🧟 Король спама: насколько сильно ты бесишь коллег в рабочих чатах
🐍 Насколько ты продвинутый питонист?

🤖 Напоминаем, что у нас есть еженедельная email-рассылка, посвященная последним новостям и тенденциям в мире искусственного интеллекта.

В ней:
● Новости о прорывных исследованиях в области машинного обучения и нейросетей
● Материалы о применении ИИ в разных сферах
● Статьи об этических аспектах развития технологий
● Подборки лучших онлайн-курсов и лекций по машинному обучению
● Обзоры инструментов и библиотек для разработки нейронных сетей
● Ссылки на репозитории с открытым исходным кодом ИИ-проектов
● Фильмы, сериалы и книги

👉Подписаться👈

😴 Писать код по ночам и в выходные — это нормально

Не все разделяют мнение о том, что кодить по ночам и выходным — это ок. Но для автора разработка — любимое хобби и работа.

🎯 Когда это становится проблемой?

1️⃣ Когда это превращается в культ.
2️⃣ Когда мы ожидаем того же от других.
3️⃣ Другие ожидают этого от нас.

🎯 Признаки, что пора остановиться:

• Ухудшение качества сна.
• Потеря социальных связей.
• Рост уровня стресса.
• Невозможность отвлечься от работы даже в личное время.

🎯 Как найти баланс?

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

• Слушайте свои ритмы. Иногда разработка приносит радость, а иногда — усталость. Прислушивайтесь к себе.

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

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

👉 Читать статью полностью

🚀 Визуальный гайд по масштабируемости архитектуры

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

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

📌 Три основные проблемы масштабируемости:

1️⃣ Централизованные компоненты могут стать единой точкой отказа.
2️⃣ Компоненты с высокой задержкой — компоненты, которые выполняют трудоемкие операции.
3️⃣ Тесная связь компонентов усложняет масштабирование системы.

📌 Популярные методы повышения масштабируемости:

• Балансировка нагрузки: распределение запросов между несколькими серверами, чтобы избежать перегрузки одного сервера.
• Кэширование: хранение наиболее запрашиваемой информации в памяти.
• Обработка событий (Event-Driven Processing): асинхронная обработка для выполнения долгосрочных задач.
• Шардинг (Sharding): разделение большого набора данных на более мелкие части (шарды) для горизонтального масштабирования.

👉 Источник

#инфографика

🧑‍💻 Статьи для IT: как объяснять и распространять значимые идеи

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

Что: семь модулей, посвященных написанию, редактированию, иллюстрированию и распространению публикаций.

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

👉Материалы регулярно дополняются, обновляются и корректируются. А еще мы отвечаем на все учебные вопросы в комментариях курса.

🤦‍♂️ Ошибки, которые разработчики допускают в больших устоявшихся кодовых базах

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

Так что такое «большие устоявшиеся кодовые базы»? По мнению автора статьи, это:

— Десятки миллионов строк кода (скажем, ~5M).
— От 100 до 1000 инженеров работают над одной и той же кодовой базой.
— Первой рабочей версии кодовой базы не менее десяти лет.

Автор потратил десять лет на работу с этими кодовыми базами. Вот что он хотел бы знать с самого начала:

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