Для MVP вполне сойдет, но только такая архитектура впринципе не может мосштабироваться, кроме как вертикально. А с условием кол-ва кода на Lua выглядит, что удобнее было бы использовать тарантул. Из дополнительных плюшек - при последующей миграции сможете любым мкскульным драйвером подключиться и перенести данные как из обычной БД. И реализовав идеоматичный API использовать как полноценный сервис, а не размазывая логику между прилкой и хранилищем.
На нагрузках в десятки K rps даже заморачиваться не придется, а дальше поковырять в сторону экосистемных библиотек для шардирования.
Правильно, но ведь статья называется не "порядок эскалации конфликта", и не "политические аспекты ведения переговоров". Вы сами выбрали "запретный" посыл. И критика именно об этом. Повторю, я не призываю с первой встречи возить по столу любого контрагента, но и избегать каждого конфликта это не выход.
"Добрым словом и пистолетом вы можете добиться гораздо большего, чем одним только добрым словом" (с)
На проектах стлимостью в пару-тройку млн, действительно легко договариваться и улыбаться. Даже на десятке-другом все достаточно прозрачно и обозримо. Протерять что-то в ТЗ на таком объеме только по лютоиу раззвездяйству можно. Но в тех, что переваливали за сотню капекс - досудебные разбирательства и суды - обычное дело (7 из 12). Ключевая сложность: если цена переваливает до 100М крайне маловероятно, что все будет выполняться одним заказчиком. Наиболее вероятно - это 1 ген.подрядчик и каскад субчиков. И вот тут и начинается самое интересное: неучтенные требования от одного - это минус в марже другого. А сколько звеньев в цепочке субчиков едва ли кто-то ответит.
Я не рассматриваю внутренние проекты в рамках разных департаментов - тут как ни крути - оплата из одного кармана, а там где нет дележки прибыли - там особо и бадаться не за что. Если в такой ситуации люди (а тем более менеджеры) не могут договориться - это уже не проблема менеджмента, а, скорее, подбора, и решать её нужно соответствующим образом.
Но, понятие проектного менеджмента подразумевает унификацию и любой менеджер обязан уметь работать со всем возможным инструментарием для достижения своих целей: подкуп, шантаж и угрозы (если вдуматься, все к этому и сводится, просто названия более толерантные придумали). И вся моя критика направлена именно на стигматизацию более жесткого отстаивания своих позиций. Неопытного менеджера подобная рекомендация банально обезаружит.
Как уже писал - война - это продолжение дипломатии, не более того. Так же и фраза "НЕТ В ТЗ" - это один из аргументов, абсолютно легитимный и разумный, и в правильной ситуации он может помочь избавиться от десятков часов пустых коммуникаций. А напомню, задача менеджера не просто управлять, а делать жто эффективно. А эффективност, как известно, это частное от результата и затрат (в т.ч. на коммуникации, споры и дипломатию).
В моем примере сам заказчик, проигнорировал лояльность со стороны исполнителя и сотни человекочасов бесплатных работ сверх ТЗ, и начал выкручивать руки, когда мы воспользовались лазейкой, которая в этом ТЗ есть. Так что в данном случае нас приблизила к сдаче готовность защищать себя в суде, на основании того что в ТЗ ЕСТЬ а учитывая, что это концессия с госзаказчиком, точно еще и прокуратура подключилась бы. Так что это был тот самый момент, когда мы жертвуя "отношениями" пошли на осознанный конфликт и защитили свою компанию.
2019 год, сдаю заказчику (муниципалитет) концессионный проект по автоматизации некоторого процесса в части административного делопроизводства. И в рамках проекта необходимо было интегрировать разработанную систему с системами МВД. А мы работаем от муниципалитета. Для не погруженных - муниципалитет не может решать серьезные вопросы с министерством, только субъект.
И так вышло, что в рамках проекта субъект нам поддержку в диалоге с МВД не оказал. Разумеется, будучи коммерческой компанией, от лица муниципалитета с системами МВД нам никто не разрешил интегрироваться.
Но, ТЗ на нашу систему содержало фразу: "...при наличии технической и организационной возможности необходимо...". Организационную так и не подвезли, 11 регламентов взаимодействия нам завернули.
Идем сдаваться, демонстрируем все, а на месте интеграции - ручное заполнение (в формате официальных запросов на бумаге делопроизводство уже работало). Разумеется, заказчик недоволен. После длительного спора с ним апелирую к тому, что ЕСТЬ В ТЗ, получаю короткий ответ: "Я это ТЗ составлял, здесь этого быть не может, здесь этого нет." (В этот момент перед ним лежит открытый на нужной странице экземпляр концессии, подписанный живыми подписями главы города и прочих уполномоченных лиц). Занавес.
При этом мы им и дизайн несколько раз за свой счет меняли, чтоб соответствовал айдентике города, и дополнительные формы, сделали, чтоб удобнее, и кучу обучений провели, на связи были по любым вопросам, консультаций и т.п. (всего этого в ТЗ не было) как итог, вместо маржи в 7% на реализацию мы в минусе на 17М только в капекс проекта. Еще и с кассовым разрывом в 120М и перспективой суда, т.к. заказчик не хочет принимать по своему же ТЗ.
Мораль простая - там где деньги - человеческие отношения - это лишь инструмент манипуляций, не более того. Лучше научитесь разделять отношения и работу. Хорошими личными качествами профессионализм не заменить. (Верно и обратноное). Как известно, война - это продолжение дипломатии, и в этом контексте "ЭТО НЕТ В СОГОСОВАННОМ ТЗ" - это превосходный оберег от попыток продавить Вашу команду. Просто использовать каждый инструмент нужно правильно и своевременно. Но, однозначно, стигматизация этой фразы - это очень странно.
PS: проект сдали но через "человеческие отношения" с более уполномоченными людьми, т.к. всем было ясно, что суд мы выиграем и репутацию всем подмочим. Да и банкротить нас никому выгоды не было.
Отношения, штука, безусловно важная. Пока кому-то из участников не прижмет хвост. И как только что-то пошло не так с вашей стороны ни один адекватный заказчик не лишит себя привилегии "потыкать носом Вас и команду в то, что не реализовано то, что ЕСТЬ В ТЗ".
Задача любого начальника/заказчика/руководителя/менеджера не просто поставить задачу, а убедиться, что его поняли именно так, как он это представлял. И как раз ТЗ должно являться фиксацией того самого общего видения, которое сходится у заказчика и исполнителя. И как в таком случае, по мнению автора, сожно разделить банальное непонимание/неопытность/некомпетентность заказчика, который забыл указать какое-то, по его мнению не важное, уточнение (неважным оно ему кажется именно из-за не опытности) от намеренного искажения с целью снижения цены. Ведь в случае, например, большого проекта с частичной предоплатой, на поздних этапах из-за кассового разрыва исполнитель буквально становится заложником заказчика, т.к. он то на людей уже потратился. Если не полная предоплата - это вилы, тобой и с ТЗ крутят как угодно.
"Хороший человек - не профессия" и "Вежливость -главное орудие вора" - эти две народные мудрости глубже, чем кажется. Именно под маской отношений вытягиваю скидки, снижают цену, продавливаю допы. В любой трактовке - жто тот же сценарий win-loose, только в этом случае заказчик пытается выиграть больше за счет исполнителя. Не забывайте, вы делите ограниченный пирог, чем больше "отожмет" заказчик, тем меньше достанется исполнителю.
А что делать, если у вас есть "субчики" или просто другие команды, которые участвуют в реализации того же проекта? Ведь если НЕТ В ТЗ у Вас, соответственно и у них НЕТ В ТЗ. а тут возвращаемся к п.1. Составление ТЗ - это общая ответственность заказчика и исполнителя. Теперь просто подумайте, в описанной ситуации как вы будете с субподрядчиком общаться на тему доп.работ? Тоже без доп.оплаты? Они ж тоже, получается, недоисследовали/недопоняли/недодумали/не угадали. Или из своей компании вынете ресурс?
Я не хочу сказать, что нужно всех и каждого по матери за каждый косяк. Но что касается коммуникаций - поиск четкого взаимопонимания - это обоюдная задача. И, если заказчик хочет получить ожидаемый результат, у него нет иного пути, кроме детального погружения во все аспекты и контроля на всех этапах. И первый из них - убедиться а правильно ли его запрос поняли.
Прежде чем формировать свои ожидания от системы, пожалуйста, ознакомьтесь с предлагаемой документацией. А когда выбираете метод интеграции, не поленитесь, почитайте спецификации. В них часто все подробно описано, может быть несколько многословно, за то однозначно. Едва ли не половина всех обращений в ТП любого продукта - это просто несоответствие ожиданиям клиента. Люди не читают ни пользовательские соглашения (я тоже ленюсь, каюсь))), ни спецификации протоколов - а результат один: сервис плохой, ТП формально отписываются и вообще мир не справедлив.
Подойдем с обратной стороны: что мотивировало выбирать интеграцию именно посредством WebDAV? Это далеко не самый "удобный" протокол. Есть более "попсовый" REST, там и команд больше, описание русское, и список проверок от случайностей побольше.
Когда Вы монтируете сетевой диск и удаляете из него файл/папку - он(а) удаляется безвозвратно. Именно такоп поведение и реализуется посредством WebDAV.
Все вопросы и предупреждения "вы уверены..." при этом отображает клиент в виде файлового менеджера.
Вы сами выбрали работу именно через API и не стали подробно с ним разбираться. Если продукт не оправдывает Ваших ожиданий, очень часто дело именно в ожиданиях, а не в продукте.
Я понимаю Ваши эмоции, но в данном конкретном случае проблема находитс на стороне вашей ИС, а Вы обвиняете яндекс, что они не подстраховались на случай Вашей ошибки.
Ув.автор, не нужно обвинять компанию, если Вы, или Ваши разработчики не смогли/захотели качественно разобраться в документации API.
Несмотря на то, что сейчас яндекс диск наши конкуренты, ничего плохого об их реализация протокола WebDAV я сказать не могу. Все работает согласно спецификации протокола, и описанное поведение может управляться посредством API.
Что касается Ваших данных: естественно физическое удаление не производится ежесекундно и, с максимальной вероятностью, сами файлы на диске были лишь помечены на удаление и физически сотрутся позже. Но из дерева каталогов пользователя запись должна удаляться сразу, что логично. Иначе вы лишились бы возможности быстро менять один файл на другой и всегда ожидали бы его физического удаления. А это может происходить в течение длительного срока.
Но если бы, сотрудник яндекса смог вам их восстаровить - это означало бы, что сотрудники ТП могут спокойно просмотреть содержимое чужого облака. А это было бы грубейшим нарушением приватности и по сути делало бы облако публичным.
В свое время столкнулся с подобной задачей, только вместо диаграмм были маркеры на карте для Leaflet с дополнительным функционалов вроде окрашивания в различные цвета в зависимости от состояния, индикации различных состояний на внешнем контуре в виде сегментов. Ввиду необходимости серьезной кастомизации под собственные цели отказался от использования готовых библиотек. Писал сам, встраивание, управление стилями, свойствами — обычным jQuery.
В первой итерации попробовал канвас — получился примерно такой же код, как приведен автором — те же смещения, углы поворота, постоянная отрисовка. На 4K+ объектов в итоге начали ощущаться серьезные лаги, явное замедление скорости работы. Особенно при изменении масштаба карты.
В итоге переделал с помощью SVG. Как результат:
— ощутимый прирост скорости рендеринга,
— втрое меньше кода,
— из чего вытекает отсутствие даже самой необходимости использования сторонних решений (весь код управления маркером + логика поведения без шаблонов умещается на одном экране),
— и самый весомый плюс — масштабируемость без потери качества. Более того, даже сам шаблон не потребовал создания путей и прочих элементов.
Для круглого маркера: подложка+слои по количеству отрисовываемых сегментов.
Так что с целью «поиграться» может и подойдет canvas, но гораздо проще и красивее задачу можно решить с помощью SVG графики.
автоматически перегонять стадо с одного участка для выпаса на другой с помощью дронов
Очень амбициозный проект, но увы, оторванный от жизни. Сразу видно, что с предметной областью, и конкретно с животными, разработчики очень слабо знакомы))). В любом случае могу только пожелать удачи! Ну, и терпения, если когда попробуете работать с реальными животными — поймете о чем идет речь.
Не поймите не правильно, не с целью критиковать Ваш проект задаю вопросы. Я занимаюсь разработками в области интернета вещей и в том числе, один из проектных кейсов — это агрегация и анализ биометрических данных (правда не у животных, а у людей).
Но интернет вещей подразумевает какое-то M&M взаимодействие, автоматические сценарии реагирования на выявленные инциденты. Передача данных с датчика через дрон в облако едва ли укладывается в обозначенное понятие. Это скорее телематика (транспортная + телемедицина) + учет данных (назначение задачи оператору, учет поголовья). А разработки для интернета вещей — все же из другой области. Хотя с практической точки зрения отдельные элементы предложенного решения при интеграции с другими подсистемами могут вписаться в IoT.
PS. Насколько сложно расширять список поддерживаемых железок и доработка/создание сценариев? И где-то кейс уже удалось реализовать? Или это просто концепт?
Данные, полученные от датчиков, позволяют делать выводы о состоянии здоровья животного. Недавние исследования показали, что показатели акселерометра позволяют распознать до девяти различных болезней крупного рогатого скота.
А точно с «акселерометра» получают данные о состоянии здоровья животных. Просто, насколько мне известно, данный измерительный прибор преимущественно используют для определения изменения каких-либо скоростных характеристик. И каким образом их можно применить с целью диагностики заболеваний у животных. Тем более, что указано 9 заболеваний. Достаточно большая цифра для удаленной диагностики.
дроны-пастухи… дроны-ковбои...
Оригинальное название для летающей точки доступа…
Агрохолдинги и животноводческие хозяйства ставят перед собой несколько целей: учёт и увеличение поголовья животных, контроль пастбищ и полей, расширение площадей для выпаса, при этом без увеличения расходов на персонал. Поэтому в сельском хозяйстве сейчас идёт активное изучение и внедрение новых технологий для интернета вещей.
И разумеется, для этого не требуется привлекать квалифицированный технический персонал, занимающийся настройкой и обслуживанием оборудования. Не может внедрение новых технологий обойтись без расширения штата высококвалифицированного персонала, способного с этими технологиями совладать. В итоге, экономя на специалистах аграрного сектора, к слову, несколько более распространенных в регионах, в силу чего работающих за гораздо более низкое вознаграждение, владельцы поголовий/пастбищ буквально становятся заложниками оборудования и кадров, способных с ним работать.
Ну и о ценах: 25$ за агрегат в пересчете на поголовье, плюс дополнительные затраты на LoRa Wan оборудование + ремонт + запасной фон на период выхода из строя единиц… В общем, кейс конечно интересный, но серьезно оторванный от реальности.
PS.
На животных крепятся датчики: местоположения (GPS), движения (акселератор) и температуры. Датчики передают данные по технологии LoRa WAN на микрокомпьютер, установленный на квадрокоптере.
Флуд: Не смог удержаться. А закись озота к коровам не пристегивается))) акселератор
Для MVP вполне сойдет, но только такая архитектура впринципе не может мосштабироваться, кроме как вертикально. А с условием кол-ва кода на Lua выглядит, что удобнее было бы использовать тарантул. Из дополнительных плюшек - при последующей миграции сможете любым мкскульным драйвером подключиться и перенести данные как из обычной БД. И реализовав идеоматичный API использовать как полноценный сервис, а не размазывая логику между прилкой и хранилищем.
На нагрузках в десятки K rps даже заморачиваться не придется, а дальше поковырять в сторону экосистемных библиотек для шардирования.
Правильно, но ведь статья называется не "порядок эскалации конфликта", и не "политические аспекты ведения переговоров". Вы сами выбрали "запретный" посыл. И критика именно об этом. Повторю, я не призываю с первой встречи возить по столу любого контрагента, но и избегать каждого конфликта это не выход.
"Добрым словом и пистолетом вы можете добиться гораздо большего, чем одним только добрым словом" (с)
На проектах стлимостью в пару-тройку млн, действительно легко договариваться и улыбаться. Даже на десятке-другом все достаточно прозрачно и обозримо. Протерять что-то в ТЗ на таком объеме только по лютоиу раззвездяйству можно. Но в тех, что переваливали за сотню капекс - досудебные разбирательства и суды - обычное дело (7 из 12). Ключевая сложность: если цена переваливает до 100М крайне маловероятно, что все будет выполняться одним заказчиком. Наиболее вероятно - это 1 ген.подрядчик и каскад субчиков. И вот тут и начинается самое интересное: неучтенные требования от одного - это минус в марже другого. А сколько звеньев в цепочке субчиков едва ли кто-то ответит.
Я не рассматриваю внутренние проекты в рамках разных департаментов - тут как ни крути - оплата из одного кармана, а там где нет дележки прибыли - там особо и бадаться не за что. Если в такой ситуации люди (а тем более менеджеры) не могут договориться - это уже не проблема менеджмента, а, скорее, подбора, и решать её нужно соответствующим образом.
Но, понятие проектного менеджмента подразумевает унификацию и любой менеджер обязан уметь работать со всем возможным инструментарием для достижения своих целей: подкуп, шантаж и угрозы (если вдуматься, все к этому и сводится, просто названия более толерантные придумали). И вся моя критика направлена именно на стигматизацию более жесткого отстаивания своих позиций. Неопытного менеджера подобная рекомендация банально обезаружит.
Как уже писал - война - это продолжение дипломатии, не более того. Так же и фраза "НЕТ В ТЗ" - это один из аргументов, абсолютно легитимный и разумный, и в правильной ситуации он может помочь избавиться от десятков часов пустых коммуникаций. А напомню, задача менеджера не просто управлять, а делать жто эффективно. А эффективност, как известно, это частное от результата и затрат (в т.ч. на коммуникации, споры и дипломатию).
В моем примере сам заказчик, проигнорировал лояльность со стороны исполнителя и сотни человекочасов бесплатных работ сверх ТЗ, и начал выкручивать руки, когда мы воспользовались лазейкой, которая в этом ТЗ есть. Так что в данном случае нас приблизила к сдаче готовность защищать себя в суде, на основании того что в ТЗ ЕСТЬ а учитывая, что это концессия с госзаказчиком, точно еще и прокуратура подключилась бы. Так что это был тот самый момент, когда мы жертвуя "отношениями" пошли на осознанный конфликт и защитили свою компанию.
Автору на заметку из личной практики.
2019 год, сдаю заказчику (муниципалитет) концессионный проект по автоматизации некоторого процесса в части административного делопроизводства. И в рамках проекта необходимо было интегрировать разработанную систему с системами МВД. А мы работаем от муниципалитета. Для не погруженных - муниципалитет не может решать серьезные вопросы с министерством, только субъект.
И так вышло, что в рамках проекта субъект нам поддержку в диалоге с МВД не оказал. Разумеется, будучи коммерческой компанией, от лица муниципалитета с системами МВД нам никто не разрешил интегрироваться.
Но, ТЗ на нашу систему содержало фразу: "...при наличии технической и организационной возможности необходимо...". Организационную так и не подвезли, 11 регламентов взаимодействия нам завернули.
Идем сдаваться, демонстрируем все, а на месте интеграции - ручное заполнение (в формате официальных запросов на бумаге делопроизводство уже работало). Разумеется, заказчик недоволен. После длительного спора с ним апелирую к тому, что ЕСТЬ В ТЗ, получаю короткий ответ: "Я это ТЗ составлял, здесь этого быть не может, здесь этого нет." (В этот момент перед ним лежит открытый на нужной странице экземпляр концессии, подписанный живыми подписями главы города и прочих уполномоченных лиц). Занавес.
При этом мы им и дизайн несколько раз за свой счет меняли, чтоб соответствовал айдентике города, и дополнительные формы, сделали, чтоб удобнее, и кучу обучений провели, на связи были по любым вопросам, консультаций и т.п. (всего этого в ТЗ не было) как итог, вместо маржи в 7% на реализацию мы в минусе на 17М только в капекс проекта. Еще и с кассовым разрывом в 120М и перспективой суда, т.к. заказчик не хочет принимать по своему же ТЗ.
Мораль простая - там где деньги - человеческие отношения - это лишь инструмент манипуляций, не более того. Лучше научитесь разделять отношения и работу. Хорошими личными качествами профессионализм не заменить. (Верно и обратноное). Как известно, война - это продолжение дипломатии, и в этом контексте "ЭТО НЕТ В СОГОСОВАННОМ ТЗ" - это превосходный оберег от попыток продавить Вашу команду. Просто использовать каждый инструмент нужно правильно и своевременно. Но, однозначно, стигматизация этой фразы - это очень странно.
PS: проект сдали но через "человеческие отношения" с более уполномоченными людьми, т.к. всем было ясно, что суд мы выиграем и репутацию всем подмочим. Да и банкротить нас никому выгоды не было.
Вот тут категорически не согласен.
Отношения, штука, безусловно важная. Пока кому-то из участников не прижмет хвост. И как только что-то пошло не так с вашей стороны ни один адекватный заказчик не лишит себя привилегии "потыкать носом Вас и команду в то, что не реализовано то, что ЕСТЬ В ТЗ".
Задача любого начальника/заказчика/руководителя/менеджера не просто поставить задачу, а убедиться, что его поняли именно так, как он это представлял. И как раз ТЗ должно являться фиксацией того самого общего видения, которое сходится у заказчика и исполнителя. И как в таком случае, по мнению автора, сожно разделить банальное непонимание/неопытность/некомпетентность заказчика, который забыл указать какое-то, по его мнению не важное, уточнение (неважным оно ему кажется именно из-за не опытности) от намеренного искажения с целью снижения цены. Ведь в случае, например, большого проекта с частичной предоплатой, на поздних этапах из-за кассового разрыва исполнитель буквально становится заложником заказчика, т.к. он то на людей уже потратился. Если не полная предоплата - это вилы, тобой и с ТЗ крутят как угодно.
"Хороший человек - не профессия" и "Вежливость -главное орудие вора" - эти две народные мудрости глубже, чем кажется. Именно под маской отношений вытягиваю скидки, снижают цену, продавливаю допы. В любой трактовке - жто тот же сценарий win-loose, только в этом случае заказчик пытается выиграть больше за счет исполнителя. Не забывайте, вы делите ограниченный пирог, чем больше "отожмет" заказчик, тем меньше достанется исполнителю.
А что делать, если у вас есть "субчики" или просто другие команды, которые участвуют в реализации того же проекта? Ведь если НЕТ В ТЗ у Вас, соответственно и у них НЕТ В ТЗ. а тут возвращаемся к п.1. Составление ТЗ - это общая ответственность заказчика и исполнителя. Теперь просто подумайте, в описанной ситуации как вы будете с субподрядчиком общаться на тему доп.работ? Тоже без доп.оплаты? Они ж тоже, получается, недоисследовали/недопоняли/недодумали/не угадали. Или из своей компании вынете ресурс?
Я не хочу сказать, что нужно всех и каждого по матери за каждый косяк. Но что касается коммуникаций - поиск четкого взаимопонимания - это обоюдная задача. И, если заказчик хочет получить ожидаемый результат, у него нет иного пути, кроме детального погружения во все аспекты и контроля на всех этапах. И первый из них - убедиться а правильно ли его запрос поняли.
Абсолютно верный комментарий от khajiit.
Прежде чем формировать свои ожидания от системы, пожалуйста, ознакомьтесь с предлагаемой документацией. А когда выбираете метод интеграции, не поленитесь, почитайте спецификации. В них часто все подробно описано, может быть несколько многословно, за то однозначно. Едва ли не половина всех обращений в ТП любого продукта - это просто несоответствие ожиданиям клиента. Люди не читают ни пользовательские соглашения (я тоже ленюсь, каюсь))), ни спецификации протоколов - а результат один: сервис плохой, ТП формально отписываются и вообще мир не справедлив.
Подойдем с обратной стороны: что мотивировало выбирать интеграцию именно посредством WebDAV? Это далеко не самый "удобный" протокол. Есть более "попсовый" REST, там и команд больше, описание русское, и список проверок от случайностей побольше.
Когда Вы монтируете сетевой диск и удаляете из него файл/папку - он(а) удаляется безвозвратно. Именно такоп поведение и реализуется посредством WebDAV.
Все вопросы и предупреждения "вы уверены..." при этом отображает клиент в виде файлового менеджера.
Вы сами выбрали работу именно через API и не стали подробно с ним разбираться. Если продукт не оправдывает Ваших ожиданий, очень часто дело именно в ожиданиях, а не в продукте.
Я понимаю Ваши эмоции, но в данном конкретном случае проблема находитс на стороне вашей ИС, а Вы обвиняете яндекс, что они не подстраховались на случай Вашей ошибки.
Ув.автор, не нужно обвинять компанию, если Вы, или Ваши разработчики не смогли/захотели качественно разобраться в документации API.
Несмотря на то, что сейчас яндекс диск наши конкуренты, ничего плохого об их реализация протокола WebDAV я сказать не могу. Все работает согласно спецификации протокола, и описанное поведение может управляться посредством API.
Что касается Ваших данных: естественно физическое удаление не производится ежесекундно и, с максимальной вероятностью, сами файлы на диске были лишь помечены на удаление и физически сотрутся позже. Но из дерева каталогов пользователя запись должна удаляться сразу, что логично. Иначе вы лишились бы возможности быстро менять один файл на другой и всегда ожидали бы его физического удаления. А это может происходить в течение длительного срока.
Но если бы, сотрудник яндекса смог вам их восстаровить - это означало бы, что сотрудники ТП могут спокойно просмотреть содержимое чужого облака. А это было бы грубейшим нарушением приватности и по сути делало бы облако публичным.
В первой итерации попробовал канвас — получился примерно такой же код, как приведен автором — те же смещения, углы поворота, постоянная отрисовка. На 4K+ объектов в итоге начали ощущаться серьезные лаги, явное замедление скорости работы. Особенно при изменении масштаба карты.
В итоге переделал с помощью SVG. Как результат:
— ощутимый прирост скорости рендеринга,
— втрое меньше кода,
— из чего вытекает отсутствие даже самой необходимости использования сторонних решений (весь код управления маркером + логика поведения без шаблонов умещается на одном экране),
— и самый весомый плюс — масштабируемость без потери качества. Более того, даже сам шаблон не потребовал создания путей и прочих элементов.
Для круглого маркера: подложка+слои по количеству отрисовываемых сегментов.
Так что с целью «поиграться» может и подойдет canvas, но гораздо проще и красивее задачу можно решить с помощью SVG графики.
Очень амбициозный проект, но увы, оторванный от жизни. Сразу видно, что с предметной областью, и конкретно с животными, разработчики очень слабо знакомы))). В любом случае могу только пожелать удачи! Ну, и терпения,
есликогда попробуете работать с реальными животными — поймете о чем идет речь.Но интернет вещей подразумевает какое-то M&M взаимодействие, автоматические сценарии реагирования на выявленные инциденты. Передача данных с датчика через дрон в облако едва ли укладывается в обозначенное понятие. Это скорее телематика (транспортная + телемедицина) + учет данных (назначение задачи оператору, учет поголовья). А разработки для интернета вещей — все же из другой области. Хотя с практической точки зрения отдельные элементы предложенного решения при интеграции с другими подсистемами могут вписаться в IoT.
PS. Насколько сложно расширять список поддерживаемых железок и доработка/создание сценариев? И где-то кейс уже удалось реализовать? Или это просто концепт?
А точно с «акселерометра» получают данные о состоянии здоровья животных. Просто, насколько мне известно, данный измерительный прибор преимущественно используют для определения изменения каких-либо скоростных характеристик. И каким образом их можно применить с целью диагностики заболеваний у животных. Тем более, что указано 9 заболеваний. Достаточно большая цифра для удаленной диагностики.
Оригинальное название для летающей точки доступа…
И разумеется, для этого не требуется привлекать квалифицированный технический персонал, занимающийся настройкой и обслуживанием оборудования. Не может внедрение новых технологий обойтись без расширения штата высококвалифицированного персонала, способного с этими технологиями совладать. В итоге, экономя на специалистах аграрного сектора, к слову, несколько более распространенных в регионах, в силу чего работающих за гораздо более низкое вознаграждение, владельцы поголовий/пастбищ буквально становятся заложниками оборудования и кадров, способных с ним работать.
Ну и о ценах: 25$ за агрегат в пересчете на поголовье, плюс дополнительные затраты на LoRa Wan оборудование + ремонт + запасной фон на период выхода из строя единиц… В общем, кейс конечно интересный, но серьезно оторванный от реальности.
PS.
Флуд: Не смог удержаться. А закись озота к коровам не пристегивается)))
акселератор