Искренние возмущения и удивления со всех сторон. Всё как в первый раз.
Именно так и должно быть. Не обязательно удивления, но указания на то, что что-то идёт неправильно — да, каждый раз. И это не должно утихать, это должно быть по возможности громче.
Потому что это поле и эти "выборы" заточены на то, чтобы его нельзя было сменить. Никак вообще
Иногда изменения происходят даже с тем, что совсем не заточено под изменения. Не очень часто, конечно, и иногда это совсем незначительные изменения. Но мне лично кажется, что лучший способ уменьшить шансы на это — активно убеждать себя и других, что таких шансов нет совсем.
Это очень помогает тем, кому приходится фальсифицировать лишь 10-20% процентов, а 50% попросту смиренно приняли «простые и очевидные» вещи и сидят по домам.
Может быть уже хватит жить в иллюзиях?
Как ни странно, ничего не мешает не жить в иллюзиях (как о грядущем светлом будущем, так и о его недостижимости), и при этом ходить на выборы, а когда голоса воруют — говорить об этом. Каждый раз, как в первый.
А если же вы думаете, что отсутствие общественного резонанса как-то ослабит легитимность режима, а не усилит его, то вы сильно заблуждаетесь, как мне кажется.
Я согласен, хорошо бы это более нормально заисследовать, и хорошо бы чтобы этим серьёзно занимались не простые программисты вроде меня, а люди, серьёзно занимающиеся матстатистикой и изучающие политические процессы. Не уверен, правда, что такие исследования пишутся за неделю.
Но согласитесь, видеть наглядные картинки всё-таки лучше, чем совсем уж ничего? Считайте, что у меня здесь не ответ, а напротив, запрос к науке — как вот такое получилось, чем это объясняется?
Ну, а в современной РФ просто работает «Теорема Эскобара», что физическое бумажное, что электронное - чистая показуха
На мой взгляд, это сильное упрощение, которое не очень подтверждается историческими данными.
Если изучать статистику по всем выборам (как делает Шпилькин, например), то видно, что есть различия в масштабах фальсификаций, которые варьируются по регионам и по отдельным участкам (особенно сильная корреляция, собственно, с присутствием на участках наблюдателей). То есть там понятно, какие есть методы для залатывания дыр, а в электронном их не будет совсем
Например у вас подзаголовок "Почему электронное голосование всегда будет хуже бумажного" , а потом пункты в которых описываются только минусы текущей реализации.
Верно, я начинаю с перечисления минусов реализации, а сразу после них — описываю, что фундаментально не так с любыми электронными голосованиями. Там есть проблемы, которые либо не пофиксить никак, либо можно пофиксить в обществе роботов, каждый из которых понимает устройство системы. И главный недостаток — это возложение куда большего доверия к оператору такой системы (государству).
Да, это справедливое замечание. Мне всегда вебхуки казались наиболее предпочтительным способом получения обновлений, так что я не особенно принимал во внимание работу через (long) polling (поправлю, правда, что оба метода сразу Телеграм не позволяет использовать параллельно).
Проксирование-то держать мне не сложно — я вообще думаю в будущем давать публичный endpoint для каждого бота, за который его можно будет самому дёргать снаружи. А вот со стороны владельца бота чуть-чуть запарнее переключиться: тут уже обязательно править исходники, чтобы запросы на getUpdates шли к Botsman, а не к Telegram (в случае с вебхуками это необязательное условие, можно только в интерфейсе переключатель ткнуть).
Но это всё не очень серьёзные аргументы — в скором будущем, думаю, действительно указание адреса вебхуки сделаю опциональным.
В разделе «Предыстория» я сформулировал ответ на этот вопрос примерно так:
… почти сразу пришла в голову идея сделать такую платформу, которая возьмёт весь мониторинг на себя
Могу дополнить ещё так: хотелось сделать инструмент, делающий процесс разработки ботов (не только работы с Telegram API) максимально удобным, чтобы вопросы отладки, деплоя и мониторинга стали менее напряжными. Вот к этому и стремлюсь.
Если в какой-то момент поддерживать сервера станет слишком накладно, то скорее всего платный тариф будет отличаться более свободными лимитами (на число ботов в аккаунте, количеством групп/пользователей бота, максимальным временем выполнения кода). Принципиально отключать в бесплатной версии ничего не хочется — мне кажется, будет хорошо, если всегда будет возможность создать бота лично для себя (или на маленькую аудиторию), не чувствуя каких-то серьёзных ограничений.
Над тем, чтобы открыть исходники, пока тоже не думал.
Мы рассчитываем, что в дальнейшем нашей команде — возможно, при помощи сообщества — удастся развить KPHP так, чтобы он стал полезным инструментом и вне ВКонтакте. Не так важно, как быстро это произойдёт. В любом случае, это тот ориентир, который теперь стоит перед проектом.
Честно говоря, не очень понятно, зачем эта цель (и вам, и сообществу). В конкретном случае (очень много легаси-кода на PHP) — да, ок, вероятно это имеющее право на жизнь решение. Но мне сложно представить ситуацию, в которой у кого-то ещё снова может возникнуть подобная необходимость. Это нужно ведь, чтобы кто-то решил начать новый проект на PHP (а не на Go, скажем, да и даже не на PHP 8 почему-то), вырос до тех размеров, когда уже нет желания переписать на какой-то другой язык — но при этом есть желание переписать код так, чтобы он успешно компилировался kPHP…
Кажется, вы зря возлагаете надежды на сообщество. Пусть вы и оформили kPHP покрасивше, чем в 2014, но пользы для кого-то, кроме самого ВК, от него немного. А если уж кто-то и горит желанием развивать нечто компилирующееся в C++, я бы предложил лучше потратить силы на Nim, например, — у него, по крайней мере, нет цели одновременно подражать другому языку (который сам по себе так себе образец для подражания), и при этом отбирать из него целые пласты функциональности :)
Не знаю, насколько реализуемо, но может быть подпружиненную металлическую пластину-защелку типа такой? В текстолите тогда достаточно будет отверстия под неё.
Абсолютно верно, и об этом сказано в самой статье.
Если в вашей задаче важно, чтобы при повреждении строк сохранялась целостность последующего за ними текста — используйте UTF-8. Это ведь нормально — подбирать решение под задачу.
В моей задаче (да и во многих других практических задачах), риск повреждений невысок, а если они возникли — то это уже ошибка в любом случае, независимо от того, сколько именно символов затронуто.
Значит, понимание того, что «гораздо проще» у нас с вами несколько разное.
Для меня, повторюсь, вариант тащить полноценную либу, осваивать её апи, готовить для неё какие-то данные (в надежде, что они будут репрезентативными для любого будущего датасета), и потом потенциально страдать от недостаточной производительности — не ощущался проще, чем написать две функции на 100 строчек кода. И что самое важное, это точно не ощущалось интереснее :)
В то же время я совершенно не спорю, что кому-то другому может показаться иначе (и это нормально). Хорошо же, что у нас всех есть свобода выбирать, какими решениями пользоваться, и какие велосипеды писать :)
Ошибся, семь: греческий (U+0370..U+03FF), армянский (коды U+0530..U+058F), иврит (U+0590..U+05FF), арабский (два блока, U+0600..U+06FF и U+0750..U+077F), сирийский (U+0700..U+074F), тана (мальдивский язык, U+0780..U+07BF) и н'ко, использующийся в языках манде в Западной Африке (U+07C0..U+07FF).
Не могу сказать, что в моём случае это так. Как раз-таки содержимое строк мне трогать не нужно (не требуются никакие изменения строк, поиск подстрок и тому подобное), они абсолютно статичны.
Кажется, это всё-таки чистая задача хранения строк, но при условии их малой длины (что мешает использовать алгоритмы сжатия).
Я лично не нахожу удивительным, что эффективность вещества может сильно зависеть от его концентрации и способа применения.
Капля никотина, как говорится, убивает лошадь
Мне как минимум это будет очень интересно, я открою для себя что-то новое и смогу построить более точную модель окружающего мира.
Именно так и должно быть. Не обязательно удивления, но указания на то, что что-то идёт неправильно — да, каждый раз. И это не должно утихать, это должно быть по возможности громче.
Иногда изменения происходят даже с тем, что совсем не заточено под изменения. Не очень часто, конечно, и иногда это совсем незначительные изменения. Но мне лично кажется, что лучший способ уменьшить шансы на это — активно убеждать себя и других, что таких шансов нет совсем.
Это очень помогает тем, кому приходится фальсифицировать лишь 10-20% процентов, а 50% попросту смиренно приняли «простые и очевидные» вещи и сидят по домам.
Как ни странно, ничего не мешает не жить в иллюзиях (как о грядущем светлом будущем, так и о его недостижимости), и при этом ходить на выборы, а когда голоса воруют — говорить об этом. Каждый раз, как в первый.
А если же вы думаете, что отсутствие общественного резонанса как-то ослабит легитимность режима, а не усилит его, то вы сильно заблуждаетесь, как мне кажется.
Вы мне делаете грустно. Я тут вам целую статью об объективных причинах, почему это менее надёжно, а вы мне про «религиозные споры».
О каком удобном непрерывном процессе может идти речь, если он может (и будет) непрерывно подделываться?
Я согласен, хорошо бы это более нормально заисследовать, и хорошо бы чтобы этим серьёзно занимались не простые программисты вроде меня, а люди, серьёзно занимающиеся матстатистикой и изучающие политические процессы. Не уверен, правда, что такие исследования пишутся за неделю.
Но согласитесь, видеть наглядные картинки всё-таки лучше, чем совсем уж ничего? Считайте, что у меня здесь не ответ, а напротив, запрос к науке — как вот такое получилось, чем это объясняется?
В Ленинградском, 198-м
На мой взгляд, это сильное упрощение, которое не очень подтверждается историческими данными.
Если изучать статистику по всем выборам (как делает Шпилькин, например), то видно, что есть различия в масштабах фальсификаций, которые варьируются по регионам и по отдельным участкам (особенно сильная корреляция, собственно, с присутствием на участках наблюдателей). То есть там понятно, какие есть методы для залатывания дыр, а в электронном их не будет совсем
Верно, я начинаю с перечисления минусов реализации, а сразу после них — описываю, что фундаментально не так с любыми электронными голосованиями. Там есть проблемы, которые либо не пофиксить никак, либо можно пофиксить в обществе роботов, каждый из которых понимает устройство системы. И главный недостаток — это возложение куда большего доверия к оператору такой системы (государству).
Проксирование-то держать мне не сложно — я вообще думаю в будущем давать публичный endpoint для каждого бота, за который его можно будет самому дёргать снаружи. А вот со стороны владельца бота чуть-чуть запарнее переключиться: тут уже обязательно править исходники, чтобы запросы на getUpdates шли к Botsman, а не к Telegram (в случае с вебхуками это необязательное условие, можно только в интерфейсе переключатель ткнуть).
Но это всё не очень серьёзные аргументы — в скором будущем, думаю, действительно указание адреса вебхуки сделаю опциональным.
Могу дополнить ещё так: хотелось сделать инструмент, делающий процесс разработки ботов (не только работы с Telegram API) максимально удобным, чтобы вопросы отладки, деплоя и мониторинга стали менее напряжными. Вот к этому и стремлюсь.
Если в какой-то момент поддерживать сервера станет слишком накладно, то скорее всего платный тариф будет отличаться более свободными лимитами (на число ботов в аккаунте, количеством групп/пользователей бота, максимальным временем выполнения кода). Принципиально отключать в бесплатной версии ничего не хочется — мне кажется, будет хорошо, если всегда будет возможность создать бота лично для себя (или на маленькую аудиторию), не чувствуя каких-то серьёзных ограничений.
Над тем, чтобы открыть исходники, пока тоже не думал.
Don’t be evil
Честно говоря, не очень понятно, зачем эта цель (и вам, и сообществу). В конкретном случае (очень много легаси-кода на PHP) — да, ок, вероятно это имеющее право на жизнь решение. Но мне сложно представить ситуацию, в которой у кого-то ещё снова может возникнуть подобная необходимость. Это нужно ведь, чтобы кто-то решил начать новый проект на PHP (а не на Go, скажем, да и даже не на PHP 8 почему-то), вырос до тех размеров, когда уже нет желания переписать на какой-то другой язык — но при этом есть желание переписать код так, чтобы он успешно компилировался kPHP…
Кажется, вы зря возлагаете надежды на сообщество. Пусть вы и оформили kPHP покрасивше, чем в 2014, но пользы для кого-то, кроме самого ВК, от него немного. А если уж кто-то и горит желанием развивать нечто компилирующееся в C++, я бы предложил лучше потратить силы на Nim, например, — у него, по крайней мере, нет цели одновременно подражать другому языку (который сам по себе так себе образец для подражания), и при этом отбирать из него целые пласты функциональности :)
Абсолютно верно, и об этом сказано в самой статье.
Если в вашей задаче важно, чтобы при повреждении строк сохранялась целостность последующего за ними текста — используйте UTF-8. Это ведь нормально — подбирать решение под задачу.
В моей задаче (да и во многих других практических задачах), риск повреждений невысок, а если они возникли — то это уже ошибка в любом случае, независимо от того, сколько именно символов затронуто.
Для меня, повторюсь, вариант тащить полноценную либу, осваивать её апи, готовить для неё какие-то данные (в надежде, что они будут репрезентативными для любого будущего датасета), и потом потенциально страдать от недостаточной производительности — не ощущался проще, чем написать две функции на 100 строчек кода. И что самое важное, это точно не ощущалось интереснее :)
В то же время я совершенно не спорю, что кому-то другому может показаться иначе (и это нормально). Хорошо же, что у нас всех есть свобода выбирать, какими решениями пользоваться, и какие велосипеды писать :)
Кажется, это всё-таки чистая задача хранения строк, но при условии их малой длины (что мешает использовать алгоритмы сжатия).