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

Привет, Хабр. С гордостью, триумфом и трепетом хотим рассказать вам об одной из наших флагманских новинок, вышедшей в пылающем июле — книге «Экскурс в неопределённое поведение 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 и ту проверку мы убрали зря.

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

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

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

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

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

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

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

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

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

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

Всем интересующимся — добро пожаловать под кат!

Да, это очередная статья по чистому коду. Но по разным источникам, соотношение времени, затрачиваемого на чтение и написание кода, может достигать 7 к 1 и даже больше. Когда вы исправляете ошибку, добавляете новую функциональность или проводите рефакторинг, вы сначала погружаетесь в логику, написанную другими людьми (или вами же, но несколько месяцев назад). Именно поэтому читаемость кода становится более важным фактором, чем скорость его первоначального написания. Нечитаемый код — это технический долг, который замедляет всю команду и увеличивает стоимость разработки в долгосрочной перспективе.

Я раньше работал обычным безопасником. Кто-то называет таких «ИБшниками», кто-то — «параноиками», кто-то — «тем самым занудой, который мешает жить».
Каждый день у меня был один и тот же диалог:

• Тимлид: «У нас релиз в пятницу, отстань со своим сканированием».
• Менеджер: «В бюджете только Jira и пицца, какие ещё 15 миллионов за софт?»
• Разработчик: «Код сгенерил AI, билд прошёл, значит, всё норм».

Привет, Хабр! Я — Ксюша, младший специалист по ИБ в Selectel. 22 сентября 2012 года в России появилась первая программа багбаунти. Сегодня в индустрии уже работают несколько отечественных платформ, которые объединяют тысячи исследователей и десятки компаний. С каждым годом интерес к багбаунти увеличивается: все больше людей принимают в этом участие, а бизнес активнее разрабатывает собственные программы. Если впервые слышите об этих программах или хотите узнать, как они появились, вы обратились по адресу. В статье поделюсь историей возникновения и расскажу, как уже сегодня можно зарабатывать (и учиться) на чужих ошибках.

«Привет! Я разработчик. Для начала расскажу о своём важном для этой статьи опыте: я пишу код на Hoobijag, иногда на jabbernocks и, разумеется, на ABCDE++++ (но никогда — на ABCDE+/^+; вы что, шутите?); мне нравится работать с Shoobababoo и иногда с клептомитронами. Я устроился на работу в Компанию¹ и занимаюсь там кодом для Shoobaboo, поэтому перешёл к использованию Snarfus. Давайте разбираться!

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

В мире баз данных, где каждая миллисекунда на счету, а объемы информации растут как на дрожжах, выход PostgreSQL 18 стал настоящим подарком для разработчиков и администраторов. Это не просто косметический апгрейд, а глубокая перестройка подкапотных механизмов, от облачных хранилищ до высоконагруженных OLAP-систем. Давайте разберемся, что там в этом релизе появилось и/или изменилось.

Занимаясь проектированием систем ПО, идите самым простым путём из возможных.

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

Многие инженеры, продумывая дизайн системы, представляют себе некий её «идеал»: что-то стройное, практически бесконечно масштабируемое, удобно распространяемое и так далее. Я же считаю, что это абсолютно ошибочный подход к проектированию ПО. Напротив, нужно вложить всё это время в глубокий анализ имеющейся системы, а затем реализовать простейшее рабочее решение.

Привет, Хабр! Меня зовут Алексей Николаевский, и мы с командой делаем СУБД Яндекса. С 2013 года в Яндексе использовали Kafka для потоковой передачи данных. Но Kafka со временем перестала справляться с растущими объёмами, и в 2017 году мы перешли на своё решение.

Брокер сообщений YDB Topics во многом вдохновлялся Kafka: в нём также есть топики, партиции и аналогичные способы работы с данными. Но есть и существенные отличия, о которых в конце прошлого года я рассказал на московской конференции HighLoad. Под катом — адаптированная для Хабра статья по мотивам этого доклада: про архитектуру транзакций в обеих системах и интересные для разработчиков детали и нюансы, которые мы обсуждали на конференции.