Я практически уверен, что это проблема конфигурации битрикса. Или он не понял, что IM доступен, или ему не сказали, что им надо пользоваться. Или нет PHP-расширения для IM (может, битрикс его ожидает, а не обычные бинарники). Я в битриксе не спец, так что конкретнее сказать не могу.
Кррррасота. А у вас на сервере ImageMagick вообще установлен? А Битрикс об этом знает? Потому что выглядит это как nearest neighbor из стандартного php-шного GD, который обычно используется, если в системе нет нормальных средств работы с графикой.
Для начала посмотрите, как именно в Вашей CMS ресайзятся картинки. Вполне возможно, что для устраивающего Вас качества будет достаточно уменьшить степень сжатия результата, увеличить битность компонент цвета или просто слегка подшарпить на выходе. Смена алгоритма ресайза на никому не известный — это всё-таки крайний шаг.
Интересно, а что Вам мешало уменьшить для сравнения картинки до _одинакового_ размера? И использовать не только изобилующий артефактами шарпинга бикубик-шарп, но и обычный бикубик, а до кучи ещё и алгоритм Ланцоша (наиболее популярный метод для уменьшения) и другие алгоритмы? То есть, провести нормальное сравнение, из которого было бы понятно, что это за алгоритм у вас и чем он хорош.
Потому что по представленным картинкам я, например, вообще не понимаю, о чём речь (а я последние лет пять темой ресайза занимаюсь довольно плотно).
Раз вы тестировали, то значит и сами знаете — как. Оставляет желать лучшего, хотя во многих случаях его скорости будет достаточно. Но вообще, если пользователи российские, то вполне может выручить прокси в России с хорошим каналом на Европу.
Странно, всегда летаю с зонтом в рюкзаке, ни разу никто даже не покосился на него. Правда, Европа. В Конго, может, и придираются (наверное, не знают, что такое зонт).
Думаю, версий через несколько ЯПочта станет хорошей почтой:)
Вечная проблема, НЕ решённая в этой версии — объединение писем в цепочки. Вот Гугл как-то умудряется группировать письма с учётом времени, и группы получаются обозримые. Яндекс же слепляет все письма с одинаковым сабжем в одну цепочку. Вообще все. Например, у меня в ящике есть ~1200 писем с одинаковой темой — письма с одного из интернет сервисов. Вся (!) эта мегагруппа грузится в третью колонку целиком, и даже со свёрнутыми прочитанными это очень медленно и неудобно. Прежний же интерфейс почты такие группы завешивали напрочь.
И ещё сейчас заметил глючок: PageUp и PageDown листают третью колонку, но Home и End — вторую. Это неправильно.
Я _знаю_, что голоса на думских выборах на моём участке были украдены. Это видно по статистике. Но статистику на хлеб не намажешь и к делу не подошьёшь.
Так что лучше бы придумать протокол, который исключает такую возможность, а не надеяться на то, что все будут ходить по подъездам и сверять с соседями протоколы голосований.
Посмотрите статистику по президентским выборам, скажем, в Питере. Там была туча участков с 99,(9)% голосов за самизнаетекого, но все они были на предприятиях, в режимных учреждениях и т. п. Проверить их нет возможности.
Кроме этого, один из основных каналов вброса — это голосование вместо тех избирателей, которые физически существуют, но на выборы давно не ходят (и в УИКах это знают). Таких очень большое количество — до половины списочного состава. Такой резерв позволяет корректировать голоса как угодно, и это тоже не проверить в предложенной схеме — в списках реально существующие люди, в реально существующих квартирах, только на самом деле они в этот день картошку сажали, а проголосовали за них ребята из карусельных автобусов.
Вы знаете, таких схем — анонимность+открытость+верифицируемость — стотыщмиллионов, и непонятно, какую Америку Вы открываете. Вот на недавних выборах в КС ровно так и было — и анонимно, и открыто, и верифицируемо.
Проблема-то не в этом. Проблема в том, что «из воздуха» берутся дополнительные голоса за альфа-кандидата, и Ваша схема от этого никаким образом не защищает. Анонимна? Прекрасно. Открыта — да пожалуйста, вот в таком-то УИК-е столько-то голосов с такими-то хэшами, всё открыто. Верифицируема? Да ради бога, если вы голосовали, то проверяйте свой хэш. А вот эти 100500 хэшей за Путина, что рядом? А это не ваши, извините, их вы проверить не можете.
В условиях, когда ЦИК может быть не честен, эта схема ни от чего не защищает.
Можно сделать следующий шаг: отсылать не по почте, а через личные сообщения вконтакта или фейсбука. И пусть у Дурова голова болит:) Кстати, почти не шутка.
Я не хотел бы пинать ЦВК-шников — они провернули огромную работу, организовав все эти выборы, и атаки отбили довольно оперативно. Но всё-таки некоторые моменты…
Послушайте, все знали, что будет ДДОС, ЦВКшники знали что будет ДДОС, все об этом говорили, все этого ждали. И при этом — синхронные запросы к БД на публичных страницах сайта?! Azure без логов?! Капча?! Атака им. Дурова, которая, извините, почти вся отбивается просто по реферерам?!
Поддерживаю. Data class определён с _именами_ полей, вот пусть они по именам и достаются. Привязываться к _порядку_ объявления, да ещё и неявно — это самому себе стелить грабли.
Вообще, при всём уважении к команде Котлина (и симпатии к языку), componentN — это уродство. Надеюсь, можно будет придумать какую-нибудь альтернативу. Например, var (a, b) = c автоматически заполнять, если c — это массив (список, итератор и т. п.), а var (foo: a, bar: b) = c или (a, b) = c.(foo, bar), если c — это объект (или хэш?).
Потому что по представленным картинкам я, например, вообще не понимаю, о чём речь (а я последние лет пять темой ресайза занимаюсь довольно плотно).
Вечная проблема, НЕ решённая в этой версии — объединение писем в цепочки. Вот Гугл как-то умудряется группировать письма с учётом времени, и группы получаются обозримые. Яндекс же слепляет все письма с одинаковым сабжем в одну цепочку. Вообще все. Например, у меня в ящике есть ~1200 писем с одинаковой темой — письма с одного из интернет сервисов. Вся (!) эта мегагруппа грузится в третью колонку целиком, и даже со свёрнутыми прочитанными это очень медленно и неудобно. Прежний же интерфейс почты такие группы завешивали напрочь.
И ещё сейчас заметил глючок: PageUp и PageDown листают третью колонку, но Home и End — вторую. Это неправильно.
Так что лучше бы придумать протокол, который исключает такую возможность, а не надеяться на то, что все будут ходить по подъездам и сверять с соседями протоколы голосований.
Кроме этого, один из основных каналов вброса — это голосование вместо тех избирателей, которые физически существуют, но на выборы давно не ходят (и в УИКах это знают). Таких очень большое количество — до половины списочного состава. Такой резерв позволяет корректировать голоса как угодно, и это тоже не проверить в предложенной схеме — в списках реально существующие люди, в реально существующих квартирах, только на самом деле они в этот день картошку сажали, а проголосовали за них ребята из карусельных автобусов.
Проблема-то не в этом. Проблема в том, что «из воздуха» берутся дополнительные голоса за альфа-кандидата, и Ваша схема от этого никаким образом не защищает. Анонимна? Прекрасно. Открыта — да пожалуйста, вот в таком-то УИК-е столько-то голосов с такими-то хэшами, всё открыто. Верифицируема? Да ради бога, если вы голосовали, то проверяйте свой хэш. А вот эти 100500 хэшей за Путина, что рядом? А это не ваши, извините, их вы проверить не можете.
В условиях, когда ЦИК может быть не честен, эта схема ни от чего не защищает.
Послушайте, все знали, что будет ДДОС, ЦВКшники знали что будет ДДОС, все об этом говорили, все этого ждали. И при этом — синхронные запросы к БД на публичных страницах сайта?! Azure без логов?! Капча?! Атака им. Дурова, которая, извините, почти вся отбивается просто по реферерам?!
Уверен, что все там вынесли свои уроки из этого.
Вообще, при всём уважении к команде Котлина (и симпатии к языку), componentN — это уродство. Надеюсь, можно будет придумать какую-нибудь альтернативу. Например, var (a, b) = c автоматически заполнять, если c — это массив (список, итератор и т. п.), а var (foo: a, bar: b) = c или (a, b) = c.(foo, bar), если c — это объект (или хэш?).