В быстро меняющемся мире веб-разработки постоянно появляются новые технологии и подходы к созданию системы обмена данными между приложением или сервисом. Одной из таких технологий, позволяющей запрашивать только необходимые данные, является GraphQL. Меня зовут Дмитрий и я python-разработчик. В этом материале я дам сравнительный обзор на REST и GraphQL.

Один из наиболее популярных примеров использования GraphQL — это применение в социальных сетях, где множество пользователей связаны между собой определёнными отношениями. К GraphQL мы прибегаем, когда нам требуется избирательно получить много данных о них. Такая организация пользователей имеет сетевую модель и представляется в виде графа, отсюда и связь с названием GraphQL (Graph — граф, QL — язык запросов).

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

Как превратить текст «Сколько было продано камер в прошлом месяце?» в осмысленный SQL‑запрос? Это и есть задача text‑to‑SQL (ее ещё называют NL2SQL). Для многих компаний сейчас очень важна возможность задавать вопросы к данным обычным языком, без изучения SQL. Для этой задачи написаны десятки инструментов, но суть одна — генерация корректного запроса из фразы на человеческом языке.

Требование проясняется примером: бизнес‑пользователь хочет узнать: «Какие топ-5 товаров по выручке за вчерашний день?» — а система превращает это в SELECT product, SUM(revenue) ... LIMIT 5 и выдаёт результат. До недавнего времени требовались сложные пайплайны или ручное кодирование, а сейчас на сцене — большие языковые модели (LLM) и всякие прокачанные методы достучаться до них.

В этой статье мы пробежимся по ретро‑ и ультрасовременным подходам к text‑to‑SQL. Плюс обзору добавим практических инсайтов.

Меня изрядно забросали помидорами в первой части этой статьи. Поэтому сегодня не будем об “ошибках”. Давайте просто посмотрим, что ещё “болит” у айтишников в английском, и как можно эти боли “вылечить”.

Английский язык можно учить бесконечно. Многие занимаются им около 10 лет в школе, а затем сдают зачеты в вузе, но все равно чувствуют себя с нейтивами неуверенно. Дело в том, что в современном мире традиционные подходы к изучению прикладных наук давно устарели. Давно известно, что лучше всего запоминается то, что можешь пережить сам (хотя бы виртуально), а от простого прочтения теории остается в памяти дай бог 10%.

В целом, практически любая видеоигра может помочь подтянуть английский. Даже в какой-нибудь Diablo можно разучить общеупотребительные слова: наводишь на изображение щита в инвентаре, видишь «Buckler» и сразу понимаешь без перевода. А если взять игру с сильным нарративом...

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

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

Привет! Это эксперты курсов английского в Практикуме. Возможно, вы замечали, что в начале изучения английского прогресс гораздо более явный: с каждым уроком становится больше знакомых слов, понятнее тексты и диалоги. Но со временем развитие замедляется.

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

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

Как-то раз я допустил в своем коде дедлок и пока выкатывал пул реквест с его фиксом думал “ах как бы было хорошо, если дедлоки определялись на этапе компиляции”. Я решил немного разобраться в этом вопросе и вот что выяснил…

За последние два года Go-сообщество выросло на 55% — с 3 млн до 4,7 млн разработчиков. Многие пришли в Go из других языков или только начинают свой путь в программировании. Без понимания идиоматики и ключевых особенностей языка даже опытные специалисты нередко сталкиваются с медленным кодом, дедлоками и утечками памяти.

Так что сегодня разберём, как организовывать пакеты, обрабатывать ошибки, безопасно работать с горутинами и каналами, оптимизировать аллокации и профилировать «горячие» участки через pprof. Советы одинаково пригодятся и опытным Golang-разработчикам, и тем, кто только начинает свой путь в Go.

Разберемся с сигналами от ОС, поработаем с таймаутами и контекстом в нашем HTTP сервере и шаг за шагом сделаем Graceful Shutdown в Go приложении.

Всем привет! Меня зовут Илья Криволапов, тружусь системным аналитиком в SENSE на проекте одного из цветных банков РФ. В профессии я уже пятый год и, несмотря на фамилию, ломал прод всего лишь несколько незначительных раз (надеюсь). 

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

Всего в цикле будет 3 статьи. В первой поговорим о двух разных подходах масштабирования БД и о том, как лучше его делать и как лучше не делать (Никогда. Пожалуйста). 

Кому будет полезно? Всем отвечающим за «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам. 

Согласны? Узнали? Тогда поехали!

Современные AI ограничены контекстом и страдают галлюцинациями при работе со сложными темами. NotebookLM обходит эти проблемы, обрабатывая 25 млн слов из ваших источников и предлагая уникальные инструменты для ускоренного обучения.

Поймите, как осваивать любые области в 10 раз быстрее и без выдумок.

Конечно, для многих настоящее общение куда интереснее, чем общаться с «глупым» роботом. Но это всё ещё вопрос времени, кажется, совсем скоро они будут общаться на таком уровне, что мы будем забывать о том, что это робот. В этой статье поделюсь своим опытом замены репетитора нейросетью ChatGPT: как пользуюсь и так далее.

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

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

Я решил, что хватит терпеть это, и вдохновился простотой стандартного пакета flag, где каждая опция — это буквально одна строка кода. Представьте: больше никакой беготни по структурам и файлам! В zerocfg вы объявляете опцию, дефолтное значение и документацию в одной строке — лаконично, понятно, надёжно.

Карты (maps) в Go — это отличный инструмент для хранения данных в виде пар «ключ — значение». Они широко используются в разработке благодаря своей гибкости и удобству. Например, карты часто применяются для кэширования данных, хранения конфигураций или обработки больших объемов информации. Однако эффективная работа с картами требует понимания их внутреннего устройства и особенностей управления памятью. Под капотом карты реализованы на основе хеш-таблиц, что обеспечивает быстрый доступ к данным, но также создает потенциальные проблемы, такие как неэффективное использование памяти или утечки. В этой статье мы разберем устройство карт в Go, рассмотрим, как они растут и работают, а также обсудим способы оптимизации их использования. Особое внимание уделено проблемам, связанным с инициализацией карт и управлением памяти, чтобы помочь вам писать более эффективный и надежный код.

Golang — приключение не на 20 минут, а игра вдолгую. Подтвердили это, собрав в офисе Lamoda спикеров Lamoda Tech, а также 2ГИС и МТС. Помимо новых докладов, разблокировали экспериментальный формат факап-разгонов, где наши друзья из ВИ.Tech, Orion soft и Cloud.ru вместе со зрителями делились историями провалов. Публикуем материалы с этой встречи.

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

Далее предлагаем вашему вниманию перевод оригинальной статьи “How Many Indexes Is Too Many?”, который подготовила специалист «Автомакона». В статье детально рассматривается данная проблема и приводятся практические рекомендации по выбору подходящего количества индексов для повышения производительности.

Для начала давайте рассмотрим простой эксперимент. Возьмем популярную базу данных Stack Overflow любого размера, уберем все индексы из таблицы Users и запустим удаление одной строки командой DELETE.

Расскажу про свой опыт конфигурирования приложений, разобрав некоторые популярные библиотеки и примеры.

В первой части статьи мы рассмотрели, как можно вручную ускорить Go-код с помощью векторизации и SIMD-инструкций, реализованных через Go-ассемблер. Написали простую, но показательно быструю реализацию sliceContains и увидели, что даже базовая векторизация может дать ускорение в 10–14 раз по сравнению со стандартной реализацией.

Во второй части статьи погрузились в практическое применение SIMD в Go-ассемблере, реализовали функцию SliceContainsV1 и изучили, как с помощью VADD, VDUP и других инструкций можно добиться 10–14-кратного ускорения простых задач.

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

Привет, Хабр! Меня зовут Игорь Панасюк, я работаю в Яндекс, преподаю в ИТМО, а также в свободное время выступаю на конференциях, делюсь опытом в соцсетях и помогаю развитию Go-сообщества, веду телеграм-канал и youtube-канал. Если вы уже знакомы с базовыми техниками векторизации, эта часть поможет глубже понять, как устроены продвинутые способы ускорения Go-кода и на что стоит обратить внимание при работе с архитектурно-зависимыми оптимизациями.

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

## Парадигма и инструменты языка

Я несколько раз встречал мнение, что го не ООП-язык. И поэтому прежде всего договоримся о том, что такое ООП.

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

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