Программирование *

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

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

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

Привет! Меня зовут Бромбин Андрей. В этой статье мы рассмотрим порождающие паттерны ООП. Обсудим, что такое хороший дизайн и почему не стоит начинать всё с нуля каждый раз, когда перед нами новая задача. Также разберёмся, где эти паттерны действительно помогают и какую пользу несут — всё это с наглядными примерами на Java, приближёнными к реальным.

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

При работе с C или C++ необходимо в какой-то степени разбираться в неопределённом поведении (UB): что это такое, каковы его эффекты, и как о него не споткнуться. Для простоты картины я буду в этой статье рассказывать только о C, но всё изложенное здесь также применимо и к C++, если явно не указано иное.

Каждую секунду в дата-центры Cloudflare в 330 городах отправляется 84 миллиона HTTP-запросов. Из-за этого даже самые редкие из багов возникают достаточно часто. На самом деле, именно наши масштабы позволили нам недавно обнаружить в компиляторе Go на arm64 баг, вызывающий состояние гонки в генерируемом коде.

В этом посте мы расскажем о том, как впервые столкнулись с багом, исследовали его и докопались до его первопричины.

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

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

Когда в 19-летнем возрасте я покупал свой первый компьютер, то я очень сильно хотел купить БК-0010-01. Однако обстоятельства сложились так, что к моменту, когда у меня появилась необходимая сумма, в магазинах БК‑шек не осталось, и вообще ничего не осталось. На полке в «Электронике» лежало только невзрачное нечто с нарисованной клавиатурой и названием «ЛИК».

Давным-давно, когда с ездовым котом приключилась "записка шестая", а знания об аллокаторах и опыт их применения ограничивался линейным и системным, перебросили мою команду в помощь другой команде, которая занималась системами навигации больших судов. Ездовые коты, особенно нестарые - это такие создания, которые редко изучают документацию детально, а чаще бегло читают там про интерфейсы систем в проекте, malloc, new, системные аллокаторы и думают, что теперь-то точно понятно, как всё устроено. А потом приходит работа и такая: “Забудь всё, что ты знал. Ты не дочитал до страницы восемьсот что-то там РД, тут есть свой аллокатор - и он реально плохой”.

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

А вот почему нужны и важны ненормальные - объяснений почти нет, как и самих реализаций в открытом доступе. В этой статье я расскажу, какие повстречал ненормальные алгоритмы распределения памяти, чем они живут, кого едят, и почему иногда malloc делает вид, что он не при делах и таки да, malloc может возвращать null и ту проверку мы убрали зря.

В ноябре 2024 года я написал пост «Действительно ли Python такой медленный?», в котором протестировал множество версий Python и отметил стабильный прогресс производительности языка.

Сегодня девятое октября 2025 года, прошла всего пара дней после официального релиза Python 3.14. Давайте снова запустим бенчмарки, чтобы проверить, насколько быстра новая версия Python!

Примечание: если вам неинтересны таблицы и графики и вы хотите просто прочитать мои выводы, сразу переходите к концу статьи.

Привет, Хабр! Я Николай Видов, разработчик в команде чатботов. Я работал как в небольших компаниях, так и в тех, которые на слуху: EPAM, QIWI, Т-Банке. За время работы я часто сталкивался с понятием продуктовости: «Разработчики должны активно участвовать в бизнесе», «Разработчики должны предлагать улучшения для продукта», «Разработчики должны аргументированно спорить, если не согласны с предложенной функциональностью».

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

Продуктовый разработчик — это следующая ступень эволюции разработчика, который активно участвует в бизнес-процессах. © Никита Пастухов, мейнтейнер FastStream

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

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

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

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

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

Приятного чтения!

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

Всем привет! Меня зовут Вадим, я Data Scientist в компании Raft. В этой статье я расскажу о Chonkie — библиотеке для простого и быстрого чанкирования документов, а также на практике применю её и сравню с другими популярными решениями: LangChain и LlamaIndex.

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

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

История о том, как стремление человека управлять сложностью меняло сами основы программирования.

Перед тем как перейти непосредственно к языкам программирования, мне очень хочется осветить одно событие.

Итак, перенесёмся в далёкий 1843 год.

Когда отлаживаешь программу, речь идет про использование отладчика в студии или другой IDE, то почти всегда имеешь дело с точками останова (breakpoint, бряками) — механизмом, когда выполнение программы приостанавливается, чтобы можно было заглянуть внутрь и понять, что происходит. Точек останова есть всего два основных типа, программные и аппаратные, а остальные все сделаны на их основе. Эти два базовых типа могут вести себя похоже, но устроены по-разному.

Программные точки останова — это то, с чем сталкивается каждый разработчик, когда вы ставите красную точку в среде разработки (в основном я использую большую студию) или используете команду bp под WinDbg. В этом случае отладчик просто подменяет один байт машинного кода в нужной инструкции на команду int 3. Это специальная инструкция для вызова прерывания отладки (Debug Interrupt), имеет машинный код 0xCC и говорит процессору: “Остановись, я хочу передать управление отладчику”, соответственно когда выполнение доходит до этой инструкции, срабатывает прерывание, и управление передаётся в отладчик. Отладчик "просыпается" и видит, что программа остановилась из-за исключения EXCEPTION_BREAKPOINT , возникшего по конкретному адресу, проверяет свой внутренний список точек останова и находит ту, которая была установлена по этому адресу.

После COVID-19 наша культура труда в основном изменилась к лучшему, но были и негативные изменения, например, увеличение количества совещаний на 13,5%[1].

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

В своей знаменитой статье «Maker's Schedule, Manager’s Schedule» [2] Пол Грэм писал:

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

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

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

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

Мы в МойОфис любим Lua. И сами активно его используем: в наших редакторах с помощью Lua работают макросы и надстройки. И помогаем разработчикам лучше узнать этот язык — при нашей поддержке вышли уже два издания классного учебника по Lua от Роберту Иерузалимски (кстати, сам автор считает, что этот язык в части задач даже более хорош, чем Си!)

А летом 2025 года мы выпустили целый трёхтомник по Lua. Первый том — новое издание книги Роберту. Второй и третий — вышедшие впервые учебники от Дмитрия Шульгина, старшего тренера по продуктам Учебного центра МойОфис.

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

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

Прошло всего несколько лет и они действительно появились. Нейросети сегодня повсюду: на улицах улыбаются котята с рекламных баннеров, в социальных сетях бомбардировщик с головой крокодила собирает миллионы лайков. Для многих алгоритмы стали инструментами, которые помогают решать десятки задач. Но этих инструментов стало так много, что выбрать бывает непросто.

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

Да, у многих сервисов нашего топа есть платные подписки. Но сегодня будем разбирать только бесплатные возможности.

Приятного чтения!

Попробую на маленьком примере показать откуда берётся запутанный код.

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

Для упрощения написания маленькая буква будет означать что условие ложно, а большая — что истинно.

Представляем функцию в виде карты Карно, чтобы оптимизировать всё что можно:

Недавно мне понадобилось реализовать автоматическую генерацию QR для личного проекта. Идея простая: пользователь нажимает на кнопку «Пригласить друга», а небольшая функция на JavaScript закидывает в буфер обмена реферальную ссылку.

Все было бы хорошо, но нужно было добавить попап с QR-кодом, который при сканировании перекидывает по ранее полученной ссылке. И так как писать собственное решение было сомнительной идеей, пришлось использовать библиотеку — QRious. В этой статье расскажу, как с ней работать.