Искренние возмущения и удивления со всех сторон. Всё как в первый раз.
Именно так и должно быть. Не обязательно удивления, но указания на то, что что-то идёт неправильно — да, каждый раз. И это не должно утихать, это должно быть по возможности громче.
Потому что это поле и эти "выборы" заточены на то, чтобы его нельзя было сменить. Никак вообще
Иногда изменения происходят даже с тем, что совсем не заточено под изменения. Не очень часто, конечно, и иногда это совсем незначительные изменения. Но мне лично кажется, что лучший способ уменьшить шансы на это — активно убеждать себя и других, что таких шансов нет совсем.
Это очень помогает тем, кому приходится фальсифицировать лишь 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).
Не могу сказать, что в моём случае это так. Как раз-таки содержимое строк мне трогать не нужно (не требуются никакие изменения строк, поиск подстрок и тому подобное), они абсолютно статичны.
Кажется, это всё-таки чистая задача хранения строк, но при условии их малой длины (что мешает использовать алгоритмы сжатия).
Да, неплохо бы это делать с учётом языка, не спорю (и никто не мешает дополнительно и эту информацию хранить и использовать при сортировке, как это делается в MySQL, к примеру).
Но ещё я отмечу, что Юникод всё-таки определяет и некий базовый порядок сортировки символов (DUCET) и даже без уточнения под конкретный язык он даст более адекватную в большинстве случаев сортировку, нежели предлагаемую вами сортировку по кодовым точкам.
Главный мой поинт остаётся в силе — если мы хотим естественный порядок, нам нужно декодировать строки (да, хорошо бы при этом знать язык).
Если же в массиве строк есть и чешские, и польские, и немецкие, и шведские, (а то ещё и турецкие,) то «естественный порядок» не определён, и единственный порядок, имеющий смысл при сортировке такого массива — это порядок по codepoints, что UTF-8 и обеспечивает.
Окей, я понял, что ваша цель не в естественном порядке. Но тогда я вообще не очень понимаю, что вы называете смыслом данного порядка, какая практическая задача этим решается?
The basic principle to remember is: The position of characters in the Unicode code charts does not specify their sort order.
Так что мне кажется, сортировка по кодовым точкам не особо лучше любой другой детерменированной сортировки (как, например, по байтам в закодированном виде).
Мне как минимум это будет очень интересно, я открою для себя что-то новое и смогу построить более точную модель окружающего мира.
Именно так и должно быть. Не обязательно удивления, но указания на то, что что-то идёт неправильно — да, каждый раз. И это не должно утихать, это должно быть по возможности громче.
Иногда изменения происходят даже с тем, что совсем не заточено под изменения. Не очень часто, конечно, и иногда это совсем незначительные изменения. Но мне лично кажется, что лучший способ уменьшить шансы на это — активно убеждать себя и других, что таких шансов нет совсем.
Это очень помогает тем, кому приходится фальсифицировать лишь 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 строчек кода. И что самое важное, это точно не ощущалось интереснее :)
В то же время я совершенно не спорю, что кому-то другому может показаться иначе (и это нормально). Хорошо же, что у нас всех есть свобода выбирать, какими решениями пользоваться, и какие велосипеды писать :)
Кажется, это всё-таки чистая задача хранения строк, но при условии их малой длины (что мешает использовать алгоритмы сжатия).
Но ещё я отмечу, что Юникод всё-таки определяет и некий базовый порядок сортировки символов (DUCET) и даже без уточнения под конкретный язык он даст более адекватную в большинстве случаев сортировку, нежели предлагаемую вами сортировку по кодовым точкам.
Главный мой поинт остаётся в силе — если мы хотим естественный порядок, нам нужно декодировать строки (да, хорошо бы при этом знать язык).
Окей, я понял, что ваша цель не в естественном порядке. Но тогда я вообще не очень понимаю, что вы называете смыслом данного порядка, какая практическая задача этим решается?
Вот цитата непосредственно из документа Unicode Collation Algorithm:
Так что мне кажется, сортировка по кодовым точкам не особо лучше любой другой детерменированной сортировки (как, например, по байтам в закодированном виде).