Про мобильный интернет

Обнаружил, что мой пакет мобильного интернета отправился в утиль, точнее в архив. Пока работает, но на всякий случай, надо искать замену. Пока искал обнаружил следующие факты:

• МТС даёт за 250 руб/месяц 3Гб интернета по СуперБиту, действующему по всей России (с неявными условиями действия, возможно 30 руб. в сутки за межгород)
• Мегафон за те же 250 руб/месяц уже даёт 5Гб интернета, но только в домашнем регионе (+10 руб/сутки за межгород)
• Билайн за те же 250 руб/месяц (как бы случайно совпало) даёт те же 5Гб интернета, но зато действует по всей России без ограничений
• СМАРТС за 200 руб/месяц даёт полный анлим 2G интернета, что реально позволяет выкачать аж 200Мб. На большее он не способен.

Зачем я это написал? Мне показалось интересно, что что для удобства сравнения конкурентов вся большая тройка решила выровнять цены, несмотря на то, что обычно они любят чуть отличающиеся параметры для более сложного выбора.

А так получается, что в нашей деревне самый лучший и без вариантов — Билайн, и даже нет ни одного факта смотреть на других провайдеров (по качеству самого интернета претензий особых тоже нет). 

Ну, а МТС имеет неясные условия, но похоже что самый дорогой.

Использование быстрых алгоритмов сжатия в потоковом режиме

Понял, что в предыдущем посте, я проверил алгоритмы на скорость, но забыл проверить их на возможность работы в потоковом режиме. Когда данные идут потоком, сжимаются и передаются дальше.
И тут выяснились весьма интересные моменты, некоторые, связанные с реализацией.

Начнём по-порядку.

• zlibnet — считает метод Flush сигналом для записи финального блока, что приводит к некорректному поведению. Надо чинить (а лучше переписать самому, где там мой блокнотик?)
• SharpCompress — любитель вызывать метод записи с длиной в 0 байт, что, имхо, весьма неаккуратно. Может на некоторые потоки создавать бессмысленную нагрузку
• SharpZipLib — никаких нареканий
• Встроенный GZip — буфер в 8Кб, полностью игнорируется Flush, оказывается для потоков его использовать нельзя.
• Snappy — блочный алгоритм, блоки с префиксом и контрольной суммой, что накладывает отпечаток на возможностях
• Snappy for .NET — нет реализации стримов, пропускаем
• Snappy.NET — блок прибит гвоздями в 64Кб, Flush вызывает запись независимого блока. Т.е. частый флуш приведёт к потере сжатия и увеличению объёма
• LZ4 — тоже блочный, при уменьшении блока резко падает степень сжатия, поведение аналогично Snappy. В реализациях (lz4-net и LZ4.NET) проблем не обнаружил (кроме самого факта с проблемами потока). Из хороших новостей — потоковое API для LZ4 разрабатывается (прямо в тот момент, как я пишу этот текст). Оно ещё не стандартизировано, но шансы есть, что будет всё круто.
• LZF — я его достал с дальнего ящика и смотрю на него. Его особенность, что сжатие позволяет писать данные хоть по байту (и читать сжатые по байту). Правда исходные данные пока выглядят блочными, но думаю это можно будет поправить, если поисследовать алгоритм. 

Выбор быстрых алгоритмов сжатия под .NET

Для начала, пара таблиц для привлечения внимания:

Быстрый компьютер:

MemCopy:         1561.050       1709.7218        100.000%
GZipStd:           66.736        221.6318          6.335%
#ZipLib.Gzip:      52.800        136.0018          6.358%
zlibnet:          100.572        466.2888          6.500%
SharpComp.GZip:    52.568        154.7598          6.501%
Snappy.Net:       970.382        944.8468         13.312%
SnappyforNet:     997.337       1795.2078         14.499%
lz4net/CC:        485.191       1122.0048         10.740%
lz4net/MM:        997.337       1158.1988         10.740%
lz4net/N:         535.883       1122.0048         10.740%
lz4net/S:         386.066        690.4648         10.740%
lz4net/HC:         42.794       1282.2918          7.751%
LZ4.Net:          997.337       1158.1988         10.896%
QuickLZ:          460.310        528.0028          8.032%
LZO_1X   :       1683.082       1561.0508         11.824%
LZF     :         272.001        398.9358         13.882%

Медленный компьютер:

MemCopy:          394,551        394,5518        100,000%
GZipStd:           18,006         50,4278          8,738%
#ZipLib.Gzip:      16,137         45,2198          6,358%
zlibnet:           31,086        105,6008          6,500%
SharpComp.GZip:    18,356         46,6898          6,501%
Fail Snappy.Net: Инициализатор типа "Crc32C.NativeProxy" выдал исключение.
SnappyforNet:     260,175        432,5808         14,499%
Fail lz4net/CC: Ссылка на объект не указывает на экземпляр объекта.
Fail lz4net/MM: Ссылка на объект не указывает на экземпляр объекта.
lz4net/N:         218,928        228,6898         10,740%
lz4net/S:         120,484        141,9148         10,740%
Fail lz4net/HC: Ссылка на объект не указывает на экземпляр объекта.
LZ4.Net:          234,668        274,0778         10,896%
QuickLZ:           60,445         65,0448          8,032%
LZO_1X   :        374,001        505,6928         11,827%
LZF     :          44,880         60,3438         13,882%

Это я тестировал различные реализации алгоритмов сжатия и их скорости. Столбцы: скорость сжатия в MB/s, скорость декомпрессии, процент сжатого текста, относительно исходного материала.

Конкретно не даю описаний компьютеров и некоторых параметров, потому что для меня цель больше стояла в удобстве использования этих алгоритмов в продакшене, а удобство и качество кода в некоторых случаях значительно перевешивает скорость. Кроме того, я рассматривал ситуацию использования всего этого дела под .NET, для других платформ результаты могут быть совершенно другие, ибо код пишется разными людьми и имеет разный функционал и возможности.

Собственно, поэтому сразу же выкину из дальнейшего рассмотрения следующие алгоритмы:

• QuickLZ — проблемы с лицензией,
• LZO — работает через P/Invoke, мутный враппер, какие-то косяки с дебагом, проблемы с 64 битами не ясно дальнейшее развитие, собственно, его высокие показатели в тестах отчасти связаны с ограниченностью функционала, из-за которого, тест оказался в более выгодном положении относительно некоторых других (я даже не уверен, что он стабильно работает, хотя то что работает хотя бы один раз, это точно, я проверил)
• LZF — хорош как вариант микро-компрессора (собственно, весь код можно зафигачить в 200 строчек не сильно экономя, при этом результат вполне сносный. Но, если вы не специалист по алгоритмам, не очень рекомендую заниматься этим делом. Хотя, возможно идея довести код до ума, вполне неплохая (надо записать себе в блокнот "обязательно сделать в следующей жизни").

Также в алгоритме не приняли участие: BZip2, LZMA и PPMd (степень сжатия отличная, скорость настолько низкая, что даже ради научного интереса их тут не стоит использовать.

Некоторые алгоритмы вида классического LZ77, не были найдены под .NET, поэтому тоже их пропускаем.

Теперь детально разберу оставшиеся GZip, LZ4, Snappy.

Gzip

Собственно, самый известный алгоритм сжатия, использующийся поголовно везде (хотя правильнее сказать, что алгоритм — Deflate, а GZip — поток с дополнительной метаинформацией). Если вы будете использовать его — у вас не будет никаких проблем с совместимостью, так что он очень хорош в плане требования по памяти и работы в потоковом режиме.

Но с выбором реализации есть некоторые проблемы — если вы сравните две верхних таблицы, то увидите что GZipStd (я так обозвал встроенный в .NET) даёт абсолютно разные варианты. Хитрость в том, что до .NET4.5, реализация GZip в .NET была ужасная, и её использовать стоило только в одном случае — никогда. Сейчас всё изменилось, и если вы пишите под 4.5, то вполне стоит использовать этот вариант, если нет критичного требования по скорости.

Если нужна максимальная скорость, то используйте zlibnet, это P/Invoke wrapper, поэтому он работает весьма шустро. Если у вас нет желания использовать P/Invoke (чуть сложнее деплой и требуется больше прав приложению), используйте SharpCompress, он мне показался чуть более удобным, быстрым и функциональным относительно классического SharpZipLib. Есть ещё библиотека SevenZipLib — P/Invoke wrapper к 7zip, но по внешниему интерфейсу я не очень понял, как работать с GZip, хотя в описании указано.

Snappy

Алгоритм от Гугла, ориентированный на максимальную скорость. Для .NET есть 2 реализации P/Invoke с оригинальными названиями: Snappy for .NET и Snappy.Net. Есть Safe-реализация Snappy.Sharp, но я её даже не пробовал, т.к. судя по всему работы ещё дофига, она полузаброшена, ничего особо не протестировано. Опять же, если есть желание — берите сами и дописывайте, иначе не советую использовать (записал второй пункт в блокнот).

Сам алгоритм очень шустрый (судя по всему, разработка велась с учётом особенностей процессоров и их кеширвоания), но сжатие у него так себе. Также у обоих реализаций есть проблемы. Snappy.Net не работает в 32х битах из-за какой-то ошибки в реализации библиотеки, вычисляющей CRC32 (третий пункт в блокнот — написать автору, что он лох и надо поправить). Snappy for .NET — требует VS2010 runtime, о чём надо помнить (я для тестов подложил нужные dll'ки на тестовый компьютер).

В общем, пока следует использовать с осторожностью, это не Production-решение

LZ4

Один из моих фаворитов, благо скорость отличная, но надо выбрать реализацию. Их две и обе хорошие. lz4-net — P/Invoke wrapper и LZ4.NET, флакон от автора с четырьмя разными реализациями, которые выбираются по приоритету и доступности: Mixed Mode, C++/CLI (требуется установленный VS2010 runtime, проверка идёт по наличию пакета в реестре, а не по DLL), Unsafe, Safe. Также, автор, возможно будет пилить дальше и улучшать свой код.

Также у алгоритма есть HC версия, которая даёт лучшее сжатие (но скорость сильно проседает), зато декомпрессия просто безумная. По идее, можно использовать это сжатие для данных, которые редко пишутся, но активно читаются.

Качество сжатия алгоритма зависит от дополнительного буфера на словарь, который в разных реализациях по дефолту 1Мб и 256Кб, в реальности, 64Кб дают пристойный результат, но и 1Мб не очень жалко для объёмных данных. Имейте в виду.

Заключение

Я, пока в раздумьях по поводу алгоритма и реализации, склоняюсь к GZip в P/Invoke исполнении и LZ4 в комплектном. Надо заранее определиться, какая скорость вам требуется: если вы передаёте огромные данные по сети со скоростью 1МБ/c, то GZip'а вам хватит за глаза, а сжатие будет активно помогать уменьшить объёмы. Если же сеть в гигабит, а данных немного, то со сжатием связываться вообще не стоит. LZ4 сидит где-то посередине и при своей скорости подходит для всего мало-мальски сжимаемого.

Решайте сами, я пока думаю, решение напишу позднее, когда потестирую всё это в продакшене (т.е. возможно, спустя длительное время).

LeapMotion первые впечатления

Мне подарили LeapMotion, и я хочу поделиться первыми впечатлениями.
Не буду пересказывать существующие отзывы, просто несколько пунктов от меня.

• Выглядит всё очень круто, упаковка в стиле Apple, ничего лишнего, зато два кабеля USB (короткий и длинный)
• Софт симпатичный и просто работает (а на случай проблем есть куча диагностики)
• Всё очень красиво, плавает и летает

• На первый взгляд, очень хорошее API и SDK (можно получить хоть сырую информацию, хоть жесты — т.е. API само занимается математикой, чтобы вручную не вычислять)

• Распознаются руки с пальцами: включая ориентацию ладони и фаланги (хотя точность их распознавания очень неважная), а также тыкательные предметы типа ручки (причём он понимает, что это не палец и у ручки нет ладони.
• По факту — ладонь должна быть повёрнута вниз, пальцы растопырены, иначе не определяет. Т.е. боком ладонь нельзя использовать (или очень хорошо обрабатывать исчезающие и появляющиеся пальцы.
• Дрожание в принципе очень хорошо сглаживается стандартным софтом.
• Он умный и у него большой угол обзора, т.е. не надо держать руку прямо над ним, я положил под монитор и он вполне понимает мои руки, находящиеся перед
• Идеально (имхо) положить его на место клавиатуры, но, естественно, это не получится. Перед клавиатурой — будет мешаться, так что остаётся место за клавиатурой или где-нибудь сбоку для одной руки
• Есть программа для управления компьютером, но она так себе. Не очень удобно попадать по углам, да и резкое неправильное движение приводит к тому, что курсор прыгает и кликает в самых неожиданных местах. Её поведение — следит за пальцем (как курсор), при пересечении виртуальной границы проходит клик. Ладонью скролл. Как-то правая кнопка работает и прочие хитрости, ещё не разобрался. 
• На весу управлять — руки быстро устают, и кроме того, сам рукой закрываешь экран (поэтому, возможно лучше где-то сбоку подцепить)
• В магазине есть много игрушек и приложений. Но, имхо, на побаловаться. Кроме того, везде управление слегка отличается.
• Google Earth управлением руками выглядит красиво, но постоянно куда-то крутится и двигается
• Вообще, управление компьютером с помощью него выглядит как использование некого виртуального тачскрина.
• В реальности, мышку заменить можно, но не нужно, если всё в порядке с руками.

В общем, не буду дальше разводить писанину, возможно, дополню пост после более длительного использования. Пока у меня планы не управлять курсором, а управлять окнами (свернуть, развернуть, закрыть, назад, вперёд, изменить громкость, и т.д.). Но стандартного софта не нашёл (во всяком случае бесплатного), поэтому попробую написать сам, именно так, как я хочу.

Если будут конкретные вопросы, пишите, отвечу. 

Деградация размера MFT от времени

Небольшая заметка посвящена тому, что недавно я обнаружил тот факт, что MFT в Windows не умеет уменьшаться.

MFT — это базовый служебный файл файловой системы NTFS, в котором хранится информация обо всех остальных файлах. Всё это весьма неплохо работает, но есть различные грабли. Сегодня расскажу про один косяк, связанный с тем, что MFT может только расти.

Представьте ситуацию, вы создали на диске миллион файлов (что не так уж и сложно), а потом их все удалили. В результате, казалось бы, место должно вернуться к исходному значению, но оно не вернётся. Потому что в MFT остались записи об этих удалённых файлах, которые никто не собирается чистить. С учётом того, что размер записи обычно порядка 1Кб, вы получили 1Гб мусора, который ни к чему хорошему не приводит. Вроде немного, но всё равно неприятно.

Хорошая новость состоит в том, что если вы опять закините этот миллион файлов, MFT переиспользует своё место и расти не будет. А если не планируете, и ваш перфекционизм мешает спать, то единственный вариант, который я вижу — бекап существующих файлов, форматирование диск и восстановление.

Если вы найдёте способ лучше, буду премного благодарен.

Смена браузера

Небольшой личный пост о ощущениях при смене браузера.

Я очень давно в качестве основного браузера использовал Оперу, и всё было хорошо, несмотря на её глюки, но около года назад её похоронили и перешли на Chromium. За этот код в новом браузере появилось полторы новых фичи, так что рассматривать его в качестве основного инструмента весьма опрометчиво. Хотя в качестве другого браузера, на замену старому, вполне.

Ну так вот, старая опера постепенно работает всё хуже и хуже (сайты просто её не поддерживают, а поддержки новых стандартов как-то не прибавляется), и рано или поздно надо переезжать на что-то другое. Что я и сделал на днях.

Сразу скажу, что по жизни, я одновременно пользуюсь тремя браузерами (жизнь разработчика обязывает), так что, в общем, имею опыт работы со всеми. Но одно дело опыт, другое — основной инструмент.

И каково же было моё удивление над самим собой, что переехав на новый браузер (я выбрал Яндекс.Браузер, это такой Хром, но с мелкими вкусными плюшками), я ожидал что мне будет не хватать множества фич оперы в виде списка закрытых страниц, навороченной статусной строки, диалога при скачивании файла, встроенного блокировщика рекламы, и многого другого. А оказалось, что больше всего приносят неудобства в новом браузере — табы. Неудобная навигация между ними, отсутствие группировки, визуального превью, плохое поведение при большом количестве. И это оказалось для меня самым большим удивлением. Оказывается, наиболее важное в опере не огромное количество фич, а то как они выверены для удобства. И что не хватает, так это такого мелкого повседневного удобства. Удивительно.


PS: Также в качестве браузеров пробовал Maxthon и Avant, люди, действительно, пытаются сделать функционал, но разработчиков у них не хватает, поэтому вылизанности интерфейса нет, и остаётся стойкое ощущение наколенной поделки, несмотря на многолетнюю историю этих браузеров.

Паранойя в андроиде, или как задолбать пользователей

Я неоднократно говорил, что если перекрутить безопасность в приложении, то это приведёт к тому, что пользователи будут отключать её, лишь бы не бесила. Или бездумно кликать на "Разрешить", потому что это окно лезет всегда.
Примеры: UAC в Vista, который лез на каждый чих (в семёрке стал реже появляться), или sudo в SUSE, которое лезет на каждое действие. Пришлось рутовый пароль поставить в 1, чтобы хоть как-то можно было жить.

Но недавно я столкнулся с другой концепцией безопасности. В Андроиде. Её политика заключается в режиме: раз ты используешь это, ты идиот, и мы будем тебе говорить про это. И эта концепция выбесила до белого каления.

Итак, для тестов некоторых сайтов, которые работают по https с клиентской авторизацией, понадобилось поставить пару сертификатов на планшет с андроидом (серверный, чтобы не было предупреждений, и клиентский, чтобы заходить на сайт). Начнём по порядку.

Казалось бы, что страшного в установке дополнительного сертификата? Ну есть проблемы, что с помощью него могут подменять сайты, но ведь в системе и так установлена сотня сертификатов, которые никто не проверяет. И вполне может быть дырка для гугла, для производителя телефона, просто любимый сертификат АНБ. И никто по этому поводу не нервничает. Что сделали в гугле? Сразу после установки появляется неотключаемая нотификация, о том что установлен сертификат. Ещё раз. Нотификация. Неотключаемая. Т.е. вам всю жизнь надо жить с иконкой, где написано что ты идиот, даже если это не так.
Решается данная проблема с помощью рута и переноса сертификата в системное хранилище. Глупо, зато хотя бы можно решить. Через одно место, но проблему хотя бы можно решить.

Но появилась другая проблема. Мне нужен клиентский сертификат. И он работает. И всё хорошо. Но в гугле решили, что я должен себя обезопасить, и обязан включить блокировку планшета с паролем, пин-кодом или графическим кодом. У кого такая блокировка уже включена, те даже не заметят проблему. Но я тестирую на планшете, основная цель которого — смотреть фильмы, читать книжки и кидаться птицами в свиней. И ради одного сертификата, я должен включать блокировку? Да нафига? Была бы идея, если бы к этой блокировке были бы привязаны другие данные. Но если посмотреть: браузеры сохраняют пароли для сайтов, система сохраняет пароли для WiFi и Bluetooth, приложения сохраняют пароли для почты, аккаунтов синхронизации, и доступа к внешним сайтам. Это нормально. Я могу взяв чужое устройство читать чужие письма, смотреть чатики, ходить по сайтам с паролями. Никаких проблем. Но если мне вдруг понадобился клиентский сертификат, я сразу же должен всё запаролить. На мой взгляд полный бред.
Решения этой проблемы я не нашёл. Только косвенное, с установкой сертификата, тестированием и удалением. По-моему бред. Зато можно жить.

Теперь я как программист считаю разработчиков Андроида — мудаками. А как обычный пользователь — всех программистов мудаками, которые мешают мне разговаривать с котиком и кататься на машинках. Не надо так.