Многим уже известно, что Ростелеком при поддержке Mail.ru начал внедрение своих рекламных баннеров на сайтах не защищённых протоколом HTTPS. Защититься от их появления на своём сайте можно переводом его на HTTPS. Но что делать, если у вас нет такой возможности или для вас это слишком трудоёмко? Я провёл своё небольшое исследование и хочу поделиться простым и пока ещё эффективным способом против этой заразы.

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

Delphi давно славится тем, что disabled иконки по умолчанию выглядят как-то так:



А хотелось бы, чтоб они выглядели вот как-то так:



Воспользуемся тем, что Delphi позволяет заменить disabled иконки своими, указав дополнительный список изображений. Но рисовать и подключать такие иконки каждый раз занятие утомительное. Поэтому мы создадим этот список изображений динамически, во время выполнения программы.

Создавать такой список изображений мы будем в специальной функции CreateSpecialImageList(). В качестве аргумента нам понадобится список с оригинальными иконками, а в качестве возвращаемого значения уже будет нужный нам TImageList. Тогда подключить наши новые иконки мы сможем при создании формы следующей строчкой кода:

ActionManager.DisabledImages := CreateSpecialImageList(ImageList);

Сегодня моя дорогая супруга решила обновить свой блог на Блогспоте, но к сожалению не смогла на него зайти. Зайдя через анонимайзер на блог я убедился, что он на месте. Ругнувшись в очередной раз на провайдера, я все же решил проверить закравшуюся во мне мысль — а вдруг заблокирован? Определил по NSLookup адрес: 173.194.71.132, я зашел на zapret-info.gov.ru и вбив капчу со второго раза увидел:



Выяснив, что 173.194.71.132 — принадлежит таки Гуглу, я объяснил жене ситуацию и сказал, что единственным выходом будет завести блог на выделенном IP на платном хостинге, тогда вероятность подобного WTF будет значительно ниже.

Вот я только одного не понимаю, зачем блочить весь IP? Единственная причина, на мой взгляд, скрыть истинную причину блокировки. Ведь это удобно, повесить на одном IP с неугодным сайтом «запрещенный контент» и внести весь IP в реестр.

Мне нравятся html-сайты. Они быстрые, не нагружают сервер, их легко бекапить и легко переносить, можно держать на флешке для оффлайнового просмотра. Но есть проблема — их сложно сопровождать. Вносить изменения в несколько файлов для смены пункта меню или года копирайта — занятие невеселое. Для этих целей я сначала написал для себя шаблонизатор, а затем после нескольких итераций родилась вот такая программа — WebProject.

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

У меня давно на компе уже лежало начало придуманной как-то истории Идеальный компаньон 2.0, да вот писать продолжение все никак руки не доходили, может дойдут у кого-то из многочисленных читателей Хабра?

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

Мне нравится JavaScript как весьма лаконичный и красивый язык сценариев. Я часто его использовал, да и сейчас использую, для автоматизации некоторых своих задач. Недостаток проявляется только в том что часто бывает недостаточно объектов и методов для выполнения поставленных целей. Но в этом случае меня выручали самописные COM-объекты. Еще для полноценных приложений необходим пользовательский интерфейс. В качестве простого интерфейса для небольших приложений весьма удобно использовать HTML. Все это есть в Windows начиная с 98-й версии и называется — HTA (Hypertext Application).

Недостатком HTA я считаю, что для выполнения такого приложения необходимо несколько файлов, сам HTA-файл, картинки для оформления интерфейса и COM-объекты с необходимым нестандартным функционалом. Причем COM-объекты необходимо регистрировать в системе, что делает практически невозможным создавать простые в использовании приложения.

Вот если бы упаковать все это в один файл и запускать его специальным приложением. Это возможно сделать следующим образом: все необходимые файлы: html, css, картинки и сам скрипт сценария сохраняется в zip-файл, а все часто используемые объекты и методы реализуются прямо в исполняющем приложении. Это приложение представляет из себя своеобразный фреймворк с необходимым функционалом. Все это было мной реализовано и получило название JSA — JavaScript Application.

Но дальше «Остапа понесло...». А что если интерфейс приложения разместить на веб-сервере и оттуда же загружать сценарий самого приложения. HTML-интерфейс обращается к функциям моего фреймворка и выполняет необходимые действия. Например, пишем приложение — Ресайзер картинок, загружаем приложение с сервера, а вся работа выполняется на компьютере пользователя. Т.е. нам не нужно аплоадить картинку на сервер и затем скачивать обратно, все это в целом повысит скорость работы приложения. Это похоже на модные сейчас расширения для браузеров типа Google Gears. Однако в этом случае остро встает вопрос безопасности. Если дать скрипту с удаленного сервера хозяйничать на пользовательском компьютере, то этак и до троянов недалеко.

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

Что мы получаем в итоге. На компьютере пользователя ставится небольшое приложение-фреймворк умеющее загружать с веб-сервера упакованный и подписанный сценарий который при запуске открывает окно с HTML-интерфейсом который расположен так же на веб-сервере. В моем случае, так как я использовал для реализации HTML интерфейса ActiveX WebBrowser, а в качестве исполняющей системы сценариев ActiveScript, то исполняющий файл получился весьма небольшой, около одного мегабайта.

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

Все это похоже на Adobe AIR или Java FX, но в моем случае получился весьма небольшой фреймворк (1 Mb) и идея размещения интерфейса на сервере, а не включенного в само приложение, дает определенные преимущества.