MCP

суббота, 28 марта 2009 г.

Обновление сайта с градусником

Прошло достаточно много времени с моего последнего поста про градусник. С технической точки зрения за это время ничего не изменилось, но появились некоторые усовершенствования на его сайте.

1. Добавлен график изменения температуры за месяц. 
Точнее не за месяц, а за 24 дня, но существенной разницы в этом нет. Просто ширина поля графика 576 пикселей, т.е. 24 часа * 24 дня. По пикселу на час. 

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

2. Дополнительная информация о текущей температуре.

Тут она фиолетового цвета. График весь из себя плавный и красивый. Это я ради интереса добавил текущую погоду с Гисметео, чтобы можно было убедиться в том, что мой градусник так же невероятно точен, как и у продвинутых систем (на самом деле он ещё точнее , Гисметео слишком оптимистичны).  Хотя тут видны сразу две проблемы с моим градусником. В 05:50 — тепмература сильно опустилась и градусник начал глючить (об этом уже написано). А в 9:20 — Солнце аккуратно попало на градусник и температура поехала. Надо будет собраться и попробовать перевесить его чуть правее, чтобы его получше закрывало от солнца. Хотя после перевода часов, проблема уедет на час, так что будет не так критично .
Хотя чего я всё заладил про Гисметео. Буквально с сегодняшнего дня данные идут от HMN, ибо они обновляются чаще и оперативнее. Но это уже детали, погоду, по идее, они берут из одних источников.

3. Web Slices.
Ну и напоследок маленькая фишка для пользователей восьмого Интернет Эксплорера. Теперь есть поддержка Веб-Слайсов, и можно добавить на панель браузера "обновлябельный" погодный сайт. Если вы уже пользуетесь восьмеркой — рекомендую добавить . А если нет, то рекомендую поставить, ибо браузер весьма и весьма симпатичный (хотя отмечу, что у некоторых людей он конкретно глючит, причём не ясно от чего).

пятница, 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% от исходного объёма). Заодно выяснил, что некоторые серверы плюют на робкие попытки прокси попросить закрывать соединение после отсылки данных (пришлось закрывать самостоятельно). Ну и конечно, всё периодически глючит, как же без этого.

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

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