MCP

пятница, 20 марта 2009 г.

Немного расчётов про Оперу

По статистике в мире доля Оперы 0.7%. В России 31%.

Берём калькулятор в руки и считаем. Получаем, что если Оперой пользуются только в России, то в России находится всего 2.2% пользователей всего интернета.

Берём статистику, например из Википедии. Получаем, что пользователей интернета в России 2.4% от общего количества. Получаем маленькую нестыковочку. 

Ещё раз в цифрах. В России пользуются Оперой 38 000 000 * 31% = 12 920 000 человек. В мире же пользуются Оперой "всего" 1 581 571 589 * 0.7% = 11 071 000.

Другими словами, в России есть почти 2 млн. человек, которые пользуются двумя Операми, и это с учётом того, что больше в мире ей никто не пользуется.

Сдаётся мне, что кто-то пизд лукавит в статистике. И я очень сомневаюсь, что это делают в России.

среда, 18 марта 2009 г.

Opera Turbo

Ну вот, стоило сделать свою версию сжимающей прокси (кстати, большинство удалось побороть за 10 минут, оказалось, что была бага, которую я правил-правил и не доправил), как норвежцы прочитали мой пост и сделали Opera Turbo.

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

Вообще, думаю что в Опере нашли ту самую killing-feature, которая позволит им прорекламироваться. Не думаю, что кто-то ещё сможет провернуть подобное. Возможно только Гугл с хромом, но не думаю, что им это нужно будет.




Эх, чтобы ещё такого сделать, чтобы в Опере тут же реализовали в 10 раз лучше...

пятница, 6 марта 2009 г.

Proxy

Жизнь течёт, изменяется, но по-прежнему сохраняется потребность в проксе, хотя казалось бы, интернет шустреет, и зачем оно таки надо?  

Достаточно давно, когда интернет у меня был практически только по диалапу (на работе, правда более или менее приличный, но не шустрый), я написал какую-то безумную проксю с совершенно извращённым кешированием. А именно, она кешировала все картинки намертво, CSS и JavaScript, вроде бы тоже. Страничики тоже кешировались, но слава богу обновлялись, иногда.  Как результат, было удобно смотреть сайты в браузере без интернета (ибо раз нельзя достучаться, результат выдавался из кеша), да и трафик был слегка меньше.

Естественно, всё слегка глючило, кеш портился, да много чего было. Но тогда я разобрался в принципах работы HTTP через прокси, написал свою файловую систему для кеша, проработал механизмы блокировки URL'ов с баннерами. Часть из всего этого пригодилась в дальнейших проектах. Да и урощённый движок прокси тоже активно использовался в одном из них.

На этом можно было бы и закончить, но совершенно недавно я понял, что таки старые наработки ещё пригодятся. Дело в том, что интернет дома развился до неузнаваемости, у меня появился отдельный компьютер, который является сервером и круглосуточно сидит в сети и делает своё маленькое грязное дело.  На работе же, с интернетом всё не так радужно. В результате, после подкинутой идеи, я за пару часиков практически с нуля (используя старые наработки в качестве напоминалок, как надо и как не надо делать) написал сжимающий прокси. Т.е. идея совершенно банальная: на работе есть прокси "клиент", который связывается с прокси "сервером" отдавая ему запросы и получая ответы (которые уже "сервер" скачивает из интернета). И вот эта передача уже идёт запакованная.

Потом, конечно, пошли доработки, в которых я выяснил, что встроенное в .NET сжатие GZip — это унылое говно, которое использовать нужно только по необходимости. В других же случаях гораздо лучше использовать #ziplib, мало того, что жмёт на порядок лучше, так ещё и работает быстрее! Кто там говорил, что в Майкрософте воруют код? Да ничего подобного! Если бы они это делали, они бы не написали такой отстой. Сжатие BZip2 было реализовано, но исключено по причине того, что оно раз в 10 медленнее GZip (точнее Deflate, но это уже тонкости структуры результирующего потока), а результаты в большинстве случаев не лучше. LZMA (7z) — результаты давал ненамного лучше, то скорость у него вообще отвратительная. Были ещё варианты сжатия по заранее заданному словарю, но пока на них забил из-за сложностей в реализации (хотя прирост сжатия должен быть весьма и весьма хорош). Добавил простенькое кеширование, чтобы не перегружать заново некоторые страницы (они реально перегружаются, но если результат такой же, то он не отправляется). Также сделал повторное использование TCP-соединений, чтобы уменьшить их количество и соответственно трафик.

Результаты оказались в принципе достаточно неплохие. Сжатие в зависимости от условий использования вполне может составлять 50% (в принципе, при некоторых сценариях и все 35% от исходного объёма). Заодно выяснил, что некоторые серверы плюют на робкие попытки прокси попросить закрывать соединение после отсылки данных (пришлось закрывать самостоятельно). Ну и конечно, всё периодически глючит, как же без этого.

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

Конечно же, можно было бы взять что-нибудь готовое, но это совершенно неинтересно. Написать что-нибудь самому, очень полезно для развития. При этом, как я уже писал, с оценкой времени всё туманно, так что как оценить пользу/вред от этого совершенно непонятно.

пятница, 27 февраля 2009 г.

Ribbon Calculator

Моей любимой шуткой про Windows 7 было то, что у неё калькулятор с ribbon-интерфейсом.  Это было почти правдой, с учётом того, что что  WordPad и Paint с ним, родимым. Но оказалось, что я был недалёк от истины, и таки есть проекты нужного калькулятора:Стырено с хабра.

вторник, 24 февраля 2009 г.

Кризис в действии

Я уже писал про семинары от Microsoft. А сегодня (да-да, именно сегодня ) пришла напоминалка. Сразу видно, что в компании кризис (выделение моё):
Рекомендуем взять с собой документ, удостоверяющий личность, и внешний носитель или флэшь большого объёма.

Т.е. судя по всему, информацию будут писать лично на флешку (на болванки денег уже нет). Да и судя по времени письма и изящному слогу, сотрудникам тоже приходится весьма не сладко (очень надеюсь, что это именно из-за позднего времени ).

Жалко, что в этом году всё настолько бюджетно.

воскресенье, 22 февраля 2009 г.

Опять про градусник :)

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

Как видно (я ещё дополнительно выделил, если не очень заметно ), в районе 10° мороза, начинается какая-то жопа, и показывается одинаковая температура. Вначале я думал, что это и есть минимальное значение температуры (а не обещанные -20°), но после того, как эта десятка была пробита, и температура как ни в чём не бывало отправилась понижаццо дальше, я впал в полный ступор. 

После того, как я быстренько прикинул, что получается (на рисунке красная линия  — рассчитанная погода, зелёные линии — проблемные места):


Я получил примерные результаты: где-то с -7° до -11° есть серьёзные проблемы с точностью, при этом где-то с -7.6° по -10.8°, творится полный превед.

Откуда эти проблемы — я не знаю. Возможно, это результат внутренних рассчётов контроллера, а может там просто что-то замерзает и заклинивает, или же брак конкретно моего экземпляра. Я недостаточно хорошо знаю технологию, по которой изготавливаются подобные датчики, но догадываюсь о возможных проблемах с точностью и калибровкой (уже было дело, матюкался ). Может он отживеет со временем, а может и, наоборот, его станет конкретно плющить, я не знаю тоже. Если вы знаете, в чём тут может быть проблема, и возможно ли её решить, то буду признателен.

А пока вывод, который из этого следует вынести: если на улице температура от  -7° до -11°, то будут серьёзные проблемы с её отображением, а конкретно, будет показываться: -10°.

пятница, 20 февраля 2009 г.

Как оценить затраченное время?

для самописных программ?

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

Т.е. выступаешь и проектировщиком, и кодером и тестером, и всем кем можно, время размазано, но оценить его хочется.

Попытка рассчитать это время в контексте "если бы я работал над этим официально", даёт примерную оценку, но чувствуешь что это совершенно неправильно, ибо на работе делается в основном упор на качественный конкретный функционал из ТЗ. А тут, балуешься, пробуешь новые идеи на коленке, постепенно приводя их к хорошему виду (если понравились), т.е. тратишь время на то, на что никогда бы не потратил на  работе, и не тратишь на то, на что на работе приходится (оформление, комментарии, совместная работа, бюрократия). И как-то не похоже, что эти времена хоть как-то коррелируют.

Так что идеи оценить затраченное время витают давно, но что с ними делать, ума не приложу. Может у кого-нить есть идеи?