Главное, что я не понимаю, это что делать с бордюрами? Съезды не всегда плавные. На самокате я просто ставлю одну ногу на землю, пока другая с самокатом слетает с бордюра. Также, когда нужно подняться на бордюр.
Как это делается с моноколесом?
И что происходит с колесом, когда оно полностью разряжено? Его можно удобно катить с собой за ручку или только нести в руках?
По факту у нас есть клиент в nuget пакете. А у него методы типа "дай значение по такому-то ключу из такой-то таблицы". Дальше в зависимости от задачи поверх этого наворачивается нужное.
Впринципе подход с SSDT имеет право на жизнь, однако если все запросы приходится писать на чистом SQL, то их потом и маппить вручную приходится на объекты? Не задалбывает? Кажется что это тупая и монотонная работа.
Нет, я понял о какой модели вы говорите. Я имел ввиду, что не всегда модель простая — в моей работе чаще всего это агрегат. При этом не всегда все части этого агрегата лежат в одной и той же базе. Иногда это может быть объектная БД с доступом через REST. Так вот для того, чтобы выполнять запросы к сервису "на запись", то есть во время которых выполняется какая-то бизнес-логика, мы собираем полный агрегат. Но это слишком дорого делать на каждый чих, например для запросов на чтение кусков этого агрегата. Тогда мы лезем напрямую в базу и не строим жирную модель.
Нет, только не хранимки. По моему мнению их использование усложняет поддержку — слой доступа к данным уезжает непонятно куда и выходит из под контроля.
Если говорить о настольных приложениях — то все просто — поднял доменную модель из базы и объекты долго живут и все хорошо.
Если говорить о веб приложениях, то объекты живут условно говоря только на время запроса. И тут приходит на помощь CQRS и начинают появляться плюсы orm. При выполнении команды — поднимаем нормальную модель из базы. При выполнении запроса работаем напрямую с orm, строя хитрые оптимальные запросы. Ведь, чтобы отобразить на странице список имён каких либо элементов, нам не нужно доставать из базы целые сущности — достаточно достать именно имена, да и сортировку можно сделать средствами базы.
Ух, ну не надо так прибивать гвоздями друг другу доменную модель и модель хранения. Даже если есть ORM, то вполне вероятно, что структура доменного объекта будет не похожа на оптимальное представление в БД
А вы случайно не знаете доступные на рынке готовые микрофоны для конференций, построенные по такому принципу? В идеале хотелось бы, чтобы один такой микрофон покрывал полусферу радиусом метра 4.
Если мне не изменяет память, то данные, которые грузятся на Ледник амазона предварительно шифруются.
Если говорить про Backblaze, то там тоже можно шифровать бэкап — 50 баксов в год и полный безлимит для одного устройства.
Так что можно бэкапиться и не бояться, что кто-то увидит данные
Кажется вы меня не до конца поняли. Описанный вами embedчик-fullstack — для меня выглядит, как узкий специалист. Хотя, возможно я лукавлю и задним умом считаю логичным разделять разработку железа и его программирование примерно также, как front-end и back-end.
Хуже — по поддерживаемости. В основном я видел спагетти код. При этом после двухмесячного перерыва в работе автор кода не мог понять что, как работает. SOLID, DDD, что это такое?
Если код надёжный и просто — то это замечательно, вот только для меня простота — это не отсутствие работы с указателями или каких-то хитрых вещей, а возможность прочитать совершенно незнакомый код и понять, как он работает. И в этом как раз помогает и SOLID, и другие идеи.
По мне вы описали слегка расширенного, но довольно специализированного разработчика встроенных систем. Когда для созданной железяки понадобится мобильное приложение или сервер сбора данных — это окажется за пределами компетенций описанного специалиста.
А ещё у меня сложилось предвзятое мнение, что чем лучше человек понимает схемотехнику и внутренности МК, тем хуже у него код для этих самых МК
А что поделать, если нужна переносимость? Слышал, что CUDA приятнее, но написав один раз код на OpenCL его можно запустить как на CPU, так и на GPU от Intel, AMD, nVidia. Вроде даже на мобильных GPU можно. Да и не такой уж он и страшный.
Понятно. Я её рассматриваю с любительской точки зрения, не думая о кишках. Видимо поэтому для меня «оставить всё по умолчанию, чтобы потом обновиться» — рабочая стратегия
Поясните, как с вашим подходом, когда отказываешься от файлов конфигурации и перефигачиваешь файловую структуру, обновляться на новую версию mbed?
И я в корне не согласен с тезисом, что непонятно, что питон скрипты делают с кодом — проект же должен лежать в системе контроля версий и сразу становится ясно, где что изменилось.
Да, использование QtCreator — довольно популярное решение, если судить по поисковой выдаче, если вбить "QtCreator Stm32"
Более того, mbed, как сайт так и cli умеют экспортить в проекты QtCreator
Главное, что я не понимаю, это что делать с бордюрами? Съезды не всегда плавные. На самокате я просто ставлю одну ногу на землю, пока другая с самокатом слетает с бордюра. Также, когда нужно подняться на бордюр.
Как это делается с моноколесом?
И что происходит с колесом, когда оно полностью разряжено? Его можно удобно катить с собой за ручку или только нести в руках?
Дык она же не прошена. Там честно написано, что куда переехало.
Хватит уже набрасывать на Мойру. Что она вам такого сделала?
По факту у нас есть клиент в nuget пакете. А у него методы типа "дай значение по такому-то ключу из такой-то таблицы". Дальше в зависимости от задачи поверх этого наворачивается нужное.
Впринципе подход с SSDT имеет право на жизнь, однако если все запросы приходится писать на чистом SQL, то их потом и маппить вручную приходится на объекты? Не задалбывает? Кажется что это тупая и монотонная работа.
Нет, я понял о какой модели вы говорите. Я имел ввиду, что не всегда модель простая — в моей работе чаще всего это агрегат. При этом не всегда все части этого агрегата лежат в одной и той же базе. Иногда это может быть объектная БД с доступом через REST. Так вот для того, чтобы выполнять запросы к сервису "на запись", то есть во время которых выполняется какая-то бизнес-логика, мы собираем полный агрегат. Но это слишком дорого делать на каждый чих, например для запросов на чтение кусков этого агрегата. Тогда мы лезем напрямую в базу и не строим жирную модель.
Нет, только не хранимки. По моему мнению их использование усложняет поддержку — слой доступа к данным уезжает непонятно куда и выходит из под контроля.
Если говорить о настольных приложениях — то все просто — поднял доменную модель из базы и объекты долго живут и все хорошо.
Если говорить о веб приложениях, то объекты живут условно говоря только на время запроса. И тут приходит на помощь CQRS и начинают появляться плюсы orm. При выполнении команды — поднимаем нормальную модель из базы. При выполнении запроса работаем напрямую с orm, строя хитрые оптимальные запросы. Ведь, чтобы отобразить на странице список имён каких либо элементов, нам не нужно доставать из базы целые сущности — достаточно достать именно имена, да и сортировку можно сделать средствами базы.
Ух, ну не надо так прибивать гвоздями друг другу доменную модель и модель хранения. Даже если есть ORM, то вполне вероятно, что структура доменного объекта будет не похожа на оптимальное представление в БД
А вы случайно не знаете доступные на рынке готовые микрофоны для конференций, построенные по такому принципу? В идеале хотелось бы, чтобы один такой микрофон покрывал полусферу радиусом метра 4.
Если мне не изменяет память, то данные, которые грузятся на Ледник амазона предварительно шифруются.
Если говорить про Backblaze, то там тоже можно шифровать бэкап — 50 баксов в год и полный безлимит для одного устройства.
Так что можно бэкапиться и не бояться, что кто-то увидит данные
Хуже — по поддерживаемости. В основном я видел спагетти код. При этом после двухмесячного перерыва в работе автор кода не мог понять что, как работает. SOLID, DDD, что это такое?
Если код надёжный и просто — то это замечательно, вот только для меня простота — это не отсутствие работы с указателями или каких-то хитрых вещей, а возможность прочитать совершенно незнакомый код и понять, как он работает. И в этом как раз помогает и SOLID, и другие идеи.
А ещё у меня сложилось предвзятое мнение, что чем лучше человек понимает схемотехнику и внутренности МК, тем хуже у него код для этих самых МК
А как вы подбирали высоту стола? Для меня это самый "опасный" вопрос.
Вы опоздали. Обучение студентов медиков и использование HoloLens при проведении операций были одними из первых кейсов применения технологии.
Я бы уточнил, что оно нормально так и не заработало в винде. А возможно ни кто так и не понял, как это должно работать.
Есть. Мойрой вроде как пользуются в довольно крупных проектах, да и Контур с неё никогда не слезет и будет развивать.
Поясните, как с вашим подходом, когда отказываешься от файлов конфигурации и перефигачиваешь файловую структуру, обновляться на новую версию mbed?
И я в корне не согласен с тезисом, что непонятно, что питон скрипты делают с кодом — проект же должен лежать в системе контроля версий и сразу становится ясно, где что изменилось.
Ну собственно, а что в этом плохого, если не требуется быстрого переключения, а использование OS упростит разработку и повысит надёжность?
Да, использование QtCreator — довольно популярное решение, если судить по поисковой выдаче, если вбить "QtCreator Stm32"
Более того, mbed, как сайт так и cli умеют экспортить в проекты QtCreator