«обслуживаемым через авторизованного Premier реселлера претензий быть не может.»
Вот это в сожалению без всяких гарантий. Лично сталкивался с проблемами с платными аккаунтами, которые в итоге пришлось закрыть и открыть новые, например у МС.
Про зеленый свет, вопрос холиварный, если исследования которые показывают, что эффективность красно-синего спектра сильно преувеличена и от зеленого он отличается на считанные проценты( при этом эффективность диодов ниже и они дороже ).
Плюс спектр по разному влияет на разные растения в разных стадиях роста.
Но тут вопрос даже не в этом. В данной лампе и красно синий никакой. Красный пик ниже 650, синий чуть выше 450. Освещенность в красно-синей зоне у нее будет не выше пары
lamptest.ru/review/nanosvet-l287-lh-mr16-85-gu10-840-38d, при это отсутствует освещенность в зеленой плюс чудовищная цена и мощность.
Да есть совсем немного дальнего красного и синего, но его кол-во пренебрежительно мало.
Эффективность скорее всего будет никакая. Световой поток для такой мощности очень слабый. Спектр для фитолампы никакой, тут даже без исследований оспаривающих необходимость особого спектра можно обойтись.
На эти деньги можно взять 4 таких lamptest.ru/review/nanosvet-l287-lh-mr16-85-gu10-840-38d световой поток будет в 5 раз выше, спектр все тоже, плюс зеленый.
Да нет дальнего красного и дальнего синего, так и тут и на грани погрешности.
Возможно в каких-то областях это и удобно, но я не видел ни одного реально удобного «3D конфигуратора».
Мне кажется, было бы не плохо добавлять его как опцию к обычному конфигуратору, для тех кому это интересно.
По факту, все что мне попадалось, жутко тормозное, лагающее даже на мощно железе, и с нулевым юзабилити. Единственно желание которое возникает от знакомства с таким конфигуратором, поскорее закрыть его и найти на сайте PDF прайс, которой тоже часто искать приходиться с помощью магии.
Например, тот же конфигуратор тайоты съел примерно 20%-30% cpu i7-5600u.
Данное сообщение вполне можно притянуть к рекламному, поскольку он служит средство привлечения внимания, а определить круг лиц они не могут, вас же не идентифицировали, а значит не определенному кругу лиц.
Плюс массовость сообщения не влияет на то, является ли оно рассылкой или нет, рассылка может быть даже из одного сообщения, в законе о связи кол-во сообщений не указано.
Жалобу в ФАС и Роскомнадзор. Там за это штрафы достаточно большие, они таким образом нарушают сразу два ФЗ, о рекламе, возможно, и о связи, статья 44.1. Только сначала напишите им претензию, по почте, а когда пройдет срок ответа, тогда вместе с претензией жалобу.
ИМХО начинать надо с малого коммерческого транспорта. Для этого есть куча причин, первая короче пробеги, вторая работа в городах с низкой средней скоростью где экономия от использования электро двигателя максимальная, третья экологические требования.
На магистралях, как мне кажется пока ловить особо не чего( до тех пор пока цена не упадет до уровня обычного тягача ), расход на магистрали минимально возможный, технологии отработаны, целый ворох готовых узлов и компонентов, эко требования ниже, да и пробег на одной заправке сильно за 1000км.
Вы пытались реализовать необходимы функционал в nix?
В никсах есть проблемы, но синхронизация контактов и почты не из их числа.
К тому же outlook совершенно справедливо только ленивый не именовал outглюк.
Лично не сталкивался только с планирование переговорных, но думаю и это не слишком сложно, да и у администрации Мюнхена наверно на тысячи переговорных, чтобы это было реально проблемой.
Не всегда возможно, вполне вероятно, что там такое кол-во разного странного софта и нормативных требований, что проще пилить свой.
Т.е. пока разберешься как надо, уже свой 10 раз сделаешь.
А в чем проблема с контактами? Во всяком случае на android, linux и windows клиентах это никак не rocket science.
С push сложнее, но при бюджетах исчисляемых в миллионах евро и эта проблема решаема( при этом стоимость решения достаточно низкая и скорее всего где-нибудь это уже сделано, я просто не сталкивался ). Хотя не уверен, что лично я бы скинулся на push уведомления для чиновников, имхо и старый добрый pull для этих целей вполне приемлем.
Вы беретесь утверждать, что на никсах нельзя сделать почту для смартфона?
Я оперирую терминами статьи, там сказано про почту, там не сказано про календари, встречи, интеграцию в AD и т.д. Да подобные вещи на Exchange сделать проще, но и на никсах это вполне подъемная задача.
Это не компьютеры, это куча денег на внедрение которые заплатили налогоплательщики и которые в итоге списали в убытки, т.е. кто-то поэкспериментировал за счет Мюнхена, имхо в таком случае этот кто-то должен опубликовать подробный отчет, чтобы другие «Мюнхены» и коммерческие компании могли реиспользовать опыт.
Использовать линукс где угодно может кто угодно, вопрос в прикладном софте и документообороте, если он работает нормально, то не важно какая ОС, андройд же используют и IOS тоже, и никаких проблем.
Все это было бы интересно при наличии экономического обоснования, а так, одни деньгоеды отняли еду у других, ничего нового, обидно, что платит за весь этот банкет налогоплательщик.
А вот экономическое обоснования я бы почитал с огромным удовольствием. И не в стиле, пришлось поставить Exchange для смартфонов, это очевидная чушь для любого грамотного спеца, а с полным и исчерпывающим списком сложностей содержащим техническую и экономическую аннотацию.
Плюс к экономической части лучше относиться как к пилоту, поскольку подход является масштабируемым, а следовательно затраты можно будет размазать более ровным слоем, в отличии от лицензий.
В компании в которой я тружусь используется windows и, я полагаю, это экономически обосновано, но чужой опыт переходы на nix крайнее интересен.
Во первых статья так и не отвечает на вопрос, как же?
Во вторых подобный специалист очень часто имеет зияющие дыры в базовых знаниях. Часто упустив, что-то в обучении или в систематизации знаний человек идет такими окольными путями, что замучаешься переобучать. Плюс очень сложно понять где человек может сделать ну просто дичайшую ошибку. Ты рассчитываешь, что если человек может умножить 20 на 30, то 2+2 он знает, а потом находишь там 5, наткнувшись случайно, и понимаешь, нужно делать полный аудит всего сделанного до текущего момента.
«Диафрагма» говорит о кол-ве света на единицу площади, у разных сенсоров с одной диафрагмой на единицу площади попадет одинаковое кол-во света. Ваше утверждение по меньше мере странное.
То есть апертура F1.8 для 1/2.55" сенсора — это F6.3. Но и апертура F2.0 для 1/2.3" сенсора — это тоже F6.3. То есть увеличение апертуры — это всего лишь маркетинг.
Шумы же сенсора, зависит от технологии, материалов и размера. Так, что два сенсора 1/2,55 и 1/2,3 вообще бессмысленно сравнивать не имея прочих параметров. Плюс есть еще много всего, что влияет на итоговое качество картинки, начиная от качества линз( при одинаковой «диафрагме» ) и заканчивая софтом.
По факту сравнивать имеет смысл только итоговый результат. Поскольку даже шумное, но четкое изображение, будет лучше не шумного, но вне фокуса, так что все эти параметры от лукавого, хотя при прочих равных «большая диафрагма» лучше( если она конечно не достигнута снижение требований к качеству изображения, например снижение четкости по углам ).
А не проще разместить тоже самое но у не провайдера? Делаем дочку, лицензии на услуги связи у нее нет, закон о связи на нее не распространяется как и куча нормативных требований, дочка заключает договор в google, все запросы на youtube уходят на сервера дочки. Их по большому счету можно даже из стоек не вынимать.
Возможность упростить кучу кода, занимающегося отправкой запросов в другие сервисы: выкинуть таймауты, обработку сетевых ошибок, разделение на идемпотентные и не идемпотентные запросы с разной логикой их повтора при ошибках и защиту от дубликатов, саму логику повтора с задержками и защитой от бесконечного повтора, асинхронное выполнение запросов.
Все эти проблемы в случае высоко изолированных сервисов у вас будут. Только не в сетевом слое, который обсосан со всех сторон и как решать данные проблемы в общем понятно,, вам придется для всех этих проблем изобретать свои велосипеды, и натыкаться на потерю запросов, зависание запросов, нарушения порядка запросов в самых неожиданных местах, поскольку куча разного стороннего кода на такую работу не рассчитано.
Плюс сложности с разделением ресурсов, как аппаратных, когда у вас один модуль повесил остальные, так и программными, различными пулами и т.д.
К тому же сетевое взаимодействие у вас все равно осталось, с клиентами, с вешними сервисами, между инсталляциями и т.д., так что код для сетевого взаимодействия у вас никуда не делся.
Возможность упростить архитектуру, реализацию и улучшить юзабилити — во многих (а то и всех, если повезёт) местах, где в обычных микросервисах возникает eventual consistency
У вас декларировано разделение данных, а значит все те же проблемы, что и в микросервисах, я бы даже сказал их ключевые проблемы, консистентность данных. eventual consistency, распределенные транзакции или просто нарушение консистентности, это уже решается для каждого проекта индивидуально.
Circuit Breaker
Тут согласен, пожалуй это плюс. Но:
1) Зависимость от инструментов разработки, поскольку далеко не везде это работает.
2) Если инструменты разработки это проблему не решают проблема усугубляется по сравнению с микросервисами.
Основной недостаток — неприменимость этого подхода в большинстве проектов, где действительно необходима высокая доступность и/или масштабирование
Вот, это как мне кажется ключевой момент. В тех проектах где такой подход можно использовать он избыточен, а где уже актуально, там не достаточен.
Что касается мелких подробностей вроде общего конфига — я вообще не понимаю, в чём проблема.
Я тоже не понимаю. Но mayorovp считает, что она есть.
То, что я вижу,
плюсы: отсутствие сетевого слоя
минусы: отсутствие раздельного деплоя, отсутствие разделение аппаратных и программных ресурсов, распределенные системы только полной установкой, длительная сборка и деплой, ограничение на выбор инструментов и языков, только единая среда выполнения и общие зависимости, отказ от многих стандартных инструментов которые активно используются в микросервисах.
Ключевые проблемы с данными остались и там и там, консистентность и агрегация.
Именно что это никакой не монолит. А встроенные микросервисы, которые общаются друг с другом без сетевого взаимодействия.
Так с этого и началась ветка, недомикросервисы, со всеми их недостатками, но без многих достоинств. Честно, ни вижу ни одного плюса подобного похода( по сравнению с микросервисами ), который не был бы не лучшей практикой в микросервисах.
Например единый конфиг, никаких проблем сделать единый конфиг для микросервисов нет, только мне кажется очевидным, что это плохая идея, поскольку теряется независимость сервисов( модулей, проектов, не принципиально как назвать ), появляются издержки на коммуникацию в команде, на мерджи изменений, осложняется выделение сервиса, проекта, в отдельную команду/отсуорс/отдельному сотруднику.
Плюс куча ограничение на язык и среду разработки, чтобы поддерживать искусственно созданную изоляцию внутри монолита, сложности вводом новых людей в проект, проблемы которой вообще нет в микросервисах.
Вот это в сожалению без всяких гарантий. Лично сталкивался с проблемами с платными аккаунтами, которые в итоге пришлось закрыть и открыть новые, например у МС.
Плюс спектр по разному влияет на разные растения в разных стадиях роста.
Но тут вопрос даже не в этом. В данной лампе и красно синий никакой. Красный пик ниже 650, синий чуть выше 450. Освещенность в красно-синей зоне у нее будет не выше пары
lamptest.ru/review/nanosvet-l287-lh-mr16-85-gu10-840-38d, при это отсутствует освещенность в зеленой плюс чудовищная цена и мощность.
Да есть совсем немного дальнего красного и синего, но его кол-во пренебрежительно мало.
Вот ссылка на «сильно понтонный патрон»
leroymerlin.ru/product/patron-keramicheskiy-uniel-gu10-cvet-belyy-12856316
На эти деньги можно взять 4 таких lamptest.ru/review/nanosvet-l287-lh-mr16-85-gu10-840-38d световой поток будет в 5 раз выше, спектр все тоже, плюс зеленый.
Да нет дальнего красного и дальнего синего, так и тут и на грани погрешности.
Мне кажется, было бы не плохо добавлять его как опцию к обычному конфигуратору, для тех кому это интересно.
По факту, все что мне попадалось, жутко тормозное, лагающее даже на мощно железе, и с нулевым юзабилити. Единственно желание которое возникает от знакомства с таким конфигуратором, поскорее закрыть его и найти на сайте PDF прайс, которой тоже часто искать приходиться с помощью магии.
Например, тот же конфигуратор тайоты съел примерно 20%-30% cpu i7-5600u.
Плюс массовость сообщения не влияет на то, является ли оно рассылкой или нет, рассылка может быть даже из одного сообщения, в законе о связи кол-во сообщений не указано.
На магистралях, как мне кажется пока ловить особо не чего( до тех пор пока цена не упадет до уровня обычного тягача ), расход на магистрали минимально возможный, технологии отработаны, целый ворох готовых узлов и компонентов, эко требования ниже, да и пробег на одной заправке сильно за 1000км.
В никсах есть проблемы, но синхронизация контактов и почты не из их числа.
К тому же outlook совершенно справедливо только ленивый не именовал outглюк.
Лично не сталкивался только с планирование переговорных, но думаю и это не слишком сложно, да и у администрации Мюнхена наверно на тысячи переговорных, чтобы это было реально проблемой.
Т.е. пока разберешься как надо, уже свой 10 раз сделаешь.
С push сложнее, но при бюджетах исчисляемых в миллионах евро и эта проблема решаема( при этом стоимость решения достаточно низкая и скорее всего где-нибудь это уже сделано, я просто не сталкивался ). Хотя не уверен, что лично я бы скинулся на push уведомления для чиновников, имхо и старый добрый pull для этих целей вполне приемлем.
Я оперирую терминами статьи, там сказано про почту, там не сказано про календари, встречи, интеграцию в AD и т.д. Да подобные вещи на Exchange сделать проще, но и на никсах это вполне подъемная задача.
Использовать линукс где угодно может кто угодно, вопрос в прикладном софте и документообороте, если он работает нормально, то не важно какая ОС, андройд же используют и IOS тоже, и никаких проблем.
А вот экономическое обоснования я бы почитал с огромным удовольствием. И не в стиле, пришлось поставить Exchange для смартфонов, это очевидная чушь для любого грамотного спеца, а с полным и исчерпывающим списком сложностей содержащим техническую и экономическую аннотацию.
Плюс к экономической части лучше относиться как к пилоту, поскольку подход является масштабируемым, а следовательно затраты можно будет размазать более ровным слоем, в отличии от лицензий.
В компании в которой я тружусь используется windows и, я полагаю, это экономически обосновано, но чужой опыт переходы на nix крайнее интересен.
Во вторых подобный специалист очень часто имеет зияющие дыры в базовых знаниях. Часто упустив, что-то в обучении или в систематизации знаний человек идет такими окольными путями, что замучаешься переобучать. Плюс очень сложно понять где человек может сделать ну просто дичайшую ошибку. Ты рассчитываешь, что если человек может умножить 20 на 30, то 2+2 он знает, а потом находишь там 5, наткнувшись случайно, и понимаешь, нужно делать полный аудит всего сделанного до текущего момента.
Шумы же сенсора, зависит от технологии, материалов и размера. Так, что два сенсора 1/2,55 и 1/2,3 вообще бессмысленно сравнивать не имея прочих параметров. Плюс есть еще много всего, что влияет на итоговое качество картинки, начиная от качества линз( при одинаковой «диафрагме» ) и заканчивая софтом.
По факту сравнивать имеет смысл только итоговый результат. Поскольку даже шумное, но четкое изображение, будет лучше не шумного, но вне фокуса, так что все эти параметры от лукавого, хотя при прочих равных «большая диафрагма» лучше( если она конечно не достигнута снижение требований к качеству изображения, например снижение четкости по углам ).
Все эти проблемы в случае высоко изолированных сервисов у вас будут. Только не в сетевом слое, который обсосан со всех сторон и как решать данные проблемы в общем понятно,, вам придется для всех этих проблем изобретать свои велосипеды, и натыкаться на потерю запросов, зависание запросов, нарушения порядка запросов в самых неожиданных местах, поскольку куча разного стороннего кода на такую работу не рассчитано.
Плюс сложности с разделением ресурсов, как аппаратных, когда у вас один модуль повесил остальные, так и программными, различными пулами и т.д.
К тому же сетевое взаимодействие у вас все равно осталось, с клиентами, с вешними сервисами, между инсталляциями и т.д., так что код для сетевого взаимодействия у вас никуда не делся.
У вас декларировано разделение данных, а значит все те же проблемы, что и в микросервисах, я бы даже сказал их ключевые проблемы, консистентность данных. eventual consistency, распределенные транзакции или просто нарушение консистентности, это уже решается для каждого проекта индивидуально.
Тут согласен, пожалуй это плюс. Но:
1) Зависимость от инструментов разработки, поскольку далеко не везде это работает.
2) Если инструменты разработки это проблему не решают проблема усугубляется по сравнению с микросервисами.
Вот, это как мне кажется ключевой момент. В тех проектах где такой подход можно использовать он избыточен, а где уже актуально, там не достаточен.
Я тоже не понимаю. Но mayorovp считает, что она есть.
То, что я вижу,
плюсы: отсутствие сетевого слоя
минусы: отсутствие раздельного деплоя, отсутствие разделение аппаратных и программных ресурсов, распределенные системы только полной установкой, длительная сборка и деплой, ограничение на выбор инструментов и языков, только единая среда выполнения и общие зависимости, отказ от многих стандартных инструментов которые активно используются в микросервисах.
Ключевые проблемы с данными остались и там и там, консистентность и агрегация.
Так с этого и началась ветка, недомикросервисы, со всеми их недостатками, но без многих достоинств. Честно, ни вижу ни одного плюса подобного похода( по сравнению с микросервисами ), который не был бы не лучшей практикой в микросервисах.
Например единый конфиг, никаких проблем сделать единый конфиг для микросервисов нет, только мне кажется очевидным, что это плохая идея, поскольку теряется независимость сервисов( модулей, проектов, не принципиально как назвать ), появляются издержки на коммуникацию в команде, на мерджи изменений, осложняется выделение сервиса, проекта, в отдельную команду/отсуорс/отдельному сотруднику.
Плюс куча ограничение на язык и среду разработки, чтобы поддерживать искусственно созданную изоляцию внутри монолита, сложности вводом новых людей в проект, проблемы которой вообще нет в микросервисах.