Сейчас среди Java/Kotlin команд распространено применение Чистой (ака Гексагональной, ака Луковой — Clean, Hexagonal, Onion) архитектуры для разработки бакэндов прикладных приложений (да и Android‑приложений тоже). Однако это семейство архитектур в контексте прикладной разработки зачастую не даёт никаких преимуществ, а только привносит лишние церемонии и тем самым замедляет её.
С завидной регулярностью эта фраза разжигает огонь моего... сердца. В ней, конечно, есть зерно здравого смысла, но и глупости тоже хватает.
Всем доброго.
Приветственный пост опубликую как-нибудь потом. Когда допишу.
А начну, как полагается, с выводов
Иногда нет-нет да и хочется что-нибудь абстрагировать и обобщить в коде на Си. К примеру, хочешь ты принтануть содержимое структуры несколько раз, пишешь везде, как дурак, printf("%s %d %fn", foo->bar, foo->baz, foo->boom), и интуитивно кажется, что есть способ сделать foo->print(foo), и так вообще со всеми структурами, не только с foo.
Возьмем пример: есть некий чувак с именем и фамилией, и есть птица, у которой есть имя и владелец.
typedef struct Person Person;
struct Person {
char *first_name;
char *last_name;
};
typedef struct Bird Bird;
struct Bird {
char *name;
Person *owner;
};Осваивая рецепты эффективного развития программного проекта, постарался для себя найти причины, делающие полезным использование принципов развития архитектуры SOLID (статья Как не понимать принципы развития архитектуры SOLID).
Анализ этих принципов позволил выделить несколько ключевых закономерностей и базовых элементов, существующих в разработке. Они позволили описать, понять и внедрить SOLID в реальной работе с программным проектом.
Стало интересно выполнить анализ применимости этих понятий для общепринятых парадигм программирования, например для ООП. Хорошо, если результат этой работы будет полезен и Вам.
Бывает так что проект заходит в тупик, и дальнейшее его развитие становится невозможным. Не редко причиной такого провала становится неудачная архитектура, заложенная в начале разработки. Или приходится наблюдать споры о том какой из "двух стульев" лучше, а может даже участвовать и искренне не понимать, как оппонент может так думать!?
Тогда попробуем не много разобраться в абстракциях, откуда они берутся и что с ними делать.
Эта статья представляет собой адаптацию разделов 2 и 3 из главы 9 моей книги «Глубинное обучение с Python» (Manning Publications).
Статья рассчитана на людей, у которых уже есть значительный опыт работы с глубинным обучением (например, тех, кто уже прочитал главы 1-8 этой книги). Предполагается наличие большого количества знаний.
Самая удивительная вещь в глубинном обучении — то, насколько оно простое. Десять лет назад никто не мог представить, каких потрясающих результатов мы достигнем в проблемах машинного восприятия, используя простые параметрические модели, обученные с градиентным спуском. Теперь выходит, что нужны всего лишь достаточно большие параметрические модели, обученные на достаточно большом количестве образцов. Как сказал однажды Фейнман о Вселенной: «Она не сложная, её просто много».
Читать полностью »
Что общего у нормального распределения, конечных автоматов, хеш-таблиц, произвольных предикатов, строк, выпуклых оболочек, афинных преобразований, файлов конфигураций и стилей CSS? А что объединяет целые числа, типы в Haskell, произвольные графы, альтернативные функторы, матрицы, регулярные выражения и статистические выборки? Наконец, можно ли как-то связать между собой булеву алгебру, электрические цепи, прямоугольные таблицы, теплоизоляцию труб или зданий и изображения на плоскости? На эти вопросы есть два важных ответа: 1) со всеми этими объектами работают программисты, 2) эти объекты имеют сходную алгебраическую структуру: первые являются моноидами, вторые — полукольцами, третьи — алгебрами де Моргана.
На протяжении своей карьеры я слышал множество аргументов о длине функции. Более глубокий вопрос — когда код нужно выносить в отдельную функцию? Иногда рекомендации основаны на размере, например, функция должна помещаться на экране. Другие основаны на повторном использовании — любой код, используемый больше одного раза, должен быть вынесен в отдельную функцию. Но если код используется лишь один раз, то можно его оставить на месте. Мне кажется, что большим смыслом обладает аргумент о разделении намерения и реализации. Если нужно потратить время на поиски фрагмента кода чтобы понять, что он делает, то нужно вынести его в функцию и дать ей такое имя, которое отвечает на вопрос "что". Тогда в следующий раз смысл функции сразу будет очевидным, и в большинстве случаев вас не будет волновать то, как функция выполняет свою работу. Иными словами — что происходит в теле функции.
Когда я стал применять такой принцип, я развил в себе привычку писать очень маленькие функции — обычно не больше нескольких строк. Любая функция длиннее шести строк уже попахивает. Вполне обычное дело для меня — иметь функцию с одной строчкой кода. Кент Бек показал мне когда-то пример из оригинальной системы Smalltalk, и это помогло мне по-настоящему понять, что размер — это не важно. Smalltalk в те годы работал на черно-белых машинах. Если нужно было подсветить текст или графику, то приходилось реверсировать видео. Класс в Smalltalk, отвечающий за графику, содержал метод 'highlight', и в его реализации была лишь одна строка — вызов метода 'reverse'. Название метода было длиннее реализации, но это не имело значения, потому что между намерением и реализацией этого кода — большое расстояние.Читать полностью »
Понадобилось взглянуть в сторону mbed. На первый взгляд выглядело весьма интересно – железонезависимый фреймворк, на С++, с поддержкой кучи микроконтроллеров и демо-плат, онлайн-компилятор с интеграцией в систему контроля версий. Куча примеров, еще более убеждающих в элегантности фреймворка. Прямо «из коробки» доступны практически все интерфейсы микроконтроллера при помощи соответствующих, уже реализованных классов. Вот прямо из коробки бери и программируй на С++, не заглядывая в даташит от микроконтроллера – ну не мечта ли?
Тестовой платформой стала давно лежащая без дела STM Nucleo F030, поддерживаемая этой платформой. О том, как зарегистрироваться и начать первый проект, есть много хороших туториалов, об этом не будем. Перейдем сразу к интересному.
Эта статья, еще одна попытка переосмысления метапрограммирования, которые я периодически предпринимаю. Идея каждый раз уточняется, но в этот раз удалось подобрать достаточно простых и понятных примеров, которые одновременно очень компактны и иллюстративны, имеют реальное полезное применение и не тянут за собой библиотек и зависимостей. В момент публикации я буду докладывать эту тему на ОдессаJS, поэтому, статью можно использовать, как место для вопросов и комментариев к докладу. Формат статьи дает возможность более полно изложить материал, чем в докладе, слушатели которого, не освобождаются от прочтения.
Популярное понимание метапрограммирования обычно очень размытое, и чаще всего, заканчивается такими вариантами:
Предлагаю следующее определение:
Метапрограммирование — это парадигма программирования, построенная на программном изменении структуры и поведения программ.
И дальше мы разберем как это работает, зачем это нужно и какие преимущества и недостатки мы получаем в итоге.