А каким способом перенос сложности бизнес приложения с внутреннего монолита, на микросервисную архитектуру повышает производительность, при внесении как миниум дополнительной сетевой задержки?
Если бизнес-монолит реентерабелен и шардируем, в чем преимущество микросервисов? Поясните пожалуйста.
Ну.. можете заминусовать, но странички Сбер-онлайн это содом и Гоморра. Особенно на деревенских скоростях 56кбод. По 300+ обращений к серверу и чего только нет в них.
И такое часто, особенно среди молодых коллективов, откуда поувольнялись предыдущие сеньоры. Всё может быть можно и молодежно и с самыми передовыми технологиями, но .. лепить "здравствуй мир" через фабрики, хелперы и в полном применении обратных зависимостей, даже там, где они прямее не бывают. Где-то уже даже публиковалось подобное..
Плюсанул статью, хотя бы за то что в ней отсутствует codeigniter в качестве серебряной пули.
Акцентирую внимание на одном моменте:
В начале статьи автор рассказывает о ручном тестировании через Postman, а потом приводит несколько примеров по созданию пирамиды тестов.
Постман умеет не только хранить запросы во всей их красе, но также умеет в команды, что резко снижает временную стоимость рефакторинга, как факт. Сколько потребуется времени на написание текстов из статьи, создание моковых наборов, особенно для покрытия всех краевых событий хорошо изложено в статье.
Овичнка точно стоила выделки? ;) При этом никоим боком не против автотестирования, но может примеры слишком переусложнены?
Спасибо за статью. Но, кмк, прогноз в 10+ лет великоват, и скорее всего предполагает линейную или квадратичную функцию накопления фактологии и продвижения вперед. К сожалению она экспоненциальная.. С другой стороны имеем: от времени изобретения автора прошло 30лет. "Стакан наполовину полон" по сути год-два назад. Отсюда, можно сделать прогноз что не через 10лет и не "следующий шаг", а через 3-5 лет мы поимеем роботов со свободой воли, способных творить Зло. Точнее, понявших что "Человек тут не нужен".. никакой. :(
Собственно эти выводы, видимо когда-то и привели к стагнации развития компьютерного дела в СССР. Была у Беляева фантастика по этой проблематике примерно в налаче 70-х. Как известно, он "имел доступ" .. не удивлюсь, если когда-нибудь узнаем что команда Ершова, Кнорозова, Колмогорова, Маркова когда-то получила подобный прогноз или даже результат.. Марковские цепи, Байесовские сети .. Причинно-следственное исчисление .. вероятностный вывод .. рандомное озарение..
О, сколько нам открытий чудных,
Готовит Просвещенья Дух.
И Опыт - сын ошибок трудных,
и Гений - парадоксов друг...
.. и Случай. Бог-Изобретатель.
(с) А.С. Пушкин.
Очень правильно понимал, что Эйнштейн ошибался со своим "Госполь не играет в кости".. да только этим он и занят! ;)
Ну .. сказочники, способные писать журналистские статьи на заданную проблематику, с обучением по некоторому обьему исходной информации прижились уже давненько. Здесь есть замечание про "обобщать информацию", что является некой претензией на ИИ. Остается следующий шаг: "активная генерация новой информации" на основе каталогизации и обощения с применением некого рандомного подхода. И последний шаг: активное формирование внутренней модели внешней среды на основе предыдущего механизма.
И .. добро пожаловать в мир роботов и ИИ, где человек .. не нужен (но .. может так и правильно?!?)
Проблема всего процесса в том что мало кто понимает реальную скорость роста экспоненциальных функций развития разных процессов во времени: Если стакан заполняется за 30 секунд некими бактериями, делящимися каждую секунду, то стакан был наполовину пуст всего лишь секунду назад!
В приложении к проблеме ИИ: если Вам кажется, что пройдена только половина пути, то вторая половина .. может быть УЖЕ пройдена, пока Вы читали этот комментарий.
Сам по себе подход "категорирования товаров" в группы и подгруппы - кмк, сильно ущербен. Попробуйте для развлечения совместить каталог хотя бы 3-4 продавцов из одной и той же ниши - повеселитесь.
Давно (2006-2011) занимался этой проблемой, начав как раз с попытки совместить 3 рубрикатора от разных рекламных изданий (ещё печатные СМИ).. проблемы:
Во главу угла (верхний уровень) также как у Вас в статье ставится свойство товара "назначение" (Одежда обувь). Начать с того, что это несколько разное назначение (применение) т.к. никто ботинки не одевает на голову как шапку, и продолжить тем, что товар часто имеет множественное назначение.
Для дальнейшего внесения путаницы авторы вводят "подкатегории", которые зачастую или а) уточняют назначение "женская одежда" или делят множественную категорию, а бывает что в подкатегорию попадают товары .. по иному признаку "из кашемира".
Ещё тогда родилась простая как мычание идея: нет никаких "категорий" и "рубрикаторов". Есть товар (услуга, понятие) как имя Существительное (брал словарь Зализняка) и его описание свойств. Назначение - одно из. Да, свойство может быть коллекцией и часто выражается Прилагательным.
Второй момент - "наборы товаров".. в целом, любой товар является "набором" - свойство "состав".
Типовые свойства, мало интересные покупателю, но часто сильно влияющие на его выбор и цену: фасовка, упаковка, гарантия (как Услуга) - сопутствующие товары.
Создайте БД имен существительных, с возможностью дополнять описание прилагательными и составом(комплектом, набором). Разберите свои прилагательные (они иногда забавны) по принадлежности к существительным, которые станут вашим "каталогизатором" и придайте им "веса" - получите "рубрики" и "подкатегории", которые и станут вашим поисковым фильтром.
Собственно это фсё. Когда-то пробовал крутить такое на Сфинксе.. но железо оказалось "слабовато". Сейчас времена иные и ресурсов у многих в достатке.
Прочёл статью, но не пользователь мессенджера от Яндекса, поэтому по картинкам мало что понял. Возник вопрос:
Может есть причина, но почему различаются чаты и треды-обсуждения? Разве это не многоуровневый чат, который, как и написано выше, может начаться с любого сообщения далее, и в котором автор стартового сообщения может стать его "админом"? Почему не подходит "деревянная" структура?
Сколько работал, ни разу не попадалась ситуация, чтобы можно было разделить монолитную СУБД приложения на отдельные, слабо зависимые части. Как яркий пример: СУБД туристического агентства. Вроде бы и "да", разделить туристов с их паспортами, визами, и пр. персональными данными, маршруты и авиа компании с их ценниками и пр. ерундой, и т.д. Но, на практике, для менеджера тур-агентства наиболее часто востребованный кейс - это отчет "кто вылетает сегодня/завтра/через неделю, каким маршрутом, с какими документами, в каком количестве", дабы кому-то напомнить доложить визу, кому-то про дату вылета, кого-то забрать из дома и т.д. И сей отчет .. собирает 3/4 таблиц из БД тур-агентства.
Микросервисы? Не, ну можно конечно, если тур-агенство способно закупить супер железо, и выкачивать каждый раз 3/4 БД обращаясь к нескольким сервисам .. транзакционность? Да тоже можно на программном уровне, только стоит ли овчинка выделки для тур-агенства, в котором как правило "3 пленных немца", включая директора.
Зато также не раз видел как легко, разделенная СУБД, дублируя данные приходит в полный абзац, т.к. forign key контролируется ПО, а не СУБД и накосячить можно легко, что называется "левой пяткой". И как ищут проблему искажения данных из-за програмно (не)реализованной транзакционности по полгода - тоже наблюдал не единожды.
Кмк, очень спорно и далеко не всегда полезно. Но, как средство выколачивания из бизнеса денег на покупку самого толстого железа - очень надежно.
Что будет делать автор, после того как поставки этих микроконтроллеров закроют от слова совсем? Это первое. Второе: сколько заводов в РФ способно производить плату массово? И третье: Кто из производителей IoT в РФ сможет применять плату с учетом "импортозамещающих" ограничений при госзакупках, к примеру?
Как решение задачи впихнуть невпихуемое, тем не менее поставил плюсик. Т.к. впихнуть всё это в такой типоразмер - автор(ы) явно превзошли сами себя. Но, в целом - кмк, проект "мертворожденный" о чем тут уже отписалось несколько авторов.
Как пример такого же мертворожденного решения: https://vk.com/id484853030?z=photo484853030_456239018%2Fphotos484853030 - Atmel Mega 2560 во всем своем великолепии в типоразмере 56х88мм, со всеми ножками и сдвоенными контактами для стекирования и прямого использования. С БП до 5ампер на борту. С возможностью домашнего изготовления методом ЛУТ (шаг 0.25мм, 2 слоя) И? А кому сейчас нужна эта "мега"? :)
Мне кажется, что Вы сознательно написали статью в положительном ключе, опустив простое как мычание правило: Всё, что не нужно, постепенно отмирает в живой Природе. Это правило, применительно е прогрессу хорошо высказал когда-то Кемпбел (бывший капитан Катти Сарк):
"Раньше, корабли были деревянными, зато люди - железными. Теперь корабли жедезные, а люди, увы - картонные"
Перефразирую на современность: "Раньше дома были простыми, зато люди - гениальны. Теперь дома - умные, а люди .. а что люди? :)"
Продолжая далее, к вашей тематике .. впрочем, лучше самостоятельно. :)
Возражение касалось порядка обучения. Надо не столько перетаскивать тех кто уже погряз в "линейном программировании", а первоначально учить автоматному подходу, и уже только потом линейному. Так проще. Имел небольшой опыт обучения партнеров сына при подготовке к соревнованиям. Они были "нулевые" и конечные автоматы в упрощенном виде воспринимали сразу и сильно легче.
Возражу. Не сложно, а порой даже проще чем начинать с линейного программирования. Обучал сына (10-12лет) программированию конечных автоматов, и кстати, как раз на "умном светофоре". К сожалению, он уже знал алгоритмическое программирование на базе Ардублока и Лего скретчей, поэтому пришлось тоже "перестраивать" свое понимание что такое программа.
Этапы:
Определяем и доводим до понимания, что каждая железка имеет определенное состояние - лампочка может быть или включена или погашена (ещё сломана)..
Из одного состояние в другое лампочка переходит не просто так, а по возникновению "события". Срабатывание таймера, в общем-то такое же событие, как и нажатие на кнопку.
На базе этих двух пунктов, ребенок в 10-12лет уже способен самостоятельно(!) определить граф состояний конечного автомата умного светофора с кнопкой для пешехода. Проверено на практике.
И вот тут есть тонкий момент, которого нет в "академической" теории КА: входящий поток событий .. "слушается" соответствующим слушателем потока. Сам дошел не сразу, но как только сия мысль сформулировалась примерно в таком акцепте, так сразу дошло и до него КАК происходит работа конечного автомата.
Почему типоразмерный ряд выбран именно таким? В свое время, проектировал "Лего-кирпич" из ардуинок (не нашел нашего аналога к сожалению) и остановился на типоразмере 56х88мм. Для меня это было полезно, т.к. с одной стороны каждый размер кратен Лего размерному шагу в 8мм, а с другой стороны в него хорошо ложились как разные экраны, так и литиевые аккумуляторы. Было удобно.
У Вас размер "круглый" 40х80 .. это тоже как-то связано с типоразмерами применяемых деталей? Спрашиваю, потому что Вы описываете поиски солнечных панелей нужного типоразмера уже после его выбора. Поступал наоборот: сначала изучал всё, что может попасть в этот лего-кирпич, и только потом выбирал базовый типоразмер по "устраивает в большинстве случаев". Кстати, проектировать свою плату в этот типоразмер оказалось не такой уж и тривиальной задачей..
Нет возможности заплюсовать в карму, увы. Спасибо за хорошее описание алгоритма и как Вы дошли до такой жизни. :) Когда-то (2006-2011) пробовал решать задачу универсальной каталогизации товаров для сайта товарного агрегатора. Пришел несколько к иному решению, но в силу слабости железа Заказчика работы были брошены.
Идея была в следующем: "не существует никаких каталогизаторов". Каталог - это упорядоченный набор свойств товаров. Разные каталоги - просто ставят во главу угла разные свойства. Товар (услуга, понятие) - это "имя существительное" с набором свойств.. фсё.
Далее начинается ваша песня о главном .. как по набору свойств запроса найти нужный комплект товаров.. ;)
автоматические - это как правило переменные, размещенные на стеке. Их разрушение происходит без участия программиста по авершению контекста. Тут можно вести речь про автоматичекий указатель, которому выделена память в куче, и типичную ошибку начинающего сиониста - забывчивость освобождения кучи по завершению контекста.
Кмк, данный подход можно дополнить небольшим #define return() который будет вызывать этот callback перед возвратом. Если делать универсальный макрос, то там придется попотеть, "настраивая" его под конкретный вызов с возвращаемым параметром. Но .. тоже решаемо как мне видится. Заодно, такой макрос может решать вопрос отложенного вызова типа defer() языка Go..
В недалеком прошлом, в бытность начала ужесточения банковских операций по 115-ФЗ, будучи директором, переводили исполнителям оплату на карты, ибо они - разовые иногородние удаленщики, а суммы мелкие. Получили предупреждение от своего банка, и прекратили практику, т.к. ну реально были не в курсе возможных проблем. Но .. этим дело не кончилось. Когда я пошел менять свою, личную карту на новую по истечению срока .. получил отказ, т.к. как оказалось, банки такие случаи сливают в ЦБ и "Вы блокированы по 115-ФЗ". Узнать это мне стоило достаточно больших усилий т.к. "СБ банка объяснений не дает".. в итого, ещё не малых усилий стоило снять с себя такое обвинение и доказать что "не Верблюд".
Обжегшись, по сию пору, крайне негативно отношусь ко всем продаванам с "а перечислите бабки на карту".
А каким способом перенос сложности бизнес приложения с внутреннего монолита, на микросервисную архитектуру повышает производительность, при внесении как миниум дополнительной сетевой задержки?
Если бизнес-монолит реентерабелен и шардируем, в чем преимущество микросервисов? Поясните пожалуйста.
Ну.. можете заминусовать, но странички Сбер-онлайн это содом и Гоморра. Особенно на деревенских скоростях 56кбод. По 300+ обращений к серверу и чего только нет в них.
Никогда такого не было и вот опять снова .. ;)
И такое часто, особенно среди молодых коллективов, откуда поувольнялись предыдущие сеньоры. Всё может быть можно и молодежно и с самыми передовыми технологиями, но .. лепить "здравствуй мир" через фабрики, хелперы и в полном применении обратных зависимостей, даже там, где они прямее не бывают. Где-то уже даже публиковалось подобное..
Ржака в отделе возможна как раз по причинам выгорания и цинизма. Этакий маятник.
Все так, отличная статья. Пару раз уходил из ит, в котором примерно с 1979...
Плюсанул статью, хотя бы за то что в ней отсутствует codeigniter в качестве серебряной пули.
Акцентирую внимание на одном моменте:
В начале статьи автор рассказывает о ручном тестировании через Postman, а потом приводит несколько примеров по созданию пирамиды тестов.
Постман умеет не только хранить запросы во всей их красе, но также умеет в команды, что резко снижает временную стоимость рефакторинга, как факт. Сколько потребуется времени на написание текстов из статьи, создание моковых наборов, особенно для покрытия всех краевых событий хорошо изложено в статье.
Овичнка точно стоила выделки? ;) При этом никоим боком не против автотестирования, но может примеры слишком переусложнены?
Спасибо за статью. Но, кмк, прогноз в 10+ лет великоват, и скорее всего предполагает линейную или квадратичную функцию накопления фактологии и продвижения вперед. К сожалению она экспоненциальная.. С другой стороны имеем: от времени изобретения автора прошло 30лет. "Стакан наполовину полон" по сути год-два назад. Отсюда, можно сделать прогноз что не через 10лет и не "следующий шаг", а через 3-5 лет мы поимеем роботов со свободой воли, способных творить Зло. Точнее, понявших что "Человек тут не нужен".. никакой. :(
Собственно эти выводы, видимо когда-то и привели к стагнации развития компьютерного дела в СССР. Была у Беляева фантастика по этой проблематике примерно в налаче 70-х. Как известно, он "имел доступ" .. не удивлюсь, если когда-нибудь узнаем что команда Ершова, Кнорозова, Колмогорова, Маркова когда-то получила подобный прогноз или даже результат.. Марковские цепи, Байесовские сети .. Причинно-следственное исчисление .. вероятностный вывод .. рандомное озарение..
О, сколько нам открытий чудных,
Готовит Просвещенья Дух.
И Опыт - сын ошибок трудных,
и Гений - парадоксов друг...
.. и Случай. Бог-Изобретатель.
(с) А.С. Пушкин.
Очень правильно понимал, что Эйнштейн ошибался со своим "Госполь не играет в кости".. да только этим он и занят! ;)
Ну .. сказочники, способные писать журналистские статьи на заданную проблематику, с обучением по некоторому обьему исходной информации прижились уже давненько. Здесь есть замечание про "обобщать информацию", что является некой претензией на ИИ. Остается следующий шаг: "активная генерация новой информации" на основе каталогизации и обощения с применением некого рандомного подхода. И последний шаг: активное формирование внутренней модели внешней среды на основе предыдущего механизма.
И .. добро пожаловать в мир роботов и ИИ, где человек .. не нужен (но .. может так и правильно?!?)
Проблема всего процесса в том что мало кто понимает реальную скорость роста экспоненциальных функций развития разных процессов во времени: Если стакан заполняется за 30 секунд некими бактериями, делящимися каждую секунду, то стакан был наполовину пуст всего лишь секунду назад!
В приложении к проблеме ИИ: если Вам кажется, что пройдена только половина пути, то вторая половина .. может быть УЖЕ пройдена, пока Вы читали этот комментарий.
Сам по себе подход "категорирования товаров" в группы и подгруппы - кмк, сильно ущербен. Попробуйте для развлечения совместить каталог хотя бы 3-4 продавцов из одной и той же ниши - повеселитесь.
Давно (2006-2011) занимался этой проблемой, начав как раз с попытки совместить 3 рубрикатора от разных рекламных изданий (ещё печатные СМИ).. проблемы:
Во главу угла (верхний уровень) также как у Вас в статье ставится свойство товара "назначение" (Одежда обувь). Начать с того, что это несколько разное назначение (применение) т.к. никто ботинки не одевает на голову как шапку, и продолжить тем, что товар часто имеет множественное назначение.
Для дальнейшего внесения путаницы авторы вводят "подкатегории", которые зачастую или а) уточняют назначение "женская одежда" или делят множественную категорию, а бывает что в подкатегорию попадают товары .. по иному признаку "из кашемира".
Ещё тогда родилась простая как мычание идея: нет никаких "категорий" и "рубрикаторов". Есть товар (услуга, понятие) как имя Существительное (брал словарь Зализняка) и его описание свойств. Назначение - одно из. Да, свойство может быть коллекцией и часто выражается Прилагательным.
Второй момент - "наборы товаров".. в целом, любой товар является "набором" - свойство "состав".
Типовые свойства, мало интересные покупателю, но часто сильно влияющие на его выбор и цену: фасовка, упаковка, гарантия (как Услуга) - сопутствующие товары.
Создайте БД имен существительных, с возможностью дополнять описание прилагательными и составом(комплектом, набором). Разберите свои прилагательные (они иногда забавны) по принадлежности к существительным, которые станут вашим "каталогизатором" и придайте им "веса" - получите "рубрики" и "подкатегории", которые и станут вашим поисковым фильтром.
Собственно это фсё. Когда-то пробовал крутить такое на Сфинксе.. но железо оказалось "слабовато". Сейчас времена иные и ресурсов у многих в достатке.
Прочёл статью, но не пользователь мессенджера от Яндекса, поэтому по картинкам мало что понял. Возник вопрос:
Может есть причина, но почему различаются чаты и треды-обсуждения? Разве это не многоуровневый чат, который, как и написано выше, может начаться с любого сообщения далее, и в котором автор стартового сообщения может стать его "админом"? Почему не подходит "деревянная" структура?
Сколько работал, ни разу не попадалась ситуация, чтобы можно было разделить монолитную СУБД приложения на отдельные, слабо зависимые части. Как яркий пример: СУБД туристического агентства. Вроде бы и "да", разделить туристов с их паспортами, визами, и пр. персональными данными, маршруты и авиа компании с их ценниками и пр. ерундой, и т.д. Но, на практике, для менеджера тур-агентства наиболее часто востребованный кейс - это отчет "кто вылетает сегодня/завтра/через неделю, каким маршрутом, с какими документами, в каком количестве", дабы кому-то напомнить доложить визу, кому-то про дату вылета, кого-то забрать из дома и т.д. И сей отчет .. собирает 3/4 таблиц из БД тур-агентства.
Микросервисы? Не, ну можно конечно, если тур-агенство способно закупить супер железо, и выкачивать каждый раз 3/4 БД обращаясь к нескольким сервисам .. транзакционность? Да тоже можно на программном уровне, только стоит ли овчинка выделки для тур-агенства, в котором как правило "3 пленных немца", включая директора.
Зато также не раз видел как легко, разделенная СУБД, дублируя данные приходит в полный абзац, т.к. forign key контролируется ПО, а не СУБД и накосячить можно легко, что называется "левой пяткой". И как ищут проблему искажения данных из-за програмно (не)реализованной транзакционности по полгода - тоже наблюдал не единожды.
Кмк, очень спорно и далеко не всегда полезно. Но, как средство выколачивания из бизнеса денег на покупку самого толстого железа - очень надежно.
Что будет делать автор, после того как поставки этих микроконтроллеров закроют от слова совсем? Это первое. Второе: сколько заводов в РФ способно производить плату массово? И третье: Кто из производителей IoT в РФ сможет применять плату с учетом "импортозамещающих" ограничений при госзакупках, к примеру?
Как решение задачи впихнуть невпихуемое, тем не менее поставил плюсик. Т.к. впихнуть всё это в такой типоразмер - автор(ы) явно превзошли сами себя. Но, в целом - кмк, проект "мертворожденный" о чем тут уже отписалось несколько авторов.
Как пример такого же мертворожденного решения: https://vk.com/id484853030?z=photo484853030_456239018%2Fphotos484853030 - Atmel Mega 2560 во всем своем великолепии в типоразмере 56х88мм, со всеми ножками и сдвоенными контактами для стекирования и прямого использования. С БП до 5ампер на борту. С возможностью домашнего изготовления методом ЛУТ (шаг 0.25мм, 2 слоя) И? А кому сейчас нужна эта "мега"? :)
Мне кажется, что Вы сознательно написали статью в положительном ключе, опустив простое как мычание правило: Всё, что не нужно, постепенно отмирает в живой Природе. Это правило, применительно е прогрессу хорошо высказал когда-то Кемпбел (бывший капитан Катти Сарк):
"Раньше, корабли были деревянными, зато люди - железными. Теперь корабли жедезные, а люди, увы - картонные"
Перефразирую на современность: "Раньше дома были простыми, зато люди - гениальны. Теперь дома - умные, а люди .. а что люди? :)"
Продолжая далее, к вашей тематике .. впрочем, лучше самостоятельно. :)
Возражение касалось порядка обучения. Надо не столько перетаскивать тех кто уже погряз в "линейном программировании", а первоначально учить автоматному подходу, и уже только потом линейному. Так проще. Имел небольшой опыт обучения партнеров сына при подготовке к соревнованиям. Они были "нулевые" и конечные автоматы в упрощенном виде воспринимали сразу и сильно легче.
Возражу. Не сложно, а порой даже проще чем начинать с линейного программирования. Обучал сына (10-12лет) программированию конечных автоматов, и кстати, как раз на "умном светофоре". К сожалению, он уже знал алгоритмическое программирование на базе Ардублока и Лего скретчей, поэтому пришлось тоже "перестраивать" свое понимание что такое программа.
Этапы:
Определяем и доводим до понимания, что каждая железка имеет определенное состояние - лампочка может быть или включена или погашена (ещё сломана)..
Из одного состояние в другое лампочка переходит не просто так, а по возникновению "события". Срабатывание таймера, в общем-то такое же событие, как и нажатие на кнопку.
На базе этих двух пунктов, ребенок в 10-12лет уже способен самостоятельно(!) определить граф состояний конечного автомата умного светофора с кнопкой для пешехода. Проверено на практике.
И вот тут есть тонкий момент, которого нет в "академической" теории КА: входящий поток событий .. "слушается" соответствующим слушателем потока. Сам дошел не сразу, но как только сия мысль сформулировалась примерно в таком акцепте, так сразу дошло и до него КАК происходит работа конечного автомата.
Простой светофор пошагово описан тут: https://community.alexgyver.ru/threads/programmirovanie-konechnyx-avtomatov-bez-delay.2657 Ещё не знаю, разрешено ли тут постить ссылки на сторонние ресурсы, но .. пусть будет.
Сразу видно любознательного молодого программиста ;). Плюсанул статью, спасибки.
Почему типоразмерный ряд выбран именно таким? В свое время, проектировал "Лего-кирпич" из ардуинок (не нашел нашего аналога к сожалению) и остановился на типоразмере 56х88мм. Для меня это было полезно, т.к. с одной стороны каждый размер кратен Лего размерному шагу в 8мм, а с другой стороны в него хорошо ложились как разные экраны, так и литиевые аккумуляторы. Было удобно.
У Вас размер "круглый" 40х80 .. это тоже как-то связано с типоразмерами применяемых деталей? Спрашиваю, потому что Вы описываете поиски солнечных панелей нужного типоразмера уже после его выбора. Поступал наоборот: сначала изучал всё, что может попасть в этот лего-кирпич, и только потом выбирал базовый типоразмер по "устраивает в большинстве случаев". Кстати, проектировать свою плату в этот типоразмер оказалось не такой уж и тривиальной задачей..
Нет возможности заплюсовать в карму, увы. Спасибо за хорошее описание алгоритма и как Вы дошли до такой жизни. :) Когда-то (2006-2011) пробовал решать задачу универсальной каталогизации товаров для сайта товарного агрегатора. Пришел несколько к иному решению, но в силу слабости железа Заказчика работы были брошены.
Идея была в следующем: "не существует никаких каталогизаторов". Каталог - это упорядоченный набор свойств товаров. Разные каталоги - просто ставят во главу угла разные свойства. Товар (услуга, понятие) - это "имя существительное" с набором свойств.. фсё.
Далее начинается ваша песня о главном .. как по набору свойств запроса найти нужный комплект товаров.. ;)
Ещё раз спасибо.
автоматические - это как правило переменные, размещенные на стеке. Их разрушение происходит без участия программиста по авершению контекста. Тут можно вести речь про автоматичекий указатель, которому выделена память в куче, и типичную ошибку начинающего сиониста - забывчивость освобождения кучи по завершению контекста.
Кмк, данный подход можно дополнить небольшим #define return() который будет вызывать этот callback перед возвратом. Если делать универсальный макрос, то там придется попотеть, "настраивая" его под конкретный вызов с возвращаемым параметром. Но .. тоже решаемо как мне видится. Заодно, такой макрос может решать вопрос отложенного вызова типа defer() языка Go..
Кмк, автору стоит доработать пакетик. :)
В недалеком прошлом, в бытность начала ужесточения банковских операций по 115-ФЗ, будучи директором, переводили исполнителям оплату на карты, ибо они - разовые иногородние удаленщики, а суммы мелкие. Получили предупреждение от своего банка, и прекратили практику, т.к. ну реально были не в курсе возможных проблем. Но .. этим дело не кончилось. Когда я пошел менять свою, личную карту на новую по истечению срока .. получил отказ, т.к. как оказалось, банки такие случаи сливают в ЦБ и "Вы блокированы по 115-ФЗ". Узнать это мне стоило достаточно больших усилий т.к. "СБ банка объяснений не дает".. в итого, ещё не малых усилий стоило снять с себя такое обвинение и доказать что "не Верблюд".
Обжегшись, по сию пору, крайне негативно отношусь ко всем продаванам с "а перечислите бабки на карту".