Это спорный момент. Думаю не всё так просто. Дело в том, что нагрести грунта в мешки — задача довольно хорошо механизируемая и автоматизируемая. В ней мало «подводных» камней, простите за каламбур.
Верхние слои грунта исследованы хорошо, понятно чего ждать и всегда можно переехать и собирать поверхностный грунт в другом месте. Полные мешки легко транспортировать, а можно транспортировать насыпной грунт и набивать мешки на месте строительства. Можно заливать в эти мешки потом композит, для дополнительного связывания. Пустые же мешки компактны и легки, их легко закидывать на поверхность без особых затрат на приземление — им ничего не будет от удара жесткой посадки на малом парашюте.
А, вот, что если при бурении мы столкнулись с каменюкой, который не можем «разгрызть»? Если на Земле можно заморозить строительство, подтянуть технику, удобно исследовать все детально в забое, то на Марсе это сплошной риск.
А мне кажется нужны нормальные решения для почты, очереди заказа материалов из большого интернета, реплицируемого хранилища с вики и базой научных статей.
Кроме этого нужно большую модерируемую специализированную вики по темам, важным в экспедиции.
Даже на больших океанских судах, которые в приполярных широтах плавают, такие решения не помешали бы.
Тут, «на берегу», такие вещи подготовить легко, а там городить и костылить из роутеров и ноутбука… не, это не серьёзно. Я за симметричное развитие технологий. А-то на марс прилетели, а связь на уровне телеграфа и голубиной почты (условно).
Я бы еще подчеркнул необходимость в унификации всего. Чтобы все компоненты всех приборов и агрегатов были как лего, могли легко разбираться, собираться и стыковаться в любом стандарт или нестандартном сочетании. Даже если это повлечет за собой меньшую эффективность или больший вес оборудования, всё равно выигрыш от ремонтопригодности и унификации будет больше.
Ещё важная вещь — это марсианский интернет. Нужна гибкая и толерантная к изоляции сетевая инфраструктура. У экспедиции будет полно проблем и сложностей, ни к чему пополнять этот список проблемами со связностью, безопасностью и маршрутизацией. По аналогии с первым пунктом этого комментария все сетевые технологии должны быть построены как то же самое лего, когда всё ко всему можно подключить, всё через всё можно пробросить. Унификация и стандартизация должна пронизывать не только аппаратное обеспечение, но и программный абстрактный слой медиапространства для связи и управления всем оборудованием.
периодически забываю ставить запятые. А также не нравится обязательное заключение параметров и их значения в кавычки
Да это, прям. антипаттерн какой-то для мотивации создания нового формата.
Эдак если кто ошибается в «ться/тся» постоянно, то можно правила подкорректировать,
Прелесть обязательных кавычек в том, что эти правила останутся неизменными если в ключе у вас встретится "=" по какой-то причине.
Кстати, на счет комментарием в данных — это интересный подход.
Беда форматов типа json с комментариями в том, что при программной обработке и пересериализации данных эти комментарии, как вариативное форматирование исчезают. И не понятно как их вернуть или разместить при программной генерации файла.
Особый формат ключа, конечно, тот ещё способ по универсальности… но занести комментарии или, если смотреть шире, докстринги, прямо в синтаксис — это идея интересная, как мне кажется.
Кстати, о колёсах. Это ж надо было нормальные пакеты подготовить для основных языков, покрыть тестами код, замеры производительности те же самые.
Ещё большое беспокойство вызывает экранирование. Надо, конечно, разбираться и погружаться, но во всяких настройках часто урлы, айпи-адреса, пути встерчаются, всякие уникодные штуки… как с ними этот формат себя поведёт, как синтаксис устоит…
Непростое это дело — новые форматы изобретать.
Вы немножко неправильно представляете себе принципы работы сельского туалета.
Вы хотите сказать, что датчик должен показывать, когда сортир пора переставлять, а яму закапывать?
С датчиком движения тоже промах — живность ходит по двору.
На счет этого умные дома тоже обычно обучают правильно реагировать. Если у вас по двору не ходит корова, то датчик вполне реально отрегулировать по чувствительности и зоне срабатывания. Правильно расположенный датчик не будет «видеть» ближнюю зону, где шныряют коты, а дальняя будет игнорироваться за счет отрегулированной чувствительности. Еще датчик можно поставить внутри кабинки и в совокупности с датчиком закрытия двери мы получим надежный источник информации о наличии присяжного заседателя на троне.
Положение щеколды — это хороший индикатор занятости для человека, но связывать с ней логику включения освещения не всегда хороший вариант. Да и некоторые, наверно любят держать дверь открытой=)
Кстати о щеколде. В качестве неё можно сейчас использовать старый айфон. У него есть датчик положения и беспроводный интерфейс, а заряжать можно раз в неделю.
Давайте я попробую угадать «правильный» ответ=).
У YAML по сравнению с thindf есть два недостатка: первый — это некоторая «излишняя переусложнённость», а второй недостаток фатальный.=)
Вообще я открывал эту статью с мыслью, что уж теперь-то, запостив такую статью на хабр, автор, наверно, прикрыл все слабые места и придумал ответы на все каверзные вопросы про сравнение с yaml, про распространённость, про самопальность, про модифицируемость, про скорость… Но нет.
К сожалению нет.
Как бы ни был бесполезен очередной велосипед, если этот велосипед продуман и сделан хорошо, если он не лишен изящества и не блещет квадратными колёсами, то это уже интересно. Просто как ход мыслей или ход инженерной разработки.
Я ожидал в этой статье увидеть сравнительные замеры скорости парсинга, сравнения в эффективности представления тех или иных конструкций (не только с одним json, но и с прочими конкурентами),
Вот-вот. Начинаешь об этом задумываться и становится не по себе. Когнитивные искажения, иллюзия контроля… люди врут и лучше всего врут самому себе, потому что в этом у них максимальный опыт. Врут и не осознают этого. Врут, когда объясняют свою мотивацию в том или ином поступке. И тут назревает вопрос, а правильное ли это слово «врут», если толком этого даже не осознают?
Чертовски интересная, скользкая и неуютная тема.
При достаточной мощности коггерентной подсветки распознаваемого объекта можно раздесть цель… до костей.
Ну или распознающую апертуру совместить соосно с огнестрельным оружием и проецировать лазером надпись «раздевайся».
Я постарался пояснить свою классификацию глобальной/локальной карты. Для меня карта глобальная, если у неё есть абсолютная привязка, которая что-то значит для нескольких ориентирующихся сущностей. Локальная карта — это карта, которую бот строит и использует только сам.
Если бот заколеьцевал и тем самым уточнил локальную карту, то от этого она и останется локальной. Если боты скинули свои карты в облако и на их основе была синтезирована единая карта в единой системе координат — это глобальная карта. Не вижу причин не привязывать локальную координатную сетку к глобальной при первом удобном случае.
Здорово! Ждём. Всегда интересны альтернативные подходы и нюансы в интересных задачах.
Я считал, что локальной картой стоит считать карту, имеющую максимальную актуальность в окрестности бота. Координаты здесь абсолютные, но локальные, заданные от произвольной точки начала ориентирования.
Глобальная карта — это карта, полученная извне с привязкой к абсолютным координатам. В этом случае мы можем её уточнять и ориентироваться по ней.
В общем для изолированного бота глобальной карты не будет. Откуда он возьмёт глобальную привязку?
А кто мешает отдельно использовать видеокамеру в очках или в системе видеонаблюдения, или в видеорегистраторе автомобиля? Эти приборы запоминают время, а значит можно свести всё в единый таймлайн. Идеально, конечно, заполучить полное логгирование всего что происходит в мире, но это невозможно на любом, даже минимально полезном уровне.
Аудиотреккер о котором речь, задумывался как аналог видеорегистратору автомобиля. Там это способ записать дорожную ситуацию. номера автомобилей и т.д. Аудиотреккер — это способ расширения возможностей памяти. Достаточно что-то произнести вслух или услышать, и оно останется в таймлайне вашего трекера, к этой информации можно вернуться, её можно поискать в виде текста.
Постоянно носимая камера при сегодняшних технологиях не будет добавлять достаточно пользы, чтобы покрыть трудности и неудобства связанные с её наличием, анализом данных с неё, с распознаванием и индексацией попавшей в кадр информации.
Когда-то то же самое можно было сказать и про звук. Тогда были кассетные диктофоны и не было проблемой записать диалог по нажатию кнопки, но делать постоянно работающий аудио-регистратор, хотя и возможно, но несопоставимо проблематично. Сейчас технологии замечательно вмещают недели звука на MicroSD с ноготь мизинца. Сейчас технологии распознавания голоса проиндексируют речь в облаке быстро и незаметно, а смартфон позволит наглядно сёрфить по этим логам и тегам.
Когда-нибудь, я уверен, технология дойдёт до аналогичных возможностей и применимо к видео-потоку, но это точно не сегодня. Человечество, ведь, пришло уже к фитнес-трекерам. которые считают шаги постоянно. а не только во время тренировок. А звук мы можем писать и сейчас. Ничто не мешает воплотить этот гаджет кроме неочевидности полезности.
Кстати, наверняка смартфон очень быстро полностью покроет функциональность этого гаджета как только эта функциональность станет очевидно полезной. Сейчас, к сожалению, конструктивно смартфоны не приспособлены вести непрерывную запись из-за экономии батарейки.
А по-вашему люди это замкнутая система? Или тоже нет, ведь они получают энергию от мяса коров? А автомобильный холодильник с солнечной батареей сразу станет живым? Или теперь вы прицепитесь к самовоспроизводству? Но отдельно взятый человек не может самовоспроизвестись. Если вирус — это запчасть, то почему человек — это не запчасть для системы питания и размножения холодильников? Или начнём жонглировать фактами и предпосылками наделяя отдельные следствия надуманными причинами?
Жизнь — это одно из понятий, которые отлично распознаются и определяются в больших масштабах, но на некотором уровне выявляется серая область. которая из-за старика Гёделя не даёт определить всё на свете.
Верхние слои грунта исследованы хорошо, понятно чего ждать и всегда можно переехать и собирать поверхностный грунт в другом месте. Полные мешки легко транспортировать, а можно транспортировать насыпной грунт и набивать мешки на месте строительства. Можно заливать в эти мешки потом композит, для дополнительного связывания. Пустые же мешки компактны и легки, их легко закидывать на поверхность без особых затрат на приземление — им ничего не будет от удара жесткой посадки на малом парашюте.
А, вот, что если при бурении мы столкнулись с каменюкой, который не можем «разгрызть»? Если на Земле можно заморозить строительство, подтянуть технику, удобно исследовать все детально в забое, то на Марсе это сплошной риск.
Кроме этого нужно большую модерируемую специализированную вики по темам, важным в экспедиции.
Даже на больших океанских судах, которые в приполярных широтах плавают, такие решения не помешали бы.
Тут, «на берегу», такие вещи подготовить легко, а там городить и костылить из роутеров и ноутбука… не, это не серьёзно. Я за симметричное развитие технологий. А-то на марс прилетели, а связь на уровне телеграфа и голубиной почты (условно).
Ещё важная вещь — это марсианский интернет. Нужна гибкая и толерантная к изоляции сетевая инфраструктура. У экспедиции будет полно проблем и сложностей, ни к чему пополнять этот список проблемами со связностью, безопасностью и маршрутизацией. По аналогии с первым пунктом этого комментария все сетевые технологии должны быть построены как то же самое лего, когда всё ко всему можно подключить, всё через всё можно пробросить. Унификация и стандартизация должна пронизывать не только аппаратное обеспечение, но и программный абстрактный слой медиапространства для связи и управления всем оборудованием.
Да это, прям. антипаттерн какой-то для мотивации создания нового формата.
Эдак если кто ошибается в «ться/тся» постоянно, то можно правила подкорректировать,
Прелесть обязательных кавычек в том, что эти правила останутся неизменными если в ключе у вас встретится "=" по какой-то причине.
Кстати, на счет комментарием в данных — это интересный подход.
Беда форматов типа json с комментариями в том, что при программной обработке и пересериализации данных эти комментарии, как вариативное форматирование исчезают. И не понятно как их вернуть или разместить при программной генерации файла.
Особый формат ключа, конечно, тот ещё способ по универсальности… но занести комментарии или, если смотреть шире, докстринги, прямо в синтаксис — это идея интересная, как мне кажется.
Ещё большое беспокойство вызывает экранирование. Надо, конечно, разбираться и погружаться, но во всяких настройках часто урлы, айпи-адреса, пути встерчаются, всякие уникодные штуки… как с ними этот формат себя поведёт, как синтаксис устоит…
Непростое это дело — новые форматы изобретать.
Вы хотите сказать, что датчик должен показывать, когда сортир пора переставлять, а яму закапывать?
На счет этого умные дома тоже обычно обучают правильно реагировать. Если у вас по двору не ходит корова, то датчик вполне реально отрегулировать по чувствительности и зоне срабатывания. Правильно расположенный датчик не будет «видеть» ближнюю зону, где шныряют коты, а дальняя будет игнорироваться за счет отрегулированной чувствительности. Еще датчик можно поставить внутри кабинки и в совокупности с датчиком закрытия двери мы получим надежный источник информации о наличии присяжного заседателя на троне.
Положение щеколды — это хороший индикатор занятости для человека, но связывать с ней логику включения освещения не всегда хороший вариант. Да и некоторые, наверно любят держать дверь открытой=)
Кстати о щеколде. В качестве неё можно сейчас использовать старый айфон. У него есть датчик положения и беспроводный интерфейс, а заряжать можно раз в неделю.
У YAML по сравнению с thindf есть два недостатка: первый — это некоторая «излишняя переусложнённость», а второй недостаток фатальный.=)
Вообще я открывал эту статью с мыслью, что уж теперь-то, запостив такую статью на хабр, автор, наверно, прикрыл все слабые места и придумал ответы на все каверзные вопросы про сравнение с yaml, про распространённость, про самопальность, про модифицируемость, про скорость… Но нет.
К сожалению нет.
Как бы ни был бесполезен очередной велосипед, если этот велосипед продуман и сделан хорошо, если он не лишен изящества и не блещет квадратными колёсами, то это уже интересно. Просто как ход мыслей или ход инженерной разработки.
Я ожидал в этой статье увидеть сравнительные замеры скорости парсинга, сравнения в эффективности представления тех или иных конструкций (не только с одним json, но и с прочими конкурентами),
Чертовски интересная, скользкая и неуютная тема.
Ну или распознающую апертуру совместить соосно с огнестрельным оружием и проецировать лазером надпись «раздевайся».
Если бот заколеьцевал и тем самым уточнил локальную карту, то от этого она и останется локальной. Если боты скинули свои карты в облако и на их основе была синтезирована единая карта в единой системе координат — это глобальная карта. Не вижу причин не привязывать локальную координатную сетку к глобальной при первом удобном случае.
Я считал, что локальной картой стоит считать карту, имеющую максимальную актуальность в окрестности бота. Координаты здесь абсолютные, но локальные, заданные от произвольной точки начала ориентирования.
Глобальная карта — это карта, полученная извне с привязкой к абсолютным координатам. В этом случае мы можем её уточнять и ориентироваться по ней.
В общем для изолированного бота глобальной карты не будет. Откуда он возьмёт глобальную привязку?
Аудиотреккер о котором речь, задумывался как аналог видеорегистратору автомобиля. Там это способ записать дорожную ситуацию. номера автомобилей и т.д. Аудиотреккер — это способ расширения возможностей памяти. Достаточно что-то произнести вслух или услышать, и оно останется в таймлайне вашего трекера, к этой информации можно вернуться, её можно поискать в виде текста.
Постоянно носимая камера при сегодняшних технологиях не будет добавлять достаточно пользы, чтобы покрыть трудности и неудобства связанные с её наличием, анализом данных с неё, с распознаванием и индексацией попавшей в кадр информации.
Когда-то то же самое можно было сказать и про звук. Тогда были кассетные диктофоны и не было проблемой записать диалог по нажатию кнопки, но делать постоянно работающий аудио-регистратор, хотя и возможно, но несопоставимо проблематично. Сейчас технологии замечательно вмещают недели звука на MicroSD с ноготь мизинца. Сейчас технологии распознавания голоса проиндексируют речь в облаке быстро и незаметно, а смартфон позволит наглядно сёрфить по этим логам и тегам.
Когда-нибудь, я уверен, технология дойдёт до аналогичных возможностей и применимо к видео-потоку, но это точно не сегодня. Человечество, ведь, пришло уже к фитнес-трекерам. которые считают шаги постоянно. а не только во время тренировок. А звук мы можем писать и сейчас. Ничто не мешает воплотить этот гаджет кроме неочевидности полезности.
Кстати, наверняка смартфон очень быстро полностью покроет функциональность этого гаджета как только эта функциональность станет очевидно полезной. Сейчас, к сожалению, конструктивно смартфоны не приспособлены вести непрерывную запись из-за экономии батарейки.
Жизнь — это одно из понятий, которые отлично распознаются и определяются в больших масштабах, но на некотором уровне выявляется серая область. которая из-за старика Гёделя не даёт определить всё на свете.