Когда мидл-разработчик дорастает до сениора, его, как правило, мучает вопрос: как правильно писать приложение? Понятно, что когда он был джуном, ему давали совсем атомарные задачи, и он развлекался покрытием тестов или написанием контроллеров. Переход в мидлы знаменуется назначением на разработчика более абстрактных задач вроде реализации сервисов, репозиторной части или интеграции с внешними сервисами посредством клиентов. Но в какой-то момент мидл начинает задавать самому себе вопросы: как найти единственно правильный способ написать приложение с нуля?
Если Вы - мидл, и Вас стали мучать такие вопросы — поздравляю, Вы на верном пути. Ведь профессиональный рост не происходит с переводом на должность - новый сениор должен родиться, и это как раз муки такого рождения.
Да, мы уже знаем самые популярные практики: KISS, DRY, YAGNI, SOLID, что там ещё... Мы умеем их применять. Но нас не покидает чувство, что все эти практики объединяет общая научная основа. Знаете, это как с Менделеевым, который на основе закономерностей практически по наитию составил периодическую систему, а потом открыли электроны и всё встало на свои места.
У меня для вас хорошие новости: научная основа есть. Это предметно-ориентированное проектирование.
Но есть и плохая новость: тема настолько новая и непростая в изучении, что какая-никакая популярность к ней пришла лет 5 назад, и до сих пор совсем небольшое число разработчиков достаточно хорошо в ней разбирается.
Но есть ещё одна хорошая новость: в статье ниже я постараюсь дать максимально понятный ответ, что же такое предметно-ориентированное проектирование.
Начнём.
После приобретения умных часов Fenix 5 plus и дальнейшего погружения в эту среду, я обнаружил непреодолимое желание их модернизировать.
Здравствуйте, друзья! Меня зовут Константин, я python backend developer из компании «Окенит». Сегодня я хочу рассказать свое видение проблемы новичка при ознакомлении с принципами SOLID, описанными в книге «Стерильная Архитектура» Робина Мартерта.
За свой десятилетний опыт я часто был свидетелем ситуации, когда молодые разработчики, желая сделать свой проект как можно более открытым для расширения и редактирования, превращали его в груду нечитаемого и неподдерживаемого кода при попытке использовать у себя все рекомендации Матушки Роба. Отсюда вопрос: «Почему, при следовании советам более опытного разработчика, код стал только хуже?».
Ответ на этот вопрос пришел ко мне очень быстро. Из‑за описания и без того абстрактных вещей чересчур абстрактными словами и примерами, Робин Мартерта вместо упорядочивания знаний, наводит хаос в умы читателей. Во избежание этой ситуации я решил написать данную статью, где коротко расскажу о наборе принципов SOLID, для чего они нужны и, главное, как применять эти принципы в жизни. Начнем по порядку, с буквы «S». И так, что же она значит?
Мы постоянно окружены огромным количеством электроники. Эти маленькие платы с электронными мозгами есть практически везде. Некоторые из них даже подключены к интернету шпионят за нами. Но как они создаются?
Эта статья для тех, кто не имеет опыта разработки электроники, но хочет получить представление о процессе.
В этом видео мы с нуля разработаем и изготовим несложное электронное устройство. А все исходники и данные, для самостоятельной сборки, традиционно в описании.
Иногда все, что требуется — быстро вывести какой‑то текст в Renderpass. Традиционно отрисовка текста требует отрендерить все возможные символы шрифта в атлас, затем привязать полученный атлас как текстуру и затем отрендерить каждый глиф, рисуя треугольники, каждый из которых должен соотноситься с нужным глифом из текстуры атласа шрифта.
Так делает imgui, равно как и все, кто использует stb_truetype. Сам процесс приятно напоминает процесс наборного производства на физических станках.
Причудливо, правильно, но в то же время напряжно.
Если нам нужно просто вывести какое‑то сообщение для дебага? Нет ли какого‑либо более простого метода?
В данной статье я опишу метод бестекстурной отрисовки дебаг‑текста. Вдобавок, отрисовка будет производиться в один вызов draw.
Мы никогда не читаем код как книгу — мы выбираем только конкретные интересующие места. Такие места обычно запоминаются ассоциативно, например по имени функции, строковому литералу, импорту библиотеки, комментарию и т. д. Перейти от ассоциации к файлу, а тем более к конкретной строчке кода не всегда легко. Особенно если оперируешь большим количеством проектов с активно меняющейся кодовой базой. В таких случаях выручает удобный инструмент текстового поиска.
Эффективность такого инструмента определяется как скоростью работы, так и удобством использования. В частности, кастомизация под себя позволяет разгрузить мышление и включить «мышечную память» — когда руки сами нажимают кнопки, а все внимание сосредоточено на обработке результатов поиска. Не все инструменты позволяют провести такую тонкую настройку. Меня зовут Роман Щекин, я работаю руководителем команды разработчиков в VK Cloud, и в этой статье мы с вами поищем серебряную пулю, попробуем достичь сочетания скорости и удобства в виде собранного из кросс-платформенного опенсорса поисковика.
Всем привет! Меня зовут Александр, я фронтенд‑разработчик в KTS.
Не так давно я уже рассказывал про Strapi — одно из ведущих опенсорсных headless CMS‑решений, которое на протяжении долгого времени пользуется большой популярностью у разработчиков. Чуть больше месяца назад разработчики системы представили обновленную версию, и в этой статье я расскажу о фишках, которые появились в Strapi 5.
Неважно, переходите вы на Strapi 5 с предыдущей версии или только начинаете знакомиться с технологией — понимание нововведений в любом случае пойдет вам на пользу, поскольку без них вы не сможете полностью раскрыть потенциал актуальной версии. В этой статье перечислены 10 нововведений в Strapi, о которых вам стоит знать.
unsafe код на Rust. Но я этого не делал, поэтому решил, что будет полезным задокументировать свой опыт максимально подробно. Так что предлагаю сразу перейти к делу.
Я обычно не люблю затрагивать общие вопросы, но на работе недавно столкнулся с очень специфичной ситуацией, которой хочу поделиться с вами. Касается она нового человека, которого в 2024 наняли свеженьким, из колледжа.
И тут понеслась... Такого я себе даже в страшном бреду представить не мог.
Как-то я исследовал способы наиболее эффективного определения простоты числа и наткнулся на показанный выше код.
Он меня заинтриговал. Хоть это, возможно, и не самый эффективный способ, но определённо один из наименее очевидных, поэтому мне стало любопытно. Каким образом соответствие регулярному выражению .?|(..+?)\1+ должно показать, что число непростое (после его преобразования в унарную систему счисления)?
Если вы заинтересовались, продолжайте чтение, я проанализирую это регулярное выражение и объясню, что же в нём происходит. Объяснение не зависит от языка программирования, однако я приведу версии показанного выше Java-кода на Python, JavaScript и Perl и объясню, почему они немного различаются.
Я объясню, как регулярное выражение ^.?$|^(..+?)\1+$ способно отфильтровывать все простые числа. Почему это выражение, а не .?|(..+?)\1+ (использованное в примере кода на Java)? Это связано с тем, как работает String.matches(), о чём я расскажу ниже.
Хотя по этой теме есть несколько постов, я считаю, что они недостаточно глубоки и в них приводится лишь высокоуровневое объяснение, недостаточно хорошо излагающее важные подробности. В своей статье я попытаюсь объяснить подробности, чтобы их мог понять любой. Моя цель — сделать этот код понятным каждому, будь вы гуру регулярных выражений или впервые о них услышали.
База данных — это сердце многих приложений, от полнофункциональных корпоративных сайтов до сравнительно простых инструментов, например, для ведения списков покупок и финансовых трекеров. Популярны реляционные базы данных на основе SQL, но в Linux можно собрать более простую и прозрачную альтернативную базу данных.