Почитал про вандалов-покемоноводов и задумался теперь делать-таки свою геолокационную игру или нет… Если да, то как защищать ОСМ от вандализма, а игровой баланс от ГИСовых читеров.
Ага, уже поставил давно, но это для самомотивированных высокоорганизованных альтруистов.
Нужно, к примеру, разметить пандусы, чтобы сделать построение маршрута для маломобильных граждан. Тут геймификация и краудсорсинг напрашиваются сами собой. Да, КПД будет в единицах процентов, но тут уж хоть шерсти клок. Качество можно взять количеством подтверждений.
Мне кажется OSM не хватает (в том числе) немного геймификации. Вспомните с каким упоением народ бегал когда-то по городам и сёлам сражаясь в Ингресс. Гугл тогда заполучил в своё распоряжение, надо полагать, все до единого памятиники, стеллы, ротонды и достопримечательности, которые можно было сфотографировать и привязать к точке.
А ведь можно в таком же режиме дополненной реальности и с тем же азартом наперегонки промаркировать подъезды, шлагбаумы, знаки, магазины… Что-то эдакое игровое обязательно нужно сделать. Пусть на выходе получатся сырые данные, пусть КПД не так велик, как у обученных и дотошных энтузиастов, но приобщить к хорошему великую силу игровой мотивации обычных людей, не готовых осваивать что-то сложное.
Можно сделать бота, который притворяясь человеком бдит денно и нощно и детектит все отредактированные и удалённые сообщения, чтобы переслать их хозяину в отдельный канал в первозданном виде прямо в момент редактирования или удаления.
Наверно такое можно даже за деньги предлагать=).
Идею дарю. Хотя 100% уже кто-то додумался и сделал.
Всегда же интересно всякие паблики и каналы помониторить на предмет нечаянных сливов и зашкваров, которые долго в истории не провисят.
Можно сделать в обычной файловой системе пайп, куда питоновский скрипт будет выводить байты картинки.
Можно, наверно, не имя файла передавать, а открытый и доступный для чтения поток, следовательно можно было обойтись потоком `io.BytesIO`.
А ещё нет никакого смысла хранить тысячи файлов, если рендер на лету такой картинки сопоставим по времени с загрузкой её с диска.
Можно даже сделать виртуальную файловую систему, которая на запрос открытия любого файла будет генерить на лету и возвращать картинку с нарисованным именем этого файла и в запрошенном формате.
О сколько странных извращений даёт нам Python совершать.
Не в этот раз. Многие узнали про замечательную библиотеку, способную работать в качестве клиента. Кто-то не знал или просто не думал о возможности автоматической замены фото в Телеграме. Короче, это точно не троллейбус, но даже если и трамвай, всё же как пример кулинарного DIY сгодится.
А почему нет? При использовании докера можно не использовать virtualenv. Просто нет никакого смысла.
…
[Да уж… надо обновлять комментарии, иначе можно оказаться очень «оригинальным»]
Слыхал была где-то военная часть, которая специальный наряд выставляла по расписанию переворачивать крашенные доски на склоне холма так, чтобы они формировали цифры и показывали дату или время для разместившегося в долине города.
Эти ж доски теоретически можно и на дверные петли прикрутить, а дёргать тросиками.
Но на салдатской тяге такие часы, судя по всему, вообще неубиваемые.
А самое замечательное, как я понял, это контроль высоты за счет приёма модулированного сигнала с инфракрасного датчика. Фактически это простейший инфракрасный дальномер.
Я так понимаю там программно PID-регулятор реализован, чтобы балансировать на грани детектирования поверхности? Посмотреть бы что выдаёт осциллограф с ИК-приёмника при изменении расстояния до препятствия.
В основном в путанице с UTC и tzinfo. Время-то бывает очень разное, там есть всякие нюансы с монотонностью, високосными секундами и прочим. А сейчас в питоне это как-то сумбурно все, мне кажется тут тоже не помешает дополнительный слой абстракции.
Я не предлагаю numpy в стандартную библиотеку включать. Иногда numpy — это оверкилл, а нужно лишь парочку векторных операций в пространстве сделать. Вот на плоскости хорошо решает этот вопрос использование complex для векторных вычислений. Чтобы не вводить гиперкомплексные числа можно просто добавить векторный тип и матрицы. Хотя… Возможно numpy и не такой уж оверкилл тогда.
Вот ещё бы так навели порядок в работе с датами и временем. А-то наследие малость устарело, мне кажется.
Ну и не хватает стандартных векторных типов, чтобы не numpy подключать, а нативно векторную алгебру покрыть вместе с афинными преобразованиями.
А ещё прикольно было бы чатик, как у Radio-T.
Кстати, почему ещё никто не додумался сделать специально для подкастов чатик с таймкодами? Грубо говоря в ссылку на чат передаётся таймкод и масштабный коэффициент скорости прослушивания. С этого момента браузер воспроизводит состояние чата на момент, который в это же время играет в плеере.
Видимо нужна специальная поддержка такой фичи в подкаст-плеерах, но на собственных страничках подкастов, вроде того же радио-т, такое можно запилить вообще без проблем.
Если даже у подкаста нет прямого эфира и в чатик пишут только ведущие, то это всё равно киллер фича, поскольку не нужно бегать по описанию и искать именно ту ссылку, о которой сейчас говорят.
А какие именно проблемы? Можете сделать мне максимально простой скрипт, который демонстрирует их? Мне кажется я смогу подсказать вам как решать их систематически.
За GMT отдельное спасибо. Я как-то умудрился не заметить этот инструментище.
Может быть имеет смысл ещё и с графикой работать в CLI? Вообще бы здорово получилось — всё описание карты в виде скрипта.
Мне видится что-то наподобие этого.
Там с обратной стороны прищепка на одежду.
Только тут с шнурами возиться чтобы на зарядку ставить… так себе.
Лучше, конечно, чтобы из него под колпачком прям USB торчал, как у флешки.
Короче пофиг какая форма, нужно лишь чтобы на прищепке можно было на воротник повесить и не удушиться. Плюс, желательно, чтобы прям как есть в USB втыкалось на зарядку.
Вот как-то так, только экран не нужен.
Я понимаю, поэтому прибор будет позиционироваться подчеркнуто бытовым. Надеюсь пронесёт. Звук планирую шифровать асимметрично так, чтобы информации в регистраторе было недостаточно для расшифровки, только для шифрования. В прототипе шифрования, конечно, не будет. Нужно это, чтобы при краже или потере устройства не допустить утечку большого количества информации. Чтобы предотвратить возможность расшифровки можно удалить дешифрующий ключ с перекодирующей машины. Этот ключ опционально можно шифровать мастер-паролем, тогда его придётся вводить при подключении изделия на зарядку.
STM32
Да, я много слышал об этом контроллере и о том, что знающие люди искренне не понимают почему ардуина по-прежнему настолько популярна, когда есть STM32. Я его даже в руках держал, если именно этот чип стоит в ESP8266. Но не более.
АДИКМ
А как вы думаете, что более энергозатратно: кодировать этим кодеком или писать сырой поток на флеш-карту?
Мне кажется я буду сильно упираться в батарейку. Хочется хотя бы 2-3 суток запаса автономной работы, чтобы можно было заряжать хотя бы ежедневно.
сигнал усиливается, потом проходит несколько ступеней ослабления, и каждая ступень заводится на свой вывод АЦП. А контроллер смотрит с какого брать сигнал, и тем самым подбирает уровень.
Вот тут не понял. Это чтобы динамический диапазон так повысить? Или это альтернатива подачи смещения с ЦАПа? Вроде нет, вроде похоже что речь о расширении динамического диапазона. Типа АЦП, у нас, к примеру, 12 бит, а нам надо 16. Берём и… что? смещаем центральную точку (или как там она называется) операционника по-разному для каждого канала АЦП, а потом вставляем в поток сигнал с самого релевантного канала АЦП умножая его на нужный коэффициент? Блин… звучит как рокет-сайнс. Как подбирать уровни ослабления? Как калибровать? Это отдельные операционники вообще? Да и про операционный усилитель я так… понаслышке знаю=).
Наверно про ослабления речь шла в контексте банальных резисторов. Да? Типа после операционника усиленный сигнал раздваивается и через разные резисторы поступает наразные каналы АЦП, а мы потом выбираем тот канал, который сильнее всего скачет? Только не смейтесь=)
Для прототипа можно сделать битрейт… хм… какой получится. Надо попробовать. Нету у меня опыта в таких вещах. Не знаю как звучать будет, как распознаваться потом такое будет…
Но, при минимализме, можно поставить классический стабилизатор тока на одном транзисторе, а остальное написать программно в контроллере.
Чем меньше кода, тем меньше ошибок и неожиданных побочных эффектов. Я за аппаратный вариант. Мне кажется и схематически это даже будет попроще, чем мерять напряжение через АЦП и как-то всем этим жонглировать.
Спасибо. Этот тред меня прям с мёртвой точки подвинул. Я почему-то думал всё сильно сложнее и вообще, кодек обязательно нужен аппаратный… не приходило как-то в голову писать сырой поток. Чай не видео FullHD, аккумулятор сядет быстрее, да и заряжаться будет дольше, чем копирование 64Гб.
Буду искать кто прям на пальцах покажет что куда в макетку втыкать, чтобы звук писался=)
Ага, уже поставил давно, но это для самомотивированных высокоорганизованных альтруистов.
Нужно, к примеру, разметить пандусы, чтобы сделать построение маршрута для маломобильных граждан. Тут геймификация и краудсорсинг напрашиваются сами собой. Да, КПД будет в единицах процентов, но тут уж хоть шерсти клок. Качество можно взять количеством подтверждений.
А ведь можно в таком же режиме дополненной реальности и с тем же азартом наперегонки промаркировать подъезды, шлагбаумы, знаки, магазины… Что-то эдакое игровое обязательно нужно сделать. Пусть на выходе получатся сырые данные, пусть КПД не так велик, как у обученных и дотошных энтузиастов, но приобщить к хорошему великую силу игровой мотивации обычных людей, не готовых осваивать что-то сложное.
Наверно такое можно даже за деньги предлагать=).
Идею дарю. Хотя 100% уже кто-то додумался и сделал.
Всегда же интересно всякие паблики и каналы помониторить на предмет нечаянных сливов и зашкваров, которые долго в истории не провисят.
О сколько странных извращений даёт нам Python совершать.
…
[Да уж… надо обновлять комментарии, иначе можно оказаться очень «оригинальным»]
Эти ж доски теоретически можно и на дверные петли прикрутить, а дёргать тросиками.
Но на салдатской тяге такие часы, судя по всему, вообще неубиваемые.
Я так понимаю там программно PID-регулятор реализован, чтобы балансировать на грани детектирования поверхности? Посмотреть бы что выдаёт осциллограф с ИК-приёмника при изменении расстояния до препятствия.
А там, вроде, рентген.
Ну и не хватает стандартных векторных типов, чтобы не numpy подключать, а нативно векторную алгебру покрыть вместе с афинными преобразованиями.
Кстати, почему ещё никто не додумался сделать специально для подкастов чатик с таймкодами? Грубо говоря в ссылку на чат передаётся таймкод и масштабный коэффициент скорости прослушивания. С этого момента браузер воспроизводит состояние чата на момент, который в это же время играет в плеере.
Видимо нужна специальная поддержка такой фичи в подкаст-плеерах, но на собственных страничках подкастов, вроде того же радио-т, такое можно запилить вообще без проблем.
Если даже у подкаста нет прямого эфира и в чатик пишут только ведущие, то это всё равно киллер фича, поскольку не нужно бегать по описанию и искать именно ту ссылку, о которой сейчас говорят.
Может быть имеет смысл ещё и с графикой работать в CLI? Вообще бы здорово получилось — всё описание карты в виде скрипта.
Там с обратной стороны прищепка на одежду.
Только тут с шнурами возиться чтобы на зарядку ставить… так себе.
Лучше, конечно, чтобы из него под колпачком прям USB торчал, как у флешки.
Короче пофиг какая форма, нужно лишь чтобы на прищепке можно было на воротник повесить и не удушиться. Плюс, желательно, чтобы прям как есть в USB втыкалось на зарядку.
Вот как-то так, только экран не нужен.
Я понимаю, поэтому прибор будет позиционироваться подчеркнуто бытовым. Надеюсь пронесёт. Звук планирую шифровать асимметрично так, чтобы информации в регистраторе было недостаточно для расшифровки, только для шифрования. В прототипе шифрования, конечно, не будет. Нужно это, чтобы при краже или потере устройства не допустить утечку большого количества информации. Чтобы предотвратить возможность расшифровки можно удалить дешифрующий ключ с перекодирующей машины. Этот ключ опционально можно шифровать мастер-паролем, тогда его придётся вводить при подключении изделия на зарядку.
Да, я много слышал об этом контроллере и о том, что знающие люди искренне не понимают почему ардуина по-прежнему настолько популярна, когда есть STM32. Я его даже в руках держал, если именно этот чип стоит в ESP8266. Но не более.
А как вы думаете, что более энергозатратно: кодировать этим кодеком или писать сырой поток на флеш-карту?
Мне кажется я буду сильно упираться в батарейку. Хочется хотя бы 2-3 суток запаса автономной работы, чтобы можно было заряжать хотя бы ежедневно.
Вот тут не понял. Это чтобы динамический диапазон так повысить? Или это альтернатива подачи смещения с ЦАПа? Вроде нет, вроде похоже что речь о расширении динамического диапазона. Типа АЦП, у нас, к примеру, 12 бит, а нам надо 16. Берём и… что? смещаем центральную точку (или как там она называется) операционника по-разному для каждого канала АЦП, а потом вставляем в поток сигнал с самого релевантного канала АЦП умножая его на нужный коэффициент? Блин… звучит как рокет-сайнс. Как подбирать уровни ослабления? Как калибровать? Это отдельные операционники вообще? Да и про операционный усилитель я так… понаслышке знаю=).
Наверно про ослабления речь шла в контексте банальных резисторов. Да? Типа после операционника усиленный сигнал раздваивается и через разные резисторы поступает наразные каналы АЦП, а мы потом выбираем тот канал, который сильнее всего скачет? Только не смейтесь=)
Для прототипа можно сделать битрейт… хм… какой получится. Надо попробовать. Нету у меня опыта в таких вещах. Не знаю как звучать будет, как распознаваться потом такое будет…
Чем меньше кода, тем меньше ошибок и неожиданных побочных эффектов. Я за аппаратный вариант. Мне кажется и схематически это даже будет попроще, чем мерять напряжение через АЦП и как-то всем этим жонглировать.
Спасибо. Этот тред меня прям с мёртвой точки подвинул. Я почему-то думал всё сильно сложнее и вообще, кодек обязательно нужен аппаратный… не приходило как-то в голову писать сырой поток. Чай не видео FullHD, аккумулятор сядет быстрее, да и заряжаться будет дольше, чем копирование 64Гб.
Буду искать кто прям на пальцах покажет что куда в макетку втыкать, чтобы звук писался=)