Привет. Предположим, вы захотели начать изучать языĸ программирования C++ или, возможно, тех материалов, что уже изучили, вам недостаточно.

Я — Савва, программирую уже больше 7 лет, работаю менеджером команды наставников в Практикуме на курсе «Разработчик С++», а с недавнего времени — разработчиком в Positive Technologies. В этой статье мы с вместе с Практикумом собрали леĸции, ĸниги, курсы и всяĸое таĸое, чтобы шансов выстрелить себе в ногу самостоятельно было меньше :) По C++ существуют и другие подборĸи, но, ĸ удивлению, на Хабре их всего две.

В документации по UIKit компании Apple можно найти объяснение, что “структура приложений основана на шаблоне проектирования Model-View-Controller (MVC)”.

В материалах Apple по SwiftUI объяснений и даже просто ссылок на паттерны проектирования, похоже, нет. Попробуем сначала разобраться почему. Далее рассмотрим логичные и простые решения для построения как отдельных компонентов, так и уровень приложения с использованием состояний и property wrappers; подход, который логично обозначить как State-Model-View.

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

Сегодня я хочу поговорить о двух правилах С++: правиле трех и правиле пяти.

Правильное понимание этих правил способно уберечь код от утечек и неопределенных поведений.

Привет! Вопрос мобильным разработчикам: часто ли вам приходится работать с необычным UI? Если вы ответили утвердительно, то я по-доброму вам завидую. В своей повседневной практике мне в основном приходится работать со стандартным набором компонентов и их базовой настройкой. Абсолютно ничего не имею против, но хочется чего-то «эдакого»: кастомных компонентов, написанных с нуля, необычных анимаций и эффектов. Часто подобные вещи вызывают много споров (как среди разработчиков, так и конечных пользователей) а-ля «А на кой оно вообще надо», но лично для меня это ни что иное, как творчество. Кто-то красиво рисует, кто-то красиво поёт, а кто-то пишет красивые уникальные приложения, которыми интересно и приятно пользоваться. И мы, пожалуй, не можем обвинять авторов за бессмысленность «украшательств», как по-хорошему не можем судить художника за его работу.

К чему я – спросите вы. Я отвечу: настраиваю на нужный лад :) В рамках этой статьи мы коснёмся полезной темы и создадим что-то бесполезное в практическом смысле, но несомненно интересное и достаточно уникальное.

Написать этот материал меня побудило... отсутствие хороших статей по корутинам в C++ в русскоязычном интернете, как бы странно это не звучало. Ну серьезно, C++20 существует уже несколько лет как, но до сих пор почти все статьи про корутины, что встречаются в рунете, относятся к одному из двух типов. Или обзор начинается с самых глубин и мелочей, пересказывая cppreference, а потом автор выдыхается и все сводится к "ну а дальше все понятно, возьмите и примените это в своем коде", что напоминает известную картинку с совой. Либо иногда в статьях рассматривается применение корутин на примере генераторов, и этим все и ограничивается. Но, давайте будем честны, генераторы — это замечательно, но за все время моей многолетней карьеры разработчика я, вероятно, делал что‑то подобное генераторам разве что разок, в то время как асинхронный ввод‑вывод приходится использовать почти в каждом проекте. И поэтому меня гораздо больше интересует реализация асинхронного ввода‑вывода с использованием корутин, а не генераторы. Поэтому пришлось разбираться во всем самому.

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

Так уж повелось, что любой уважающий себя работодатель перенимает передовые методики FAANG — по этой причине практически во всех IT-собесах есть она: секция алгоритмов. Кто-то ей рад, кто-то не очень, но секция есть и уходить пока не планирует. Поэтому нужно закатать рукава и достойно встретить суровую реальность.

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

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

Учить C++ в 2024 году по бесплатным курсам имеет несколько преимуществ. Вот несколько причин, почему это стоит делать:

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

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

3. Множество полезных библиотек: C++ предоставляет широкий набор инструментов и библиотек для разработки приложений.

4. Доступно множество полезных ресурсов: Язык C++ очень популярный, существует множество различных онлайн-ресурсов, форумов и сообществ, где можно получить помощь и поддержку от опытных разработчиков.

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

Давайте поговорим о целях. Слышали когда-нибудь о «кризисе сложности обнаружения маленьких веб-сайтов»? Проблема в том. что маленькие веб-сайты наподобие моего невозможно найти при помощи Google или любого другого поискового движка. Какова же моя миссия? Сделать эти крошечные веб-сайты снова великими. Я верю в возвращение славы этих малышей вдали от SEO-безумия Google.

В этом посте я подробно расскажу о процессе создания поискового движка с нуля на Python. Как обычно, весь написанный мной код можно найти в моём GitHub (репозиторий microsearch). Эта реализация не будет притворяться готовым к продакшену поисковым движком, это лишь полезный пример, демонстрирующий внутреннюю работу поискового движка.

Кроме того, мне стоит признаться, что в заголовке поста я слегка преувеличил. Да, поисковый движок действительно реализован примерно в 80 строках Python, но я ещё и писал вспомогательный код (краулер данных, API, HTML-шаблоны и так далее), из-за которого весь проект становится немного больше. Однако я считаю, что интересная часть проекта находится в поисковом движке, который состоит из менее чем 80 строк.

P.S. Написав этот пост и microsearch, я осознал, что пару лет назад нечто похожее написал Барт де Гёде. Моя реализация очень похожа на работу Барта, но я считаю что кое-что улучшил, в частности: (1) мой краулер асинхронный, что сильно ускоряет работу, (2) я реализовал пользовательский интерфейс, позволяющий взаимодействовать с поисковым движком.

Зачастую мне приходится слышать в подкастах или лицезреть в комментариях примерно такой диалог: "Я вашу айтишечку на балде вертел. Я сюда ради денег пришёл, которые в России ни в одной другой области не платят. Я вру на собесах об опыте, потому что работодатели точно так же врут соискателям об условиях работы, требования к джунам сениорские, а зарплата - нет"

Реализация защиты от сбоев из-за фрагментации кучи и повышение скорости выполнения с помощью STL-альтернативы std::allocator, работающей с блоками памяти фиксированного размера.

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

В этом посте я буду говорить о страничной организации только в контексте PML4 (Page Map Level 4), потому что на данный момент это доминирующая схема страничной организации x86_64 и, вероятно, останется таковой какое-то время.

Окружение

Это необязательно, но я рекомендую подготовить систему для отладки ядра Linux с QEMU + gdb. Если вы никогда этого не делали, то попробуйте такой репозиторий: easylkb (сам я им никогда не пользовался, но слышал о нём много хорошего), а если не хотите настраивать окружение самостоятельно, то подойдёт режим практики в любом из заданий по Kernel Security на pwn.college (вам нужно знать команды vm connect и vm debug).

Я рекомендую вам так поступить, потому что считаю, что самостоятельное выполнение команд вместе со мной и возможность просмотра страниц (page walk) на основании увиденного в gdb — хорошая проверка понимания.

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

Что мне больше всего нравится в gamedev, так это что большая часть игр и каждый первый кастомный игровой движок бросают вызов устоявшимися стереотипам разработки. Иначе зачем начинать разработку такого сложного и комплексного софта, когда десятки похожих софтин есть вокруг. Конечно такие монстры как Unreal и Unity и десяток монстриков калибром поменьше существенно упростили разработку во многих отношениях, привлекли тысячи разработчиков к созданию множества великолепных игр с использованием готовых технологий, освободив их от ямы отчаяния пустого уровня. Но также не оставляет мысль, что еще больше игр они похоронили. Невзирая на весь функционал и мощь U/U люди часто застревают в рамках, о которых они даже не подозревали. На протяжении многих лет наблюдаю как оригинальный контент в большинстве случаев убивается ассетсторами, если там есть что-то близкое или похожее к нужному объекту, функционалу и виду. Не поймите мои слова неправильно, я обеими руками за магазины ассетов и любых других ресурсов, скриптов и технологий, но беря что-то в магазине за доллар, вы уже с большой вероятностью не сделаете свое. Или сделаете конечно, но позже, но до этого "позже" еще надо дожить, а пока что у вас будет всё как у всех: одинаковые паттерны, одинаковые текстуры, одинаковое поведение, одинаковые модели... и одинаковые игры? Что тогда остается своего - уникальные механики и впечатления. В другом случае не было бы игры, вот только проблема, что сначала люди видят картинку. Хорошо если игрок через полчаса-час доберется до уникальных механик, одинаковая картинка вызывает в памяти игры в которые вы уже играли, а уникальная механика так никогда может быть и не увидена в игре.

Сегодня ровно 20 лет, как я начал программировать профессионально. За эти годы я:

• Получил одобрение на петицию по грин‑карте за выдающиеся способности в науке.
• Стал Google Developer Expert.
• Стал IEEE Senior Member.
• Был операционным директором в компании со 100 сотрудниками.
• Написал код, который скачали 135 миллионов раз.
• Выступал перед аудиторией в 2000 человек, дважды.
• Стал самым честным человеком в России по версии НТВ.

Но упустил я гораздо больше и делал всё это слишком долго. Думаю, этот путь можно было бы пройти «на скорость» лет за 5 с теми подходами, принципами и приоритетами, которым я научился. Если вы только начинаете свой путь, этот текст может сэкономить вам 15 лет жизни.

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

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

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

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

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