Есть небольшая проблемка )
Чтобы пополнить запасы топлива, воды и прочего — надо будет уравнять скорости. Есть ли смысл затормаживаться при догонянии цистерны — сомнительно. Т.к. в итоге мы окажемся в том же месте и двигаться будем с той же скоростью, как если бы вылетели вместе с цистерной. Разница только во времени подлета, что играет роль для живых космонавтов, но никак не для исследования космоса.
Каждый ход стоит каких-то очков, первые — много, последние — мало, игра останавливается, когда стоимость становится отрицательной.
Когда-то техника игры была не такой совершенной, как сейчас, и не позволяла реализовать полностью преимущество первого хода, тогда коми 5.5 было разумным. С ростом техники игры у черных (ходят первыми) появляется дополнительное преимущество, которое надо компенсировать ростом коми.
У меня недостаточно мастерства, чтобы оценить, какая часть этого преимущества обьективная, а какая — психологическая. Но то, что коми растет — вполне обьяснимо — эволюционирует техника игры.
Идея хорошая, но, имхо, камера ГГ не позволит получить видео с нужным качеством. Кроме слабой оптики, камера сама находится на голове, которую трясет от пульса. Может и получится как-то компенсировать, а может и нет…
Технический вопрос. Раз время сьемки такое длинное, то в итоговом видео наверняка на один видео-кадр будет приходится несколько фото-кадров. Как будет происходить смешивание этих кадров? Может есть смысл сначала их посмешивать скриптом в индивидуальные видео-кадры, которые потом обьединить в видео-поток?
Вы немного не поняли мою мысль. Можно DELETE, PATCH, PUT и т.д. использовать, я все это в статье видел. Мой коментарий о том, что если не использовать все это многообразие, то все же вполне разумно изменяющие данные запросы отсылать через POST, а все остальные (безопасные) операции — делать через GET.
Отличная статья, ещё и весьма вовремя (для меня, разумеется ;) ).
Конечно, с некоторыми положениями можно подискутировать, но в целом все очень толково.
Единственное, что удивило — не рассматривается простая особенность GET и POST http-запросов в контексте создания API: первый идемпотентный, а второй — нет. Разумеется, свойство это обеспечивается не названием метода, а реализацией API, но в целом это хороший и правильный тон — использовать GET для получения данных, а POST — для их изменения.
Спасибо за статью, есть пару вопросов. Первый по теме — обязательно ли модифицировать Phone.apk из родной прошивки, или можно взять любой пропатченный для данной версии андроида?
И второй уже оффтоп — может быть Вы в курсе, какой есть кошерный способ по управлению пермишнами установленых приложений? В свое время я сильно удивился, что на айфоне можно практически на ходу менять, какие из запрошенных разрешений можно удовлетворять, а какие заблокировать. На андроиде же из стока можно лишь посмотреть список запрашиваемых разрешений, и либо отклонить установку, либо разрешить все сразу. Из приложений для управления пока нашел только PermissionManager, который после настройки пермишнов переустанавливает приложение, при этом обнуляя данные — их приходится предварительно бекапить и восстанавливать, а ещё ломается обновление приложение через стор. Как быть?
Спасибо за статью, весьма неожиданно с паролем получилось.
На всякий случай напомню пользователям ssh-ключей, что не стоит пренебрегать возможностью ограничивать варианты использования ключа настройкой публичной части (секция AUTHORIZED_KEYS FILE FORMAT в man sshd), в частности, крайне рекомендую указывать в опции from="" список хостов, с которых разрешено логиниться данному ключу, например from="1.2.3.4,5.6.7.8" ssh-dss AAAAB3NzaC...bla-bla...WWng==
Если ключ только для git (или других очень узких целей), то можно и список разрешенных команд настроить.
>Этот эксперимент описывает не «суперпозицию», а волновую природу фотона и электрона.
Волновая природа, это когда они просто интерферируют друг с дружкой.
А вот как Вы обьясните интерфереционную картинку одиночных частиц (которые могут взаимодействовать только сами с собой, других то нет на момент пролета). Если бы они имели определенное состояние (т.е. пролетели бы через одну, пускай неизвестную щель), то и интерференционной картинки не было бы.
Скопировать состояние не возможно, иначе весь этот сыр-бор с неопределенностью потеряет смысл — знай себе копируй и меряй состояние на копиях с возможностью повторить эксперимент сколько угодно раз.
Эксперимент по ссылке выше показывает всего лишь, что нелокальность запутанного состояния простирается не только на пространство, но и на время. Кто перестал удивляться факту пространственно нелокальности запутанности, того временная нелокальность уже не должна особо удивлять ). Тем более, что у нас есть принцип тождественности систем в одинаковых состояниях — обмен состояниями это просто слова, это можно было бы и назвать перетеканием состояния из одной области пространства-времени в другое.
Сайт очень занятный, но хостинг все портит (
Чтобы пополнить запасы топлива, воды и прочего — надо будет уравнять скорости. Есть ли смысл затормаживаться при догонянии цистерны — сомнительно. Т.к. в итоге мы окажемся в том же месте и двигаться будем с той же скоростью, как если бы вылетели вместе с цистерной. Разница только во времени подлета, что играет роль для живых космонавтов, но никак не для исследования космоса.
Каждый ход стоит каких-то очков, первые — много, последние — мало, игра останавливается, когда стоимость становится отрицательной.
Когда-то техника игры была не такой совершенной, как сейчас, и не позволяла реализовать полностью преимущество первого хода, тогда коми 5.5 было разумным. С ростом техники игры у черных (ходят первыми) появляется дополнительное преимущество, которое надо компенсировать ростом коми.
У меня недостаточно мастерства, чтобы оценить, какая часть этого преимущества обьективная, а какая — психологическая. Но то, что коми растет — вполне обьяснимо — эволюционирует техника игры.
Не все решения в математическом смысле являются решениями в программистском смысле.
Тем не менее, в 21-м веке почти повсеместно принято играть с коми 6.5, а в Китае уже и 7.5.
Ваш текст, по хорошему, должен был присутствовать прямо в обсуждаемой статье )
Конечно, с некоторыми положениями можно подискутировать, но в целом все очень толково.
Единственное, что удивило — не рассматривается простая особенность GET и POST http-запросов в контексте создания API: первый идемпотентный, а второй — нет. Разумеется, свойство это обеспечивается не названием метода, а реализацией API, но в целом это хороший и правильный тон — использовать GET для получения данных, а POST — для их изменения.
И второй уже оффтоп — может быть Вы в курсе, какой есть кошерный способ по управлению пермишнами установленых приложений? В свое время я сильно удивился, что на айфоне можно практически на ходу менять, какие из запрошенных разрешений можно удовлетворять, а какие заблокировать. На андроиде же из стока можно лишь посмотреть список запрашиваемых разрешений, и либо отклонить установку, либо разрешить все сразу. Из приложений для управления пока нашел только PermissionManager, который после настройки пермишнов переустанавливает приложение, при этом обнуляя данные — их приходится предварительно бекапить и восстанавливать, а ещё ломается обновление приложение через стор. Как быть?
На всякий случай напомню пользователям ssh-ключей, что не стоит пренебрегать возможностью ограничивать варианты использования ключа настройкой публичной части (секция AUTHORIZED_KEYS FILE FORMAT в man sshd), в частности, крайне рекомендую указывать в опции from="" список хостов, с которых разрешено логиниться данному ключу, например
from="1.2.3.4,5.6.7.8" ssh-dss AAAAB3NzaC...bla-bla...WWng==Если ключ только для git (или других очень узких целей), то можно и список разрешенных команд настроить.
Волновая природа, это когда они просто интерферируют друг с дружкой.
А вот как Вы обьясните интерфереционную картинку одиночных частиц (которые могут взаимодействовать только сами с собой, других то нет на момент пролета). Если бы они имели определенное состояние (т.е. пролетели бы через одну, пускай неизвестную щель), то и интерференционной картинки не было бы.
Эксперимент по ссылке выше показывает всего лишь, что нелокальность запутанного состояния простирается не только на пространство, но и на время. Кто перестал удивляться факту пространственно нелокальности запутанности, того временная нелокальность уже не должна особо удивлять ). Тем более, что у нас есть принцип тождественности систем в одинаковых состояниях — обмен состояниями это просто слова, это можно было бы и назвать перетеканием состояния из одной области пространства-времени в другое.