Недавно мне для личных целей понадобилось написать читалку FB2. И сразу я столкнулась с тем, что информации по теме минимум. Палочка-выручалочка под названием ChatGPT выдал что-то невразумительное в ответ на довольно подробный запрос. К тому же, никаких готовых библиотек, чтобы по-быстренькому наваять ридер, я также не смогла обнаружить. Хотя искала долго и упорно, как Чубакка расческу.

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

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

Существует огромное множество статей про оптимизацию загрузки веб-сайтов, но часто они обходятся лишь общими советами или абстрактными примерами. В этой статье я хочу поделиться своим опытом комплексной оптимизации реального проекта с конкретными примерами, в данном случае SPA, написанном на Vue 3 с использованием Vuetify для части UI компонентов и Firebase для авторизации.

Немного контекста: я работаю frontend-разработчиком в компании, которая в основном занимается разработкой MVP (Minimum Viable Product), но так же и разработкой и поддержкой долгоживущих продуктов. Как раз у MVP бывает много проблем, потому что минимум времени уделяется под рефакторинг и оптимизацию, а проблемы между проектами повторяются, потому что часто используется один стартовый шаблон.

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

Занимался обёрткой для OpenAI для Делфи и вдобавок сделал клиент.

Прошу заранее прощения, я хотел сделать пост нового типа, но с телефона не увидел, как это можно сделать.

Привет, меня зовут Владимир и у меня есть кое-что что надо обсудить, но сначала позвольте мне быстро рассказать как все это началось.

Я познакомился с понятием “архитектурные паттерны” и MVC в частности еще в 2012, и с тех пор заболел идеей архитектур программного обеспечения. Я восхищался людьми, которые пишут архитектурные фреймворки. Я тратил дни и недели читая их исходники и просматривая видео на YouTube. Но чем больше я в это погружался, тем больше я чувствовал себя в состоянии, которое я называю “начинающий иллюзионист”: пока смотришь на фокусы - это магия, но когда начинаешь их делать, то они становятся банальными.

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

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

В своих скитаниях я нашел кое-что не менее интересное: причину почему MVx всегда получается плохо. И вот об этом и пойдет речь сегодня.

GraphQL — это язык запросов с открытым исходным кодом, созданный Facebook в качестве альтернативы распространенной архитектуре REST. Он позволяет пользователям запрашивать конкретные данные и таким образом избежать классической проблемы избыточности данных в ответах, связанной с REST.

В этой статье мы рассмотрим Spring для GraphQL, преемника проекта GraphQL Java Spring от команды GraphQL Java.

Цикл статей с вопросами по Kotlin, которые могут задать на собеседованиях.

Вопросы и ответы для собеседования по Kotlin. Часть 1
Вопросы и ответы для собеседования по Kotlin. Часть 2 
Вопросы и ответы для собеседования по Kotlin. Часть 3 — вы находитесь здесь
Вопросы и ответы для собеседования по Kotlin. Часть 4 (скоро)

Как многие разработчики, я прекрасно понимаю, насколько важно создавать приложения, которые будет легко поддерживать, расширять и развивать в долгосрочной перспективе. Именно поэтому принципы Clean Architecture (Чистая архитектура) стали неотъемлемой частью моей работы. В этой статье я расскажу о том, почему следование принципам Clean Architecture так важно и какие преимущества эти принципы могут дать.

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

Статья написана по мотивам ИТ-посиделки, где мы обменивались полезными лайфхаками. Все команды, которые успели обсудить, мы разделили на две части. В первой поговорим про запросы общей информации о пользователях и системе, работу с файлами, процессами и текстом. Во второй части - о bash и работе с сетью, в частности ssh.

Сначала я хотел назвать эту заметку «Редактор связей? Это очень просто». Именно так называл свои прекрасные книжки Евгений Айсберг: «Радио? Это очень просто!», «Телевидение? Это очень просто!» Но поскольку я уже использовал эту шутку в статье о планировщике Windows, чтобы не повторяться, теперь использую любимую формулу многих журналистов: «Вся правда о…».

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

Другое дело я, который сопровождает и даже по мере сил развивает средства программирования. Приходится разбираться и с работой редактора связей, а, значит, как говорится, мне и карты в руки. Попробую кратко и на пальцах объяснить назначение и работу этого программного инструмента. И не просто объяснить, а привести примеры из конкретной реализации. Иначе абстрактные рассуждения плохо воспринимаются. Сам не люблю лекторов, которым кажется, что им достаточно поводить пальцем в воздухе, чтобы аудитория все поняла с полуслова. Так не бывает.

Инженеры Apple придумали прекрасные по быстродействию и производительности процессоры Apple Silicon (M1, M1 Max и так далее) на архитектуре arm64. Но за полученное быстродействие разработчикам пришлось платить своим временем.  

Рассказываем, к каким проблемам мог привести апгрейд рабочего мака и что нужно учитывать с изобретением процессоров Apple Silicon.

Статья вдохновлена ограничениями в недавно вышедшем Xcode 14.3: запуск из-под Rosetta в нём стал deprecated.

Привет, Хабр! На связи Сергей, iOS-разработчик в компании SimbirSoft.

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

Интеграция Combine в проект будет полезна для обеих сторон — бизнеса и команды разработки:

1. Процесс работы становится быстрее, а значит дешевле.

2. Фреймворк считается достаточно модным. Есть большое количество разработчиков, которым нравится использовать реактивный подход, и которые хотят поработать с новым инструментом — повышается интерес соискателей к вакансиям, в которых фигурирует эта технология.

3. Combine способствует легкой поддержке и удобном переходе на современные технологии в будущем (например, на SwiftUI).

С годами подходы к обработке конкурентности в ядре Linux сильно изменились. К 2023 году в арсенале разработчиков ядра появились, в частности, автозавершения, хорошо оптимизированные мьютексы, а также россыпь неблокирующих алгоритмов. Но были времена, когда управление конкурентностью сводилось к использованию обычных семафоров. Дискуссия о внесении небольшого изменения в API семафоров лишний раз свидетельствует, как сильно они изменились за долгую историю ядра.

Всем привет! Это создатель игры Dev's Battle (Образовательной MMO-RPG игры для разработчиков в Телеграмм). В этой статье я решил рассказать про наш опыт использования телеграма, как платформы для создания игры, а также обсудить с другими разработчиками плюсы и минусы этой концепции.

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

В последнее время набирают популярность low-code и no-code платформы. В них для разработки приложений предлагается использовать визуальное программирование. При таком подходе, разработчики, в качестве которых выступают обычные бизнес-пользователи, вместо написания программного кода создают приложение при помощи мыши в графическом интерфейсе. Также визуальное программирование в некотором виде используется, например, в Конфигураторе 1С.

Однако, возникает вопрос. Какие преимущества дает визуальное программирование по сравнению с Domain Specific Language ? Безусловно это зависит области применения. С одной стороны, в классических языках визуальное программирование практически не используется. В то же время при разработке графического интерфейса такой подход конечно же имеет много преимуществ. Однако, при создании интерфейсов, например, с помощью популярной библиотеки React все-таки больше используется плоский код.

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

Так как же объяснить концепцию «плохого кода» обывателю?

Дурная голова рукам покоя не даёт… история началась несколько месяцев назад: я увидел в интернете забавное видео игры в комнате с пиксельным светодиодным полом и решил сделать подобное для своих детей. За эти месяцы я получил массу удовольствия от процесса разработки и даже заразился идеей масштабирования проекта, но обо всём по порядку! Внимание, ниже будет много фото! А в конце статьи есть видео работы.

В современных веб-приложениях асинхронные операции играют ключевую роль. Однако управление ими может быть сложным, особенно когда нужно отменить задачи, уже отправленные на выполнение. До появления AbortController разработчики прибегали к различным костылям, таким как создание глобальных переменных, которые отслеживали состояние запроса или использование оберток над XMLHttpRequest.

Мне понадобилось провести несколько вводных уроков по языку программирования C++. В интернете есть много разнообразных учебных пособий для начинающих. Но почти во всех из них символьные и строковые литералы в примерах и упражнениях даются на английском языке, начиная со знаменитой первой программы «Hello, world!».

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

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