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

Насколько популярные рейтинги соответствуют реальному спросу на рынке труда? Собрал данные о 150 000+ вакансий с hh.ru и других площадок. Результаты оказались неожиданными...

Привет, Хабр!

Сегодня я хочу поговорить о заимствованиях в Rust – теме, которая очевидно вводит многих в заблуждения но первых порах, но жизненно необходима для каждого, кто хочет писать на Rust. Мы с вами разберём, зачем Rust ввёл эту концепцию, как она работает под капотом, и какие нюансы следует знать, чтобы подружиться с borrow checker’ом, а не воевать с ним каждый раз при компиляции кода.

Команда Python for Devs подготовила практическое руководство по сборке полноценной RAG-системы из пяти open source-инструментов. MarkItDown, LangChain, ChromaDB, Ollama и Gradio превращают разрозненные документы в умную базу знаний с потоковой генерацией ответов. Всё локально, без облаков и с открытым кодом — попробуйте собрать свой ChatGPT прямо у себя.

Привет, Хабр. С гордостью, триумфом и трепетом хотим рассказать вам об одной из наших флагманских новинок, вышедшей в пылающем июле — книге «Экскурс в неопределённое поведение C++».

Cегодня книжные полки изобилуют нестареющими пособиями по C++. Этот язык чрезвычайно важен не только в разработке игр, финансового софта и встраиваемого ПО, но и как основной материал для изучения алгоритмов. Именно поэтому мы даже выпустили две книги-билингвы по алгоритмам, в которых код на C++ соседствует с идентичным ему кодом на Python. Это наш многолетний бестселлер «Алгоритмический тренинг. Решения практических задач на Python и C++» Максима Иванова и недавняя новинка «Базовые алгоритмы. Реализации на Python и C++ на примере классических игр» Павла Довгалюка. Но язык C++ не только очень полезен, но и опасен, так как на этапе преобразования исходного кода в машинный многие решения отдаются на откуп компилятору. Поскольку компилятор в большинстве режимов изначально заточен на оптимизацию кода, он регулярно привносит в код C++ непредсказуемые и порой необъяснимые варианты неопределённого поведения (UB, Undefined Behavior). Титаническую работу по систематизации неопределённого поведения в C++ проделал уважаемый Дмитрий Свиридкин @Nekrolm. В настоящее время он работает инженером по программированию встраиваемых систем в отделе Cloudfront Compute компании AWS. Дмитрий преподавал курсы по Linux и C++ в Санкт-Петербургском государственном университете и Высшей школе экономики, а также имеет богатейший послужной список, в котором есть и олимпиады по информатике, и машинное обучение, и программирование прошивок и, конечно же, выжимание последних капель производительности из самого неукротимого облачного железа. Некоторое время его заметки публиковались на сайте компании PVS-Studio, разрабатывающей известный российский статический анализатор кода. Далее под катом - предисловие Андрея Карпова, а также обзор самой книги.

Когда в 2019 году я начинал размышлять о проблемах обучения кодингу, нашим врагом номер один был «ад туториалов». Признаки попадания в этот ад:

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

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

• У вас имелось знание о многих технологиях на уровне флеш-карточек, но их внутреннее устройство было вам совершенно непонятно.

Студенты смотрели шестичасовые видео (или засыпали под них), параллельно писали код в своих редакторах, у них складывалось ощущение понимания, но они заходили в тупик, как только приходилось писать что-нибудь с нуля. Классический ад туториалов. Именно поэтому при создании своего ресурса для обучения кодингу я опирался на следующие три принципа:

• Глубокий курс обучения. Основы CS нужно преподавать не только в традиционных учебных заведениях.

• Практическое освоение всего. Необходимо писать код; не только в проектах, но и интерактивно, в процессе изучения каждой концепции.

• Меньше видео, больше текста. Видео слишком легко потреблять бездумно.

Повторюсь, что в 2019 году ад туториалов был повсеместным. Многочасовые курсы на YouTube собирали миллионы просмотров. Однако сегодня те же самые каналы с трудом набирают по пятьдесят тысяч просмотров нового контента. Посмотрите на FreeCodeCamp, Traversy Media и Web Dev Simplified. Я не пытаюсь бросить тень на эти каналы, они помогли куче людей, но их показатели сейчас именно таковы.

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

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

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

Привет! Меня зовут Бромбин Андрей. В этой статье мы рассмотрим порождающие паттерны ООП. Обсудим, что такое хороший дизайн и почему не стоит начинать всё с нуля каждый раз, когда перед нами новая задача. Также разберёмся, где эти паттерны действительно помогают и какую пользу несут — всё это с наглядными примерами на 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] Пол Грэм писал:

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

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

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